[edk2-devel] [RFC] Transitioning from Bugzilla to GitHub Issues

["Michael Kubacki" <mikuback@linux.microsoft.com>]

Hello,

A topic over the last few weeks in the TianoCore Tools & CI meeting has 
been establishing a transition from Bugzilla to GitHub issues. I've 
drafted the following RFC to help explain the rationale and a proposed 
process to do so.

I think it is easier to read with formatting, so I've placed a version 
in the following link that is open to comments in the GitHub discussion. 
I recommend reading this version.

https://github.com/tianocore/edk2/discussions/5926

---

I've also copied that content below if you prefer to read and respond 
directly to the email.

---

Background
----------

TianoCore currently uses Bugzilla as its issue tracking system. However, 
with the recent transition from a mailing list
based code contribution process to GitHub pull requests, there is a 
growing need and value to consolidate development
activities on a single platform.

This RFC proposes a process for transitioning from Bugzilla to GitHub 
issues to improve issue tracking and engagement.
Feedback is welcome to refine the process in a way that best meets the 
needs of the TianoCore community.

General information about GitHub issues is available in the GitHub 
Issues Guide.

Advantages of GitHub Issues
---------------------------

* Automation

   * GitHub issues can use the same GitHub action based automation as
     pull requests, enabling the process to be more tailored to the
     project's needs. The same GitHub REST API can also be reused
     allowing for reuse of external automation tools and scripts that are
     used with extracting pull request information.

   * An example already in use in edk2 PRs today is the stale bot which
     auto closes stale PRs to reduce review noise and keep open issues
     relevant.

* Centralization of Issue Activity

   * GitHub issues automatically track the places they are mentioned such
     as comments, commits, and pull requests. This provides a central
     location for tracking the discussion and related work for an issue.

* Collaboration Features

   * GitHub issues support features like labels, milestones, and project
     boards, that enable better organization and tracking of issues if
     leveraged by the community.

* Consistent User Account

   * Users can use the same account for both code contributions and issue
     tracking, making it easier to identify and track that developer's
     contributions and related activities.

* Financial Cost Savings

   * Bugzilla requires dedicated hosting provided by TianoCore members.
     GitHub issues use the exact same infrastructure already used for
     code hosting with no additional cost.

* Dev Tool Support

   * Many of the tools already being used for GitHub based development
     support integrated issue tracking such as VS Code GitHub issue
     integration.

* Ease of Access

   * GitHub issues are accessible to anyone with a GitHub account,
     simplifying the registration and tracking process.

* Emoji and Reaction Support

   * Community members can quickly vote on issues so the most upvoted can
     be sorted for awareness and prioritization. Emoji and reaction data
     can be externally queried and exported via the GitHub REST API.

* Integration with Git

   * GitHub issues are tightly integrated with Git repositories, making
     it easier to reference commits and individual code changes with
     permalinks.

* Issue Templates

   * GitHub issues support templates, enabling standardization of issue
     reporting and customized validation in the template.

* Longer Lived Accounts

   * Even after users leave their companies, their GitHub accounts remain
     active, reducing the loss of user history and accessibility to that
     user in the future.

* Markdown Support

   * GitHub issues support Markdown formatting, allowing for rich text
     formatting and embedding of images and links. This provides a
     consistent experience with the PR process.

* Pull Request Automation

   * GitHub issues can be linked to pull requests simply by including the
     issue number in the pull request description, enabling better
     tracking and visibility. The issue will automatically close when the
     pull request is merged preventing dangling issues.

* Visibility

   * GitHub issues are more visible to developers and users who are
     already using GitHub for code development. The number of active
     issues is visible at the top of the repository page.

Goals
-----

1. More issues will be filed since registration and access is
    consolidated with the code repository.
2. Issues will have more relevant and frequently updated information due
    to the built-in integration to the repo code and pull requests.
3. The submission process will be streamlined with better opportunities
    for automation and customization.
4. Ultimately, developers will need to spend less effort to track and
    manage issues over time using built-in linking and auto close
    features.

Proposed Process
----------------

