We aim to engage with the community for feedback whenever significant product changes are being proposed for Meltano, the SDK, and the Hub. The most common way we do this is via Office Hours and Demo Day. Internal team members as well as external contributors should plan to present at office hours and/or demo day to collect feedback from the broader community.
If it is not possible to present at office hours or demo day, it may be possible for a knowledgeable team member or
community member to present on your behalf. Alternatively, you may also post a recorded video demo and walkthrough,
of length between 2 and 10 minutes, to the
#contributing channel on slack, posting a link also on your MR. You
may use Slack’s built-in video message feature, the free tool Loom, or another similar tool.
Engineers should consider their work priorities in the following order:
Some issues may be large in scope and need further refinement. This is done in collaboration with Product. For larger issues, it may be necessary to do a research spike to better understand the technical challenges in the proposed solution.
If something needs a research spike, the
Needs Research Spike label will be used.
The spike can either be tracked in the main issue in the comments, or as part of a separate issue created just for the spike.
When you do a spike, be clear on how much time you are spending. Anything less than a few hours you are ok to prioritize when you’re ready. If the spike is longer than half a day, coordinate with your manager and Product on the best time to prioritize.
An issue is ready to be worked on once both a feature spec and implementation spec have been added to it.
Feature specs describe the desired end state that should result from resolving the issue. They are created in close collaboration with Product and must be completed before an issue is assigned. Issues are typically assigned on Thursday of the week before the iteration in which the issue will be worked on.
Implementation specs describe the code, test, and documentation changes that will be required to satisfy the provided feature spec. Typically an implementation spec will be written by the issue’s assignee but they should be written in such a way that the issue could be assigned to a different engineer and it would be clear what work the assigned engineer would need to perform–even if they are relatively junior or less familiar with the relevant parts of our codebase.
After an upcoming iteration’s issues are assigned on Thursday, engineers should spend no more than three hours on that Friday to review their upcoming issues and do the following:
After any questions or concerns raised have been resolved in the issue, the assigned engineer should add to the issue an implementation spec which includes:
After the implementation spec has been written, the issue’s weight should be re-evaluated in light of the proposed implementation. Any changes to issue weight that result from this should be communicated with a flagged comment to Taylor/AJ with details about the new weight versus the initially planned weight.
If new information comes to light while an issue is being worked on which changes the implementation such that it will no longer match the provided implementation spec, that should be communicated in a timely manner via a comment on the issue. If this information changes the issue weight or threatens the feasibility of the proposed changes, that should be communicated to Taylor/AJ as quickly as possible.
https://www.meltano.com is automatically monitored using Pingdom, with notifications of downtime posted to:
hello@email address, and
When any instance managed by us is reported to be down, through Pingdom or any other means, resolving this becomes the team’s top priority.
Engineering has a regular all-hands meeting to align on overall priorities, discuss areas for improvement, share lightning talks, and socialize. Product is invited to the meeting but is not expected to always be in attendance.
We mirror the three main Meltano repositories (meltano/sdk/hub) from GitLab to GitHub. This is managed via the “Mirroring repositories” section with the Settings of the GitLab repository. The push was created using Taylor’s personal GitHub account (tayloramurphy) with a personal access token made just for the use case. This was tracked in this issue.