This page defines recurring practices which help the Engineering team to function effectively and efficiently.
We adhere to a weekly iteration delivery cycle. We do not adhere to formal sprints. Instead, leadership from Engineering and Product meet each Thursday to discuss the upcoming priorities for the next two weeks and to add or update the following week’s tasks. An “iteration” is simply a bucket of issues in GitHub which are assigned for work over a given week.
We generally work with more of a kanban style. We do this as it works better with our committment to asynchronous work. We aim to minimize Work in Progress (WIP) which, for Meltano, means assigned work in a given iteration.
Engineers are expected to deliver at least one feature or bug fix at least every 3 out of 4 weeks.
Every Wednesday, engineers receive an automated prompt from Geekbot in Slack, requesting a summary of work in-flight and expected deliverables through the end of week (EOW). This should be completed by end of day (EOD) Wednesday, as this information will be used on Thursday in planning the deliverables for the following week.
On a weekly basis (generally Thursdays), Engineering and Product leadership meet with the following agenda:
During the process of creating engineering assignments for the coming week, Product and Engineering leadership will take care that each engineer is assigned at least one small or medium-sized work item (
<=4 weight) in addition to any larger long-running work items. This is to that ensure every engineer has the ability to ship at least one work item in the coming week, per the Engineering team’s standard practice - and that at any time if an engineer becomes blocked on a larger work item (waiting for code review feedback, for instance), they can immediately fall back to the smaller item as needed.
Every Wednesday, the Meltano team meets with our users and community members. The main objectives of this meeting are:
During the weekly Thursday sync between Engineering and Product leadership (
@taylor), Product and Engineering leadership will perform the following maintenance:
Up Nexton the Office Hours board in GitHub.
If fewer than 3 topics are selected as candidates for discussion in the upcoming week, and/or if one or more topics require community member attendance, then Engineering or Product leadership will raise these concerns as new threads in the
Our goal is to have 3 medium-sized topics for each office hours, roughly 30-45 minutes of internally-curated content in order to make the most of our attendees’ valuable time.
In cases where there is an expected shortage of Office Hours content, reach out to community members who have raised topics or opened MRs with us recently. Especially relevant are contributors who have proposed net-new functionality, including new plugins, new capabilities, and other feature improvements which are relevant for team discussion. Community members with long-running or outstanding MRs also make good invitees, in hopes that a face-to-face conversation could unblock or otherwise assist the contributor’s MR to progress forward.
We will not cancel Office Hours sessions for lack of content, but may opt to conclude the session early, any time after 10 minutes elapsed. Sessions will always be held open for 10 minutes minimum, to allow time for community members to join and offer proposed topics or questions.