Skip to content

New structure for Strategy Programs

This is the suggested structure for the Strategy Programs subgroup that will allow us to manage them consistently and streamline our workflows. Exemplified implementation with 2 initiatives.

Subgroups: Education | Contributors

Each program is logged as a project and includes:

  • A readme including brief description and overview, a link to the corresponding handbook page and main CTAs (e.g. join form)
  • Template for intake with automated labelling (see below) and user assignment

Projects: GitLab for Education | Co-create

Intake templates help create standardized issues for each submission. An instance of an initiative (e.g. Codepath, Co-create workshop with customerX) becomes an epic once it is accepted so that multiple related issues (related discrete tasks) can be grouped.

Groups & subgroups by category

  • Strategy Programs (developer-relations/strategy-programs)
    • Contributor (developer-relations/strategy-programs/contributor)
    • Open Source (developer-relations/strategy-programs/open source)
    • Education (developer-relations/strategy-programs/education)

Projects by program

Every program is represented as a project that falls under a subgroup category.

  • Contributor
    • Co-Create Program
    • Notable Contributor Program
  • Education
    • GitLab for Education Program
  • Open Source
    • GitLab for Open Source Program

Group ping

  • @gitlab-org/developer-relations/strategy-programs (5 members)
    • Note: currently this option falls lower on the dropdown suggestions when typing out "@Strategy programs" because of the old groups under gitlab-com

Boards

Note: these are all drafted WIP and do not accurately reflect all issues or team member capacity. Once finalized we can appropriately label and move issues/epics to make this up to date.

Main group view: Strategy Programs (/strategy-programs)

Program specific view:

Subgroup category view:

We could add epic boards & issue boards at the subgroup level (Open Source, Contributor, Education) if necessary.

Issues

Status

Update: changing start to new for default issue status.

  • /status new - Starting point for newly submitted issues
  • /status refinement - Requires more information
  • /status validation backlog - Good idea but not prioritized now
  • /status planning breakdown - WIP, planning
  • /status in dev - WIP, executing
  • /status blocked - Progress is blocked and requires escalation with the team.
  • /status complete

There is not a Status for "scheduling" like the workflow label (workflowscheduling)

Duplicates and declined proposals are closed (duplicates should be closed with link to open issue)

Labels

Workflow

Update: deprecating use of workflow labels on issue in favor of using status field.

Time

FYXX::QX - Corresponding to Fiscal Year and Quarter when initiative will be completed

Team/program

Edited by Isa Huerga Ayza