|Matt Nohr||Engineering Manager, Monitor:APM|
|Reuben Pereira||Backend Engineer, Monitor:APM|
|Ryan Cobb||Backend Engineer, Monitor:APM|
|Adrien Kohlbecker||Senior Backend Engineer, Monitor:APM|
|David Wilkins||Senior Backend Engineer, Monitor:APM|
|Mikołaj Wawrzyniak||Backend Engineer, Monitor:APM|
|Kirstie Cook||Backend Engineer, Monitor:APM|
|Adriel Santiago||Interim Frontend Engineering Manager, Monitor:APM|
|Jose Ivan Vargas||Frontend Engineer, Monitor:APM|
|Dhiraj Bodicherla||Senior Frontend Engineer, Monitor:APM|
|Miguel Rincon||Senior Frontend Engineer, Monitor:APM|
|Achilleas Pipinellis||Technical Writer, Create, Package, Monitor, Secure, Defend|
|Amelia Bauerly||Product Designer, Monitor & Package|
|Dov Hershkovitch||Senior Product Manager, Monitor:APM|
|Sarah Waldner||Product Manager, Monitor:Health|
|Nadia Sotnikova||Product Designer, Monitor|
The APM group is responsible for:
This team maps to the APM Group category.
The APM Group is responsible for providing the underlying libraries and tools to enable GitLab team-members to instrument their code. When adding new metrics, we need to consider a few facets: the impact on GitLab.com, customer deployments, and whether any default alerting rules should be provided.
Recommended process for adding new metrics:
In planning a milestone, the engineering and product team work closely together. We do follow the Engineering Workflow and specifically the Product Development Timeline when planning a milestone. However, here is some additional information that may help in the planning process.
For APM we use the APM Planning Board to do milestone planning and to prioritize our backlog. We defer to the Product Development Timeline for deadlines. The following information outlines how we execute those tasks in the context of our issue board where
M is the month in which milestone
m will be shipped:
M-1(at least 14 days before milestone
Due Date: First day of the month. Note: this aligns with the Product Development Timeline
Identify any issues that will not be completed in
m-1 and move them to
m. Apply the "to schedule" label for any that are moved, and apply a weight (see Issue Weights). Note: This may continue to happen leading up to our deadline for finalized scope on the
M-1(at least 5 days before milestone
Scope should be finalized with the
deliverable label applied to all issues scheduled for
release post item label to the top issues for the upcoming milestone that we want to highlight in the Kickoff call.
M-1(release date for
Ensure all remaining issues in
m-1 have either been moved to
m or to a later milestone for reprioritization at a later time.
|EMs and PM||PM||Assignees|
By using the planning board as a priority list, and by keeping it in order, then we should always be able to look at the current and upcoming milestone columns to have a prioritized list of upcoming work.
We only use issue weights when we have to move an issue from one milestone to the next. This is to help us understand how much remaining work we have for any issue that had to move. For example, we may schedule an issue that just needs a final review differently than an issue that has not been started. We use a simple 1 to 10 scale to estimate the remaining work:
|10||100% Remaining/Not Started|
While we try to keep our process pretty light on meetings, we do hold a Monitor APM Weekly Meeting to triage and prioritize new issues, discuss our upcoming issues, and uncover any unknowns.
The purpose of our async standups is to allow every team member to have insight into what everyone else is doing and whether anyone is blocked and could use help. This should not be an exhaustive list of all of your tasks for the day, but rather a summary of the major deliverable you are hoping to achieve. All question prompts are optional. We use the geekbot slack plugin to automate our async standup in the #g_monitor_standup_apm channel. Every team member should be added to the async standup by their manager.