How We Work (CorpSec)

We have four approaches to how we work:

  1. Support Helpdesk Services - We provide 24x5 technical support and access requests for team members and temporary service providers (contractors). Please help us prioritize your access request with corpsec-priority::ar-high (same/next day) or corpsec-priority::ar-low (same/next week) label.

  2. Configuration Operations - We handle day-to-day small configuration and change requests (less than an hour) for configuring the SaaS systems that CorpSec is responsible for. This also includes escalations from our helpdesk analysts. Please create an issue in our issue tracker with your request and add the corpsec-priority::ops-high (same/next day) or corpsec-priority::ops-low (same/next week) label. You can ask for preliminary guidance in #it_help and our on-call team members will respond and/or tag an appropriate engineer.

  3. Engineering Iterations - We have two week agile iteration sprint cycles for handling larger requests (more than an hour) that are queued up based on our team’s capacity and competing priorities. This includes pre-planned implementation work related to other team’s projects. When an issue is created, we will assign it a priority based on your due date requirements and add it to the backlog or schedule it during an upcoming iteration. Once an issue has been added to an iteration, you can expect it to be completed by the last day of the 2 week cycle unless communicated otherwise in the issue or in a discussion with the assigned engineer.

    Please create issues as far in advance as possible (3-6 weeks ideally, even as a draft) so it gets in the queue, rather than last minute requests that cause team members to scramble in a crisis mode. We are trying to avoid situations when your team knows about it for several months and ask us at the last minute to turn something around in a day or two with a deadline that could have been communicated several weeks in advance.

  4. Engineering Initiatives - Larger program managed strategic initiatives on our roadmap that are part of our long term direction. We have objectives and key results (OKRs) that are aligned with the research, discovery, implementation, and migration to the new processes, services, systems. See our epics to see the current initiatives and progress.

Epics

All epics for larger initiatives and OKRs are created in the CorpSec group.

You can also view our gantt chart roadmap.

Issue Tracker

All issues are created in the CorpSec issue tracker for work that we have to either spend significant time performing or perform configuration and provisioning work that we need an easy-to-discover audit trail for. We can also be tagged in other team’s issue trackers for consultative questions and support.

Workflow

Sprint Planning

New Requests

Issue Opened

corpsec-status::inbox
corpsec-priority::inbox
corpsec-metric::inbox
corpsys-{system}
corpsec-team-{team}
Evaluated daily

Access Request

Day-to-Day
Config & Ops

Engineering
Project
(2+ Hours)

corpsec-metric::ar

corpsec-priority::ar-low
Resolved Same/Next Week

corpsec-priority::ar-high
Resolved Same/Next Day

corpsec-metric::ops

corpsec-priority::ops-low
Resolved Same/Next Week

corpsec-priority::ops-high
Resolved Same/Next Day

corpsec-metric::triage
Evaluated weekly

Initiative
Project Plan

Epic(s) Created

Issue(s) Created

corpsec-status::wip

corpsec-status::review
Work is completed and
waiting on review or cleanup

corpsec-status::blocked
Blocked for
technical reason

corpsec-status::waiting
Waiting for business
or stakeholders

Issue Closed

Scoping and Prioritizing
Evaluated bi-weekly

Metric

Weight

corpsec-status::backlog
Evaluated bi-weekly and
scheduled for 2 week iteration
cycle based on re-prioritized
or upcoming due date

corpsec-status::scheduled

corpsec-priority::p0
Imminent due date and
scheduled for current or next
2 week iteration cycle

corpsec-priority::p1
Project/task in the
next few weeks
or iteration cycles.

corpsec-priority::p2
Project/task in
this or next quarter.

corpsec-priority::p3
Project/task in
the next year.

corpsec-priority::initiative
Prioritized based on
OKR, timeline, or parent epic.

Iteration Cadences

We perform sprint planning on a weekly or bi-weekly basis (depending on system/team) and evaluate issues with the corpsec-status::inbox and corpsec-status::backlog label.

See the Workflow to see the full flow of issues.

Due Dates

Due dates are the date set by the requester.

Iteration cycles are used by the CorpSec team internally.

Any expectations should be mentioned in the issue description or comments so the work is completed in an iteration cycle that ends before your due date.

Issue Boards and Lists

Helpdesk Analysts

Engineering

Engineering Team Members

