User:Bcotton/UsePagureForChanges

DRAFT

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.

Current Process

The current process includes artifacts and discussion in:

• Fedora Wiki
• mailing lists
• FESCo ticket
• Bugzilla ticket
• Docs ticket

This creates a lot of management overhead, introduces opportunities for errors, and inhibits visibility.

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" (this can be scripted, e.g. fedora_changes announce 3). Discussion occurs on the devel mailing list.
5. Change Wrangler creates FESCo ticket after waiting period and changes status to Ready for FESCo (this can be scripted)
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. (this can be scripted)
10. 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 Wrangler sets the status to Complete when the change is complete
    3. Change Wrangler sets the status to At Risk if the change may not complete on schedule
    4. Change Wrangler updates the milestone to the next release if the change slips
    5. Change Wrangler closes the issue with a status of Canceled if the change is canceled
11. 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 single 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

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

• Add the ability to create dependencies between issues in different repos — Allows links to docs and FESCo tickets. Workaround: manually include links in comments.
• 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.
• Add edit history for issues — Allows visibility of how a Change has evolved in response to feedback