The engineering team gets many different kinds of work from many different sources. An important question for solving these work items is: is something ready to be worked on?
Answering this question, requires at least the following information:
Does it have all the information needed for a member of the engineering team to start working on?
If it does not, what exactly is the information needed? And who is responsible for providing it?
Once all the information is provided, is there explicit documentation on what actually needs to be done?
Work categorization¶
The following non-exhaustive initial list of the different kinds of tasks that the engineering team performs during a sprint cycle.
Definition of ready¶
The following describes what is the information needed for a member of the engineering team to start working on a specific type of work item.
Feature enablement¶
Some features for hubs require 2i2c engineering effort to be enabled, and usually this is requested via the support process. Before a feature enablement request is considered ready to be worked on, it must have the following information:
Link to 2i2c documentation on how to enable this feature. This is to be found under infrastructure
.2i2c .org documentation site. Any additional information needed for this specific feature. This should be listed in the 2i2c documentation for how to enable this feature.
Functionally, this means that anything that doesn’t have an explicit documentation on how to enable it should not be considered a feature we currently support!
Routine maintenance¶
These are tasks that must happen on some predefined cadence (every month, every quarter, etc). It’s important that these get done consistently, so the cadence must be adjusted so we can in fact consistently do these given our actual capacity.
Before a routine maintenance task can be considered ready to be worked on, it should have:
Link to 2i2c documentation that describes the cadence this should be performed in, and how it should be done. The latter can just be links to upstream, as often these tasks are not 2i2c specific.
A time period during which this maintenance should be performed.
New Hub¶
This is being tackled as part of this issue. The information needed for various phases of turning up a new hub would be captured in a new hub issue once this issue is sorted.
Configuration change¶
This is usually about modifying a feature that was enabled via a feature enablement request earlier. So the definition of ready should be very similar.
Link to documentation about this feature, which has at least some mention of the possible ways to make configuration changes. Since 2i2c documentation may not cover all the possible options (as that would be too unweildy), this could be either a link to 2i2c documentation on infrastructure
.2i2c .org or a link to upstream documentation about various configuration options for this feature. Any additional information needed for this specific configuration change.
Functionally, this means that if we are requested to change config for something that we can’t
find any documentation for, it should be escalated (via a message to the #engineering slack channel)
so we can decide what needs to be done with it. The most likely outcome should be that documentation
is written for it along with the config change.
Community config change review¶
This should be codified once this issue is resolved.
Incident response¶
This should be handled according to our incident response process.
Fault fixing¶
Usually a user reports ‘something is not working’, but it is not urgent in the same way an incident response is. These cases are a mix of incident response and configuration change. But because the timeline pressure of an incident response is not present, these should be handled exactly the same way as a configuration change.