Team Member CorpSec Issues Assigned ARs Handbook MRs
Adam Huss Issues - Kanban - Current Iteration ARs Public - Internal
Clayton Shank Issues - Kanban - Current Iteration ARs Public - Internal
David Zhu Issues - Kanban - Current Iteration ARs Public - Internal
Eric Rubin Issues - Kanban - Current Iteration ARs Public - Internal
Erik Lentz Issues - Kanban - Current Iteration ARs Public - Internal
Jacob Waters Issues - Kanban - Current Iteration ARs Public - Internal
Jeff Martin Issues - Kanban - Current Iteration ARs Public - Internal
Justin Bisutti Issues - Kanban - Current Iteration ARs Public - Internal
Kim Waters Issues - Kanban - Current Iteration ARs Public - Internal
Marcus Whitaker Issues - Kanban - Current Iteration ARs Public - Internal
Mark Loveless Issues - Kanban - Current Iteration ARs Public - Internal
Mohammed Al Kobaisy Issues - Kanban - Current Iteration ARs Public - Internal
Vlad Stoianovici Issues - Kanban - Current Iteration ARs Public - Internal
Zack Hardie Issues - Kanban - Current Iteration ARs Public - Internal

Time Tracking

When issues are prioritized and scheduled to be worked on, they can optionally have a time estimate added (in hours) using /estimate {##}h. This allows the engineer to be a manager of one and work on the issue however they see fit by the iteration end date.

As engineers work on issues, they can optionally add /spent {1.5}h to keep track of their progress. This is optional has two benefits:

  1. It allows the engineer to validate whether the time estimate was accurate.
  2. It surfaces to the management team how much work was put into the issue.

Any issue that an engineer adds a time spent to will automatically show up on management and team status reports with the title and time spent. Any issue without a time spent will show up on status reports with the count of issues worked on in a specific project. A best practice is that if it takes more than 30-60 minutes, you should consider adding time spent. If something is important that should appear on a status report, then even a 5 minutes of time spent can be added.

See weight as an alternative to time tracking.

Weight

Some engineers do not like tracking their time and just see the list of issues to work on.

Instead of time tracking, you can add a weight to share how difficult it was to work on. Weights are also used during sprint planning.

1 weight is equal to roughly a half day of work (ex. a 3-4 hour focus block).

Any issue that an engineer adds a weight to will automatically show up on management and team status reports with the title and weight along with a time estimate if it was set. Any issue without a weight will show up on status reports with the count of issues worked on in a specific project. A best practice is that if it takes more than an hour or two, you should consider adding a weight.

Labels

Status Label

  • corpsec-status::inbox - This issue is new and has not been evaluated yet. (default for new issues).
  • corpsec-status::wishlist - For any issues not being worked on in the next year or become dormant. Stale issues can be closed and can be reopened if priority changes.
  • corpsec-status::backlog - This issue is in our backlog to be completed within a year (see priority).
  • corpsec-status::waiting - This issue has started but is on hold waiting for a business reason or review. Waiting issues get attention of managers.
  • corpsec-status::blocked - This issue has started but is blocked for a technical reason. Blocked issues get attention of engineers.
  • corpsec-status::scheduled - This issue has been scheduled to be worked on in an upcoming iteration milestone.
  • corpsec-status::wip - This issue is a work in progress. The team member will assign this status when they pick it up.
  • corpsec-status::review - The work is mostly complete and is waiting on final review or cleanup work.

Priority Label

Metric

To help reporting with what issues are related to since we share the same issue tracker and epics, you can add labels for categorizing the type of work.

Team Label

See the functional org chart to learn more about our teams and the services or systems that each team manages.

These labels are subscribed to be respective team members to get notifications for issues instead of needing to carbon copy (CC) or mention team members in issues, and are also used for any issues to identify which team is working on it. These labels are included in many issue templates. These labels can be added to any epic or issue anywhere in gitlab.com/gitlab-com. We do not use scoped labels since multiple teams may need to work on the same issue.

These are used for broad teams and not specific systems. Please check if a system label is appropriate to directly notify the system owners.

System Label

These labels are subscribed to be respective team members to get notifications for issues instead of needing to carbon copy (CC) or mention team members in issues, and are also used for any issues to identify which system the issue relates to. These labels can be added to any epic or issue anywhere in gitlab.com/gitlab-com. We do not use scoped labels since multiple systems may be worked on in the same issue.

For broader needs, see the team labels.

Approvals

Last modified August 16, 2024: Replace aliases with redirects (af33af46)