Verify:Runner Core

The Runner Core team page.

Product Strategy and Roadmap

The product strategy and roadmap for the runner product categories are covered on the following direction pages.

Team Members

The following people are permanent members of the Verify:Runner Core group:

Name Role
Adebayo AdesanyaAdebayo Adesanya Engineering Manager, Runner:Runner Core
Arran WalkerArran Walker Senior Backend Engineer, Runner:Runner Core
Ashvin SharmaAshvin Sharma Backend Engineer, Runner:Runner Core
Love BhardwajLove Bhardwaj Backend Engineer, Runner:Runner Core
Staff Backend EngineerStaff Backend Engineer Staff Backend Engineer, Runner:Runner Core
Taka NishidaTaka Nishida Senior Backend Engineer, Runner:Runner Core
Timo FurrerTimo Furrer Staff Backend Engineer, Runner:Runner Core
Vishal TakVishal Tak Staff Backend Engineer, Runner:Runner Core

Stable Counterparts

Name Role

Development Process

Planning and Tracking

The issues in progress or scheduled for the current milestone can be tracked at Milestone Board.

This board contains all the necessary columns to track the workflow of the team, showing:

  • All issues in the current milestone
  • Issues organized by their GitLab status (“Ready for Development”, “In dev”, “In review”, “Closed”, etc.)

Once a team member self-assigns an issue on the Milestone Board, the issue status should be updated according to GitLab’s native issue statuses to reflect the current state of work.

Upcoming Work

Issues planned for upcoming releases can be viewed in:

Features We Maintain

Runner Core maintains other feature categories apart from developing and advancing GitLab Runners.

The following categories are in maintenance mode:

  • Auto DevOps
  • Deployment Management
  • Environment Management
  • Infrastructure as Code

We does this mean? It means we typically only prioritize issues that met at least one criteria below:

  • All Security Vulnerabilities
  • S2+ Bugs, Availability/InfraDev and Scalability issues
  • Error Budget related issues
  • Customer Escalations prioritised by the Product Manager

🔍 Spike Issues for Complex Work

If a task is too large, has too many unknowns, or requires proof of concept (POC), it should be broken down into smaller investigation tasks or POC issues. These tasks help clarify the scope, reduce risks, and identify the necessary steps to proceed with implementation.

Create an Investigation Issue

  • Purpose: Research, investigate, and document or breakdown the necessary work. Clearly define the core question or problem you’re investigating.
  • Label: Assign the ~spike label to the issue.
  • Blocking Relationship:
    • For issue investigations: Mark the investigation as blocking the original issue.
    • For epic investigations: Add the investigation issue to the epic.

Close the Investigation

  • Align with key stakeholders on findings and next steps. Consider using a sync meeting to make decisions together.
  • Depending on the feedback, we can decide to allocate more time or settle for something that works based on the information we have.
  • For Issue Investigations: Summarize findings in the investigation issue. The outcome should inform the implementation of the blocked issue. Update the blocked issues to now include a clear direction and acceptance criteria.
  • For Epic Investigations: Break down and refine the epic into actionable issues. The outcome could include:
    • Architecture Plan: High-level technical direction, quality goals (like performance, security), and supporting approaches.
    • Iteration Plan: A breakdown of work into clearly scoped, refined issues.
    • Add the plans to the epic description and close the investigation issue.