Workflow
This page introduces how we cope with issues in the tracker, note that Bugzilla bug statuses enlighten the labels we are using.
- Owner determine if text in issue(s) are useless, including, but are not limited to, twaddle, spamming, personal abuse, advertise, dicussion regardless of this repo.
- Owner determine type(s) of issue(s). Generally,
Assigneewill be taken by an owner of the repo,ASSIGNEDlabel will be taken as well. - Checking the URLs for the first time. Start tracking with
TRACKINGlabel. - If assignee can confirm the report immediately, label
CONFIRMEDwill be applied, otherwise heading into tracking stage,NEEDINFOmay needed if there are unclear description of issue(s), or obstacles which blocks checking. - Results pertinent to issue(s) will be posted one by one, labels based on results will be applied subsequently.
- Determine if
NEEDINFOis still needed for issue(s) to ask for more useful information. - Determine if
TRACKINGis needed for issue(s) to track longer on specific URLs to get more details. - Determine if
TODOis needed for issue(s), this often means issue can't be solved instantly.
- Determine if status of reports have changed.
- Apply
WORKINGlabel to issue(s). - Modify the list, update the list checksum, commit to repo with message
gfwlist edited: $(date). - (Optional) Signing commit(s).
- Pushing.
- Mention issue number(s) in each commit.
- Remove labels of issue(s), status labels, e.g.
FIXED,INVALID, will be applied. - Closing issue(s).
- (Optional) Locking issue(s).
