Project Management

This page describes details for our project management.

Definition of Done

  • Issue created in Jira with a clear description.

  • Labels added to issue.

  • Release versions set on issue - both quarter scope and product release if relevant.

  • Work items completed.

  • Work products linked to Jira issue (eg: code change, released software, blog, research report).

  • Acceptance Criteria was met.

  • Work products reviewed by Testing Farm team and stakeholders.

  • Feedback from review implemented and all stakeholders satisfied.

Please see the Contribution Guide for details about tools, code, and style.

Jira Issues

Testing Farm is managed via Jira available at https://issues.redhat.com/browse/TFT. The instance is currently Red Hat only, we are talking about opening up the issues to the public.

All issues must use the following types:

  • Epic - for large features, consisting of multiple issues

  • Story - for new features and user stories

  • Bug - for bug fixes

  • Task - for other tasks

Using subtasks is optional. Subtasks should not set any labels or be in any releases. In case a subtask should be in release, convert it to a regular issue.

Story Points

As the team, we agreed on the following story points estimation for our team.

Story Points Complexity Risk Uncertainty Time Effort

1

Task is extremely simple to do. There is a minimal amount of work that needs to be done.

Low.

None. No consultation needed.

Takes an hour or less.

4

Task is simple to do. The acceptance criteria are short and can be satisfied with ease.

Low.

None. No consultation needed.

Takes a few hours.

8

Task is fairly simple, but can have some smaller complex parts. The acceptance criteria are short and can be satisfied with ease.

Medium.

Little. May need consultation.

Takes a day.

40

Task has more complex parts, but should still be manageble. The acceptance criteria are larger, but well understood. Most probably should be split into subtasks for better tracking.

High.

Medium. Will need consultation or multiple consultations.

Takes a week.

160

Task is very complex. Cannot be delivered as is and must be split into smaller tasks.

High.

Team has fuzzy idea how long will it take.

Takes a month or more months.

Estimation

The story points can be set by the ticket assignee or discussed on team meeting in more uncertain cases.

Because our story points are based on a time work estimation (in hours), we estimate using the following principles:

  • The time in hours we estimate to spend on activities to resolve the issue, i.e. coding, writing documentation, discussion, getting more information from peers, resolving review comments, investigating and resolving CI issues caused by the change, etc.

  • We exclude from the estimate waiting times, i.e. waiting for CI pipelines to finish, waiting for outages, waiting for blocker issues to resolve, waiting for reviews etc.

  • The time during these events should be ideally spent on other tasks.

The Epic Jira issue type does not have an estimation. When another Jira issue type is converted to an Epic, the estimation will be removed by Jira automation.

Acceptance Criteria

Following acceptance criteria is automatically added to all Jira issues:

(off) Feature or Bug Fix is implemented
(off) Deliverables reviewed
(off) Unit tests were created or updated
(off) Integration tests created or updated
(off) Deployed to all environments
(off) Configuration added/changed and cherry-picked to production
(off) Documentation written or updated
(off) Release notes updated

Acceptance criteria can be extended with a checklist of subtasks in case you do not want to use subtasks for this.

Following states are allowed for the acceptance criteria items:

(off) not started
(on) started
(/) done
(-) not applicable

Jira Labels

This is a list of agreed labels to be used with our issues.

Service related:

  • BaseOS-CI

  • TestingFarm

Workflow related:

  • ErrorBudget

  • Escalation

  • KnownIssue

  • NeedsTriage

  • NewFeature

  • Release

Planning related:

  • BucketCommunity - Address public issues, support Fedora community, address tmt MR queue, organize TTI mini-summit, presentations, etc.

  • BucketContinuity - Continuing to run the business, supporting existing onboarded users and improving experience of the service for them.

  • BucketEffectivity - Improving effectivity of the team, like onboarding new team members and longer term code contributors, improving automation, etc.

  • BucketMigration - Migrating users to Testing Farm or implementing new features, so they can onboard.

  • BucketStrategic - Supporting strategic initiatives like Image Mode, RHEL on GitLab, RHEL on Konflux or RHEL AI.

  • BucketTechnicalDebt - Addressing bugs or technical debt in our code.

Event related:

  • Gathering

  • DevConf

  • QECamp

General components:

  • Composes

  • Infrastructure

  • Monitoring

  • ProdSec

  • ProjectManagement

  • ReportPortal

  • tft-admin

  • tmt

  • STI

Testing Farm components:

  • API

  • Artemis

  • Artifacts

  • CLI

  • Oculus

  • Worker

  • PublicRanch

  • RedHatRanch

Gluetool related:

  • Gluetool

  • GuestSetup

BaseOS CI components:

  • Covscan

  • Restraint

  • IntegrationTests

  • wow

Users:

  • convert2rhel

  • CRC

  • FedoraCI

  • ImageBuilder

  • JavaQE

  • KernelQE

  • KVMQE

  • OSCI

  • Packit

  • RHCOS

  • ImageModeRHEL

  • RHIVOS

  • SecureSign

  • SystemRoles

  • Upgrades

  • VirtQE

  • Zuul

Cloud related:

  • AWS

  • Azure

  • Beaker

  • GCP

  • IBMCloud

  • Openstack

Extended issue type:

  • BestPractice

  • BreakingChange

  • Contribution

  • Cost

  • Demo

  • Documentation

  • Presentation

  • Regression

  • TechnicalDebt

  • Usability

  • UserRequest

Tickets we want to monitor in other jira projects than TFT:

  • TFT