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

graph TD

subgraph "New Requests"
OPENED["Issue Opened"]:::slate
INBOX["<strong>corpsec-status::inbox</strong><br><strong>corpsec-priority::inbox</strong><br><strong>corpsec-metric::inbox</strong><br><strong>corpsys-{system}</strong><br><strong>corpsec-team-{team}</strong><br>Evaluated daily"]:::fuchsia
AR{"Access Request"}:::slate
OPS{"Day-to-Day<br>Config & Ops"}:::slate
ENG{"Engineering<br>Project<br>(2+ Hours)"}:::slate
AR_METRIC["<strong>corpsec-metric::ar</strong>"]:::sky
AR_LOW["<strong>corpsec-priority::ar-low</strong><br>Resolved Same/Next Week"]:::emerald
AR_HIGH["<strong>corpsec-priority::ar-high</strong><br>Resolved Same/Next Day"]:::orange
OPS_METRIC["<strong>corpsec-metric::ops</strong>"]:::sky
OPS_LOW["<strong>corpsec-priority::ops-low</strong><br>Resolved Same/Next Week"]:::emerald
OPS_HIGH["<strong>corpsec-priority::ops-high</strong><br>Resolved Same/Next Day"]:::orange
TRIAGE_METRIC["<strong>corpsec-metric::triage</strong><br>Evaluated weekly"]:::sky
end

INITIATIVE{"Initiative<br>Project Plan"}:::slate
INITIATIVE_EPIC["Epic(s) Created"]:::slate
INITIATIVE_ISSUE["Issue(s) Created"]:::slate

WIP["<strong>corpsec-status::wip</strong>"]:::orange
REVIEW["<strong>corpsec-status::review</strong><br>Work is completed and<br>waiting on review or cleanup"]:::emerald
BLOCKED["<strong>corpsec-status::blocked</strong><br>Blocked for <br>technical reason"]:::red
WAITING["<strong>corpsec-status::waiting</strong><br>Waiting for business<br> or stakeholders"]:::violet
CLOSED["Issue Closed"]:::slate

subgraph "Sprint Planning"
PRIORITIZE{"<strong>Scoping and Prioritizing</strong><br>Evaluated bi-weekly"}
METRIC{"Metric"}:::sky
WEIGHT{"Weight"}:::fuchsia
BACKLOG["<strong>corpsec-status::backlog</strong><br>Evaluated bi-weekly and<br> scheduled for 2 week iteration<br>cycle based on re-prioritized<br> or upcoming due date"]:::sky
SCHEDULED["<strong>corpsec-status::scheduled</strong>"]:::yellow
PZERO["<strong>corpsec-priority::p0</strong><br>Imminent due date and<br>scheduled for current or next<br>2 week iteration cycle"]:::red
PONE["<strong>corpsec-priority::p1</strong><br>Project/task in the<br>next few weeks<br> or iteration cycles."]:::orange
PTWO["<strong>corpsec-priority::p2</strong><br>Project/task in<br>this or next quarter."]:::yellow
PTHREE["<strong>corpsec-priority::p3</strong><br>Project/task in<br>the next year."]:::sky
PINITIATIVE["<strong>corpsec-priority::initiative</strong><br>Prioritized based on<br>OKR, timeline, or parent epic."]:::violet
end

OPENED --> INBOX
INBOX --> AR
INBOX --> OPS
INBOX --> ENG
AR --> AR_METRIC
AR_METRIC --> AR_LOW
AR_METRIC ---> AR_HIGH
OPS --> OPS_METRIC
OPS_METRIC --> OPS_LOW
OPS_METRIC ---> OPS_HIGH
ENG --> TRIAGE_METRIC
INITIATIVE --> INITIATIVE_EPIC
INITIATIVE_EPIC --> INITIATIVE_ISSUE
INITIATIVE_ISSUE ----> PINITIATIVE
TRIAGE_METRIC -----> PRIORITIZE

OPS_HIGH ---> WIP
OPS_LOW ----> WIP
AR_HIGH ---> WIP
AR_LOW ----> WIP

TRIAGE_METRIC -.-> PZERO
PZERO ---> SCHEDULED
METRIC -.- PRIORITIZE
WEIGHT -.- PRIORITIZE
PRIORITIZE --> PONE
PRIORITIZE --> PTWO
PRIORITIZE --> PTHREE
PONE ---> SCHEDULED
PTWO --> BACKLOG
PTHREE --> BACKLOG
PINITIATIVE --> BACKLOG
BACKLOG --> SCHEDULED
SCHEDULED ---> WIP
WIP <--> BLOCKED
WIP <--> WAITING
WIP --> REVIEW
REVIEW --> CLOSED

classDef slate fill:#cbd5e1,stroke:#475569,stroke-width:1px;
classDef red fill:#fca5a5,stroke:#dc2626,stroke-width:1px;
classDef orange fill:#fdba74,stroke:#ea580c,stroke-width:1px;
classDef yellow fill:#fcd34d,stroke:#ca8a04,stroke-width:1px;
classDef emerald fill:#6ee7b7,stroke:#059669,stroke-width:1px;
classDef cyan fill:#67e8f9,stroke:#0891b2,stroke-width:1px;
classDef sky fill:#7dd3fc,stroke:#0284c7,stroke-width:1px;
classDef violet fill:#c4b5fd,stroke:#7c3aed,stroke-width:1px;
classDef fuchsia fill:#f0abfc,stroke:#c026d3,stroke-width:1px;

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)
View page source - Edit this page - please contribute. Creative Commons License