At Meltano, we use GitHub to track everything that needs to (one day) be done or discussed.
In line with our Together we thrive value, most of our trackers and the issues they hold are public so that our entire community can participate. The most commonly used non-product trackers are the following:
meltano/handbook): Public issue tracker for process and policy proposals that will be documented in the public company handbook.meltano/internal-general): Internal issue tracker for topics around the team & companymeltano/administration): Private issue tracker for administrative tasks related to running the business. Used primarily by CEO and Head of Operations.meltano/hiring-process): Private issue tracker for hiring topics: hiring plans, job openings, and interview processes. Repository contains processes, questions, and exercises.meltano/internal-marketing/): Private issue tracker for all things marketing.meltano/meltano)meltano/sdk)meltano/hub)meltano/squared)Labels are managed via the Meltano Labelsync repository. Each label is defined in the labelsync.yml file.
New labels should not be made via the GitHub UI, instead a PR should be opened to the YAML file and go through the review process. Instructions for how to structure the YAML file are in the README of the repository. Once merged, LabelSync will handle creation, renaming, and deletion of labels.
We have 2 labels to indicate that something is prioritized but needs more refinement:
Needs Refinement : Used by Product and Engineering to indicate that more details, user stories, and organization are neededNeeds Research Spike : Used by Product and Engineering to indicate that a Spike is needed to better understand the scope of work.We have 5 urgency labels:
urgency/Lowurgency/Defaulturgency/Highurgency/Higherurgency/HighestThe majority of issues should have the urgency/Default label, which is a sign that we are accomplishing the important as well as the urgent.
The urgency/Low tag can optionally be used to indicate issues that should be the first to be deprioritized.
Issues with the urgency/Default label, or no urgency label at all, in a milestone have a ~80% chance of being completed within a milestone.
Issues with the urgency/Low label have a ~50% chance of being completed within a milestone.
We aim to close 100% of issues with urgency/High or above within the milestone.
The urgency/Highest should be resolved for urgent user-facing issues such as the website going down - and should be resolved within 24 hours or less.
If an issue of this type is moved to another milestone because it was not completed, the urgency should most likely be increased.
If there is an issue of particular interest, add the urgency/High label to it and leave a comment tagging Taylor with a note explaining why you believe it’s a high urgency.
All issues should have a label indicating its kind:
kind/Bugkind/Featurekind/Tech Debtkind/RiskThese kinds map onto the Flow Framework items of Feature, Defect, Debt, and Risk.
These are meant to be mutually exclusive and collectively exhaustive, meaning an issue will have 1 and only 1 of these labels.
There is a fifth label available for filtering purposes: kind::Non-Product which is used for administrative and business-related issues.
| Kind Item | Delivers | Description | Example Artifacts |
|---|---|---|---|
| Features | New business value | New value added to drive a business result; visible to the customer | Epic, user story, requirement |
| Bugs (Defects) | Quality | Fixes for quality problems that affect customer experience | Bug, problem, incident, change |
| Risks | Security, governance, compliance | Work to address security, privacy, and compliance exposures | Vulnerability, regulatory requirement |
| Tech Debts | Removal of impediments to future delivery | Improvement of the software architecture and operational architecture | API addition, refactoring, infrastructure automation |
This table is sourced from “Project to Product” by Mik Kersten.
FAQ:
It is the responsibility of the Product team to add this label, but Engineers are welcome to add it as well.
All issues should have a label indicating its value stream:
valuestream/Meltanovaluestream/Hubvaluestream/SDKvaluestream/Academyvaluestream/Ecosystem - This is a bit of a catchall for general “community” type work that benefits the Meltano and Singer communities but does not neatly fit into another value stream.These map to our “product lines” and are used to understand allocation of work across the value streams.
There is an additional label for filtering purposes: valuestream/BusinessOperation which is used for administrative and business-related issues.
These value streams are inspired by the Flow Framework and are useful for understanding every bit of work that goes into the products that deliver value for users and, eventually, customers.
It is the responsibility of the Product team to add this label, but Engineers are welcome to add it as well.
If appropriate, an issue should have a stage label (one of the letters in “meltano”):
ModelExtractLoadTransformAnalyzeNotebook (currently unused)OrchestrateThe value of these labels is under discussion as forcing them to fit the Meltano acronym may not be optimal. We want a way to indicate the part of Meltano specifically that the work applies to, such as transformation, integration, etc.
Accepting Pull Requests for issues that are ready to be picked up by a community contributorMarketing::Blog Feature for issues which we think may deserve a blog post feature, and/or other promotion on social channelsCommunity-Contributed PRs for issues which have attached MRs from the community (used in prioritization and monitoring)Awaiting Action/Author for community-contributed issues and MRs which are pending an action from the original authorDemo Day::Up Next for Demo Day to indiciate things people would like to DemoDemo Day::To Share for Demo Day to indicate was is planned to be shared at the next meetingDemo Day::Shared for Demo Day to indicate what has been previously sharedDiscussion for issues that require more discussionExplorationCommunity SupportCLI or UI for issues specifically concerning the CLI or UIBackend or Frontend for issues specifically concerning the Backend or FrontendDocumentation for new or updated documentationIntegrations for issues relating to integrations with other open source data tools, typically as pluginsConfiguration for issues relating to configurationPlugin Management for issues relating to plugin managementNew labels can be created as appropriate at the Group Level and should be documented here.
Milestones are used to track progress on groups of issues or pull requests within a repository. They are defined at the repository level.
Once an issue becomes a priority, a sprint iteration is set (identified by the Friday of the week in question), even if it’s still weeks away and may end up being moved.
New iterations are created about 6 weeks in advance as part of preparation for the weekly kickoff meeting.
Check out the GitHub documentation on Iterations to better understand the differences between iterations and milestones.
The Product team manages all iterations. They can only be made at the project level, they always have a start and end date, and the date ranges cannot overlap.
Anyone can add an issue to an iteration, but at the end of the issue, all incomplete issues will be rolled to the next iteration by Product.
The team uses Github’s weight feature to align on rough estimates of relative size. We bias towards
a system where most increments are double of the prior increment, to avoid debates of “is this a 2 or a 3?”
and to acknowledge these are only low-precision estimates. The used values are: 1, 2, 4, 8, 12,
20, and 40.
Sizing should always take into account these three factors:
1 - E.g. A simple docs update
2 - E.g. A simple code fix which may include a docs update, changelog, etc.
4 - Roughly 1-2 days work
8 - Roughly 2-4 days work
12 - Likely >=1 week and <=2 weeks
20 - Should be broken to smaller deliverables if possible
40 - Probably needs to be planned out in smaller deliverables
It’s important to document the why behind sizing:
Anyone reviewing or submitting an issue can add a weight estimate to a new issue.
Engineering team management otherwise has the responsibility of filling out missing weight values prior to each week’s kickoff.
When weight is not clear, we will ping an individual on the team to ask for second opinion.
As an engineer, whenever you are assigned an issue, you should immediately check the weight and
confirm if it is correct. In the case that an item is significantly over- or under-estimated, please
raise a comment and tag head of engineering and product. This may inform prioritization.
Whenever a new milestone starts, we re-estimate the remaining weight for anything still in-progress.
Again, this may inform prioritization.
By the end of day Friday, or the last day of their work week, everyone is expected to:
In Progress status.In Review status will be expected to be closed out once review completes.
Needs Assist status may be appropriate.This is in preparation for the Product milestone review and Weekly Kickoff on Monday.