For an understanding of what this team is going to be working on take a look at the product vision.
The Verify:Runner Group is focused on all the functionality with respect to Runner.
This team maps to Verify devops stage.
The following people are permanent members of the Verify:Runner group:
|Elliot Rushton||Backend Engineering Manager, Verify:Runner|
|Tomasz Maczukin||Senior Backend Engineer, Verify:Runner|
|Steve Azzopardi||Backend Engineer, Verify:Runner|
|Georgi Georgiev||Senior Backend Engineer, Verify:Runner|
|Pedro Pombeiro||Senior Backend Engineer, Verify:Runner|
|Lyubomir Raykov||Senior Backend Engineer, Verify:Runner|
|Arran Walker||Senior Backend Engineer, Verify:Runner|
The following members of other functional teams are our stable counterparts:
|Grzegorz Bizon||Staff Backend Engineer, Verify:Continuous Integration|
|Dimitrie Hoekstra||Product Designer, Verify:Continuous Integration|
|Miranda Fluharty||Frontend Engineer, Verify:Testing|
|Sarah Groff Hennigh-Palermo||Senior Frontend Engineer, Verify:Continuous Integration|
|Darby Frey||Senior Manager, Engineering, Verify|
|Scott Hampton||Senior Frontend Engineer, Verify:Testing|
|Payton Burdette||Frontend Engineer, Verify:Continuous Integration|
|Frédéric Caplette||Frontend Engineer, Verify:Testing|
|Zeff Morgan||Senior Software Engineer in Test, Verify:Testing|
|Tiffany Rea||Software Engineer in Test, Verify:Continuous Integration|
|James Heimbuck||Senior Product Manager, Verify:Testing|
|Thao Yeager||Senior Product Manager, Verify:Continuous Integration|
|Darren Eastman||Senior Product Manager, Verify:Runner|
|Juan J. Ramirez||Senior Product Designer, Verify|
|Marcel Amirault||Technical Writer, Verify (Continuous Integration, Testing), Release (Progressive Delivery)|
|Suzanne Selhorn||Senior Technical Writer, Package, Release (Release Management), Verify (Runner)|
|V.M.||Senior Product Designer, Verify:CI|
As a team we maintain several projects. The https://gitlab.com/gitlab-com/runner-maintainers group is added to each project with maintainer permission. We also try to align tools and versions used across them.
We spend a lot of time working in Go which is the language that GitLab Runner is written in. Familiarity with Docker and Kubernetes is also useful on our team.
We follow the same process outlined here. Any engineeer inside of the organization is welcome to become a maintainer of a project owned by the Runner team. The first step would be to become a trainee maintainer.
To start the maintainer training process, please create an issue in the Runner project's issue tracker using the Release Maintainer Trainee template.
After the training is finished, the new maintainer will be added to the https://gitlab.com/gitlab-com/runner-maintainers group, which will set proper permission across the projects.
editoraccess to the
group-verifyproject in GCP
gitlab-com/runner-groupgroup on GitLab.com
team.ymlhas the new member as a reviewer of
gitlab.com/gl-retrospectives/runner/project and add to the team definition in
Runner Group Daily Standupand
Runner Weekly Retro
Verify1password vault (requires creating an access request).
We try to use the Kanban process for planning/development. Here is the single source of truth about how we work. Any future changes should be reflected here. If you feel like that process is not ideal in certain aspects or doesn't achieve a goal, you are more than welcome to open a merge request and suggest a change.
We use the following board for planning, milestone tracking.
~workflow::start: This is the backlog for the product manager, they are responsible for this column. Issues should be vertically stacked, the top one has the highest priority. At this stage the issue is not very fleshed out, and we still need to understand the problem. When an issue is in this column it means that the product manager is aware of the issue and will start working on it soon. This column is limited to 10.
~workflow::planning breakdown: This is where the engineering team
will work with the product manager to make sure we have a good
proposal for the issue at hand. Each engineer should spend 1-2 hours each
week to discuss the issue async with the community and product manager
to figure out a proposal. Particular attention should be given to thinking
about how the team can build the feature in an iterative way - what's the
smallest change we could make to get some version of the feature into the
hands of a customer in a single release?
Sometimes it's helpful to attach a milestone to the issue that is in this
column, so that an engineer can focus time doing PoC and research spikes for
that specific release.. It's perfectly OK for an issue to be closed from this
column if we decided to split the issue into multiple ones. When both the
product manager and engineering team are happy with the proposal they should
move the issue to the next column,
~workflow::ready for development. The
people assigned to this issue are most likely engineers and are responsible
for getting this issue to the next stage.
~workflow::ready for development: At this stage, we should have a good idea of what the issue requires, and how much work it is. When an engineer is out of tasks to work on and has no merge requests to review or any issues that are
~workflow::In devthey should pick the one on top, assign it to them and move it to the next column. In this column, each issue should have a milestone attached to it to indicate to the customer in which release it will be done in.
~workflow::In dev: Here is where the engineer starts working on the issue. If the issue is not clear on what needs to be achieved, they should discuss it with the team to see if it needs to go back to previous stages. This column is limited to 3 issues per engineer in the team. If they have more issues assigned to them we need to reevaluate the workload of the engineer because there is most likely a lot of context switching which is not effective.
~workflow::In review: When the issue has either 1 merge request or multiple merge requests ready for review it should be moved to the
~workflow::In reviewcolumn. There is a limit of 20 issues that should be in review. If we are at limit engineers should not pick up new work but see if they can help out in the review process.
~workflow::blocked: There are multiple reasons why an issue can be blocked. If the issue has a milestone attached to it, the issue blocking it should have the same milestone or 1 earlier, and have a higher priority. We should also mark the issue as blocked using the related issue feature.
~workflow::In review. If not pick a new issue from
~workflow::ready for development.
/labelquick action to keep the same priority stack.
As discussed above each issue inside of
development should have a milestone attached to it. If stack-ranked
properly, the issues on top should be in the current milestone, and then
the upcoming milestone. The product manager will take the top 5 issues
~workflow::ready for development column that is intended
for the upcoming milestone and use these issues as kickoff
The team has a weekly meeting where we spend 10-15 minutes
to review and discuss issues on the board. Especially if the product manager needs input on
~workflow::start. There shouldn't be uncertainties regarding the priorities
for the week ahead at the end of the meeting.
Issues worked on by the Runner group a group label of ~"group::runner". Issues that contribute to the verify stage of the devops toolchain have the ~"devops::verify" label.