-
Notifications
You must be signed in to change notification settings - Fork 163
FSO Project Management within Github
This is a general overview of the KanBan system used by project managers, bug triage staff, and all contributors involved.
If you haven't done so already, you should take a look over Github's documentation over the issue ticket system to get more insight. This should also be the most up to date, as the rest of this page is mainly "working experience."
We primarily use the issue system for bug tracking but it is also used to keep track of feature requests. Feature requests should have "Feature Request:" or "FR:" in their title to distinguish them from bugs.
During busy times, we also rely fairly heavily on labels to help delegate the tasks amongst specialists. All users making a new issue should add labels (on the right side of the page) to the best of their abilities, and project managers likewise should edit the labels accordingly.
Milestones are the various release build targets. We usually keep at most two milestones active to represent the upcoming release cycle, or the one after that, so that we can determine if an issue/feature should be worked on ASAP or if it can be deffered to a later time. Issues/features that do not have a milestone are typically low priority items, but all high and critical priority items should have a milestone, and must have a milestone during a Release Cycle.
Project managers and Bug Triage staff should add relevant issues to their associated project. All issues with the bug, not a bug, and/or regression must be in the Bug Triage project, which hopefully at some point we'll get automation to do but for now its manual.
Issues can be assigned to authors either by the author themselves or by project managers who think said author is the best one for the job. Usually we prefer for authors to self-assign, but sometimes an author says they'll do the thing and forget to do the thing.
Using assignee:@me as the issue filter, or select "Everything assigned to me" within the Filter dropdown box to the left of the textbox will show all issues currently assigned to you. Using "@username" should likewise show issues assigned to that user.
Issues can have tasks within them if the issue is particularly involved. These are added to GitHub's UI whenever it sees lines in the issue's description text with a checkbox on it, which can be added with the markup of - [ ]
Task checkboxes can be marked or unmarked by the issue author or by SCP members with the appropriate permissions.
#Pull Requests
It is recommended that all PR's have an associated issue card since Github's automation seems to favor it. During a Release Cycle, an associated issue card lets us keep better track of what changes happened in the RC phase.
If a PR has a linked issue, then it doesn't need to have a label. If a PR does not have a linked issue, then the PR should have labels that accurately describe all related parts that it touches or affects within FSO. Bug fix PR's should have the bugfix label and added to the Bug Triage project as an In Progress item
PR's with milestones are not required but are recommended. We sometimes use the milestone to defer the PR to a later release if other PR's have priority.
Github's Kanban system organizes issue "cards" into columns, with the default kanban organized with 3 columns: To Do, In Progress, and Done.
Github does provide some automation to move issue and pull request cards into the appropriate column when they are linked or closed.
It is recommended that all new project Kanbans have an Information text card in each column to explain the purpose of the column, especially if the project manager wants to use a different set of columns like with the Bug Triage project.
Project managers can manually move cards between columns, but it is recommended to assign them from the issue or PR page itself from the right-hand menu.