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

["Michael D Kinney" <michael.d.kinney@intel.com>]

Hi Michael,

Thank you for the detailed proposal.  Overall looks like a great
start.  Some comments included below.  I would be in favor of 
moving in this direction as soon as possible.

I would like to hear if there are any objections to this proposal
from any community members so those can be addressed quickly.

Mike

> -----Original Message-----
> From: Michael Kubacki <mikuback@linux.microsoft.com>
> Sent: Friday, July 19, 2024 2:20 PM
> To: devel@edk2.groups.io; rfc@edk2.groups.io
> Cc: 'Andrew Fish' <afish@apple.com>; 'Leif Lindholm'
> <quic_llindhol@quicinc.com>; Kinney, Michael D
> <michael.d.kinney@intel.com>; 'Sean Brogan' <sean.brogan@microsoft.com>
> Subject: [RFC] Transitioning from Bugzilla to GitHub Issues
> 
> 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

Would this be free form text or a multi select list of possible packages?

>         * Current Behavior
>         * Expected Behavior
>         * Steps to Reproduce
>         * Build Environment
>           * Host Information (if applicable) such as OS and Tool Chain
>             and/or container information

Would this be free form text or a multi select list of allowed options?

>           * Target Information (if applicable) such as DEBUG/RELEASE,
>             architecture, and relevant features enabled

Would this be free form text or a multi select list of allowed options?

>         * 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

Would this be free form text or a multi select list of allowed options?

>         * 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

Would this be free form text or a multi select list of allowed options?

Some documents are not package specific such as the build system related documents.
Would the target spec be the right value here?

>         * 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:
> 

This set looks good.  Please add brief descriptions of that each label represents.

>     * 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.

Is milestone and release the same thing?  Should we just use "release"
Terminology?  Or is there a needs to define one or more milestones
Between releases?

> 
> 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.

Bugzilla supports attachments.  How will attachments be migrated to a GitHub issue?

Bugzilla also contains bugs that apply to may different GitHub repos.  Will 
all of the Bugzilla issues across all repos be migrated at the same time
so Bugzilla can be converted to read-only for all issue types on the same
date?

> 
> 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 (#120069): https://edk2.groups.io/g/devel/message/120069
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]
-=-=-=-=-=-=-=-=-=-=-=-