User:Bcotton/UsePagureForChanges

This document is in draft status
We're still working on this.

Use Pagure for Change Wrangling

Summary: the current Fedora Change Process involves independently-managed artifacts across a variety of platforms. This proposal aims to simplify the process to improve visibility and ease of management.

Problems with the Current Process

The current process allows contributors to propose changes in upcoming Fedora releases. However, the management of those feature proposals is cumbersome and requires several manual steps. This introduces more opportunity for error and reduces the time available to the Change Wrangler for more valuable contributions to Fedora. In particular, the current process includes artifacts and discussion in the Fedora Wiki, on mailing lists, FESCo tickets, Bugzilla tickets, and Docs tickets.

Querying and updating the wiki in a programmatic manner is challenging. The current process was developed before Pagure was available. By using Pagure, we can make the process more programmatic.

New Process

The new process will consolidate much of the information in Pagure. Proposed Changes will be submitted as an issue in the Fedora Changes repo. The description of the issue will include the content, with a few exceptions:

• System-Wide or Self-Contained change will be indicated by a binary in the issue metadata
• Fedora release will be indicated by a milestone in the issue metadata
• Change status will be indicated by a list selection in the issue metadata

Workflow

1. Change Owner creates a new issue in the Fedora Changes repo.
2. Change Owner sets the Ready for Wrangler status on the issue when it is ready.
3. Change Wrangler reviews the change for completeness.
4. Change Wrangler' announces changes on mailing lists for discussion and changes status to "Announced". Discussion occurs on the devel mailing list.
5. Change Wrangler creates FESCo ticket after waiting period and changes status to Ready for FESCo
6. FESCo votes on change.
7. Change Wrangler collects votes and updates status to "Accepted" or "Rejected"
8. Change Wrangler closes Rejected Changes. Change Owner may re-open issue to address rejection reasons or to resubmit for the next release.
9. Change Wrangler creates new issue in the Release Notes repo for Accepted changes and sets the Release Notes needed flag on the change issue.
10. Change Wrangler creates a Bugzilla tracking bug. Bugzilla will be considered deprecated for Change tracking and this step will be removed in a future release.
11. Change Wrangler coordinates with Change Owner and Docs Team to track the status of changes
    1. Change Wrangler clears the Release Notes needed flag when the Docs Team completes the release notes
    2. Change Owner set the implementation status to Ready for testing when the change is ready for testing (this should be done by Beta)
    3. Change Owner sets the implementation status to Complete when the change is complete
    4. Change Wrangler sets the At Risk flag if the change may not complete on schedule
    5. Change Wrangler updates the milestone to the next release if the change slips
    6. Change Wrangler closes the issue with a status of Canceled if the change is canceled
12. Change Wrangler monitors status of changes and works with FESCo and Change Owner to delay changes that do not meet deadline.

Advantages

• Pagure repo becomes a consolidated source for change information
  • Eliminates Wiki and Bugzilla as artifact locations
• Workflow steps can be more easily scripted because change metadata is partially separated from content
• Automatic report generation is easier
• This provides a foundation for more future iteration on the process (e.g. by having FESCo vote on the change ticket directly).
• Separate templates for System-Wide and Self-Contained changes will simplify change submission for contributors.

Disadvantages

• Still requires changes be represented in three different Pagure repos
• Pagure date reporting is not robust (e.g. a comment left on the issue will change the modified timestamp of the issue). This will require more careful scripting for time-based reports (e.g. by using a manually-assigned due date)
• External processes that depend on Bugzilla tickets (if any?) will need to be adjusted
• We lose edit history if a change proposal is updated based on feedback

Technology changes

Pagure repo setup

Add the following metadata fields:

• Due date — text field
• System Wide change — boolean
• Summary — text field
• FESCo ticket — text field (URL)
• Release notes ticket — text field (URL)
• Bugzilla — text field (URL)
• Summary — text field
• Proposal status — list: Ready for Wrangler, Announced, Ready for FESCo, Accepted, Rejected
• Implementation status — list: In Progress, Ready for testing, Complete, Canceled
• Flags — Release Notes needed, At Risk
• Releng ticket — text field (URL)
• Trademark approval required — boolean
• Owners — text field

Pagure features

• Add the ability to create dependencies between issues in different repos — Allows links to docs and FESCo tickets. Workaround: manually include links in comments. Requested as Pagure issue 3409.
• Add 'Due Date' as an issue field — Allows easier reporting of issues based on due date. Workaround: use a text string formatted as an ISO-8601 date. Requested as Pagure issue 3410.
• Add edit history for issues — Allows visibility of how a Change has evolved in response to feedback. Requested as Pagure issue 3408.
• Allow all authenticated users to enter metadata — Allows Change owners to edit required metadata fields. Requested as Pagure issue 3500.

Changes handling script

• bcotton to write a script that will handle:
  • querying for changes that need action
  • announcing changes
  • creating FESCo tickets changes
  • creating Bugzilla and Release notes tickets
  • generating HTML reports of change status
  • generating ChangeSets