1. Create GitHub issue templates for the following categories that 
include basic automation of validation for input.

    * Bug Report

      * Fields:
        * Title
        * Packages Affected
        * Current Behavior
        * Expected Behavior
        * Steps to Reproduce
        * Build Environment
          * Host Information (if applicable) such as OS and Tool Chain
            and/or container information
          * Target Information (if applicable) such as DEBUG/RELEASE,
            architecture, and relevant features enabled
        * Version Information
          * Commit SHA or stable tag
        * Urgency
          * Low
            * A minor change with little to no important functional
              impact
            * It is not important to fix this in a specific time frame
          * Medium
            * An important change with a functional impact
            * Will be prioritized above low issues in the normal course
              of development
          * High
            * A critical change that has a significant functional impact
            * Must be fixed immediately
        * Are you planning to submit a PR?
          * Yes
          * No
        * Do you need maintainer feedback?
          * Yes
          * No
        * Additional information including attachments (optional)

    * Feature Request

      * Fields:
        * Title
        * Packages Affected
        * Feature Overview
        * Proposed Solution
        * Alternatives Considered (optional)
        * Urgency
          * Low
            * A minor enhancement
            * It is not important to address this request in a specific
              time frame
          * Medium
            * An important enhancement
            * Will be prioritized above low requests in the normal course
              of development
          * High
            * A critical enhancement with significant value
            * Should be prioritized above low and medium requests
        * Are you planning to implement this feature?
          * Yes
          * No
        * Do you need maintainer feedback?
          * Yes
          * No
        * Additional information including attachments (optional)

    * Documentation Request

      * Fields:
        * Title
        * Packages Affected
        * Request Description
        * Are you going to make the change?
          * Yes
          * No
        * Do you need maintainer feedback?
          * Yes
          * No
        * Additional information including attachments (optional)

2. Automatically apply labels to the issue based on submission
    information:

    * Type
      * Bug Report
        * type:bug
      * Feature Request
        * type:feature-request
      * Documentation Request
        * type:documentation-request

    * Urgency
      * Low
        * priority:low
      * Medium
        * priority:medium
      * High
        * priority:high

    * State
      * Maintainer Feedback Requested
        * state:maintainer-feedback-requested
      * Submitter Not Planning to Complete
        * state:needs-owner

3. Define GitHub labels that can be manually added:

    * Duplicate
      * state:duplicate

    * Help Wanted
      * state:help-wanted

    * Insufficient Submitter Information
      * state:needs-submitter-info

    * Decision Not to Fix
      * state:wont-fix

    * Issue is Understood But Invalid
      * state:invalid

    * Issue is Not Actively Being Fixed
      * state:backlog

      * Note: This would also prevent the stale bot from closing the
        issue due to inactivity.

4. Define GitHub milestones for the upcoming three edk2 stable tags so
    that issues can optionally be tracked against those milestones.

    Note: The milestone box is a simple drop down that allows for easy
          selection of defined milestones.

5. Enable basic GitHub actions for GitHub issues:

    * Automatic application of labels based on issue template input at
      time of issue creation.

    * Daily check for issues that have not been updated in 45 days to
      apply the state:stale label (already used for pull requests in
      edk2) and leave a warning comment. If still no activity in 7 days,
      close the issue with a comment that it can be reopened if the issue
      is still relevant.

6. Stage updates to the TianoCore documentation to reflect the new
    process and provide a user guide for transitioning to GitHub Issues
    from Bugzilla.

7. Establish a date to begin accepting GitHub issues and disable the
    creation of new issues in Bugzilla. This RFC proposes the date of
    Monday, August 26, 2024 the following business day after the 202408
    stable tag is released.

8. Communicate this date to the community alongside the staged
    documentation.

9. Enable GitHub issue submission in edk2 on the transition date.

10. Learn from GitHub issue usage and adjust the process as needed.

11. During this first one month, review open issues in Bugzilla to
     determine if they are still relevant and if so, transfer them to
     GitHub issues. Close the Bugzilla issue with a link to the new
     GitHub issue. This is possible to do programmatically.

12. Manually review the transferred issues to ensure accuracy and
     completeness.

Additional Resources
--------------------

* GitHub Issues Documentation: [GitHub Issues 
Guide](https://docs.github.com/issues)
* Tracking Work with GitHub Issues: [GitHub Issues - About 
issues](https://docs.github.com/issues/tracking-your-work-with-issues/about-issues)
* GitHub Markdown Guide: [Mastering 
Markdown](https://guides.github.com/features/mastering-markdown/)

---

Thanks,
Michael


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#119986): https://edk2.groups.io/g/devel/message/119986
Mute This Topic: https://groups.io/mt/107442879/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-