Github Issues: Process and Procedures
"Interesting" Queries
Issues
Templates can be used for new issues, automatically mark new issues as needing triage
Our tagging / labeling of issues can be simplified
- Labels already deleted:
- New, Assigned, Post, Modified, OS: Centos7, OS: RHEL7
- Labels already consolidated:
- Low, Normal, High, Urgent -> Severity: Low | Medium | High | Urgent
- Propose to delete labels:
- Migrated from Redmine, Sprint *, Quarter *
- Move highest-number "Sprint:*" tag to "Current Sprint" first
- Propose to consolidate labels:
- Invalid -> Wontfix
- Story / Enhancement -> Feature
- Triaged / Groomed -> Triage-Needed
- Bug -> Issue
Matching up with expected Bugzilla state-transitions
- PR merged into main : BZ NEW -> POST
- PR backported to branch needed for BZ milestone and new branch-release available: BZ POST -> MODIFIED, update "Fixed in" w/ released NEVRA(s)
Project boards
Github has a more advanced set of project boards in beta e.g. https://github.com/orgs/pulp/projects/2/views/1:
These could eventually be a great way to handle triage, sprint planning, 3 month planning, tracking deliverables for various stakeholders, etc.
edit: I wrote it up more elegantly here - https://github.com/github/feedback/discussions/10611
- Boards can be public or private
- limitation: but you have to make the decision on a per-board basis, you can't just have private views on a public board
- Boards can show issues from many different repos and filter / group many different ways including by repository
- blocker: if you group by repository (which is really useful!), you cannot add new issues
Image Not Showing
Possible Reasons
- The image file may be corrupted
- The server hosting the image is unavailable
- The image path is incorrect
- The image format is not supported
Learn More →
- The automation features look great
- blocker: No way to import or view issues in bulk (each issue has to be manually added)
- blocker: No way to keep issues separate between different views (an issue added to the board will show up on all views unless you have filters set up)
- That might be reasonable except that it would presumably also mean that if you start bulk importing issues for various views it would then be impossible to curate an ad-hoc set of issues without adding labels
- Custom fields - you can annotate issues with dates, "iteration", enum/dropdown menu items, text fields, etc.
- See: Added a "bugzilla" field which then makes the link available in the sidebar on the issue itself
- limitation: the fields are per-board, so if you have the "bugzilla" field set up on a public board, you can't use it from a private board (like one we might want to use for coordinating downstream priorities)
- Easy to edit issue title / tags / whatever from the bulk view
Prognosis: great potential, but not ready yet
Other issues to track:
Triage
https://github.com/pulp/pulp_rpm/projects/1
Sprint planning
Would these work for metrics of how we did?
Sprint 112
https://github.com/search?q=org%3Apulp+is%3Apr+is%3Amerged+closed%3A2022-01-06..2022-01-20
Sprint 113
https://github.com/search?q=org%3Apulp+is%3Apr+is%3Amerged+closed%3A2022-01-19..2022-02-03
We still need something for us know what we should be working on when folks are looking for the next thing. Current Sprint or something like this.
3 month planning
you can have private boards
Opportunities for improvement