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/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-


Reply via email to