1

Workflow

Christopher Meng edited this page 2016-01-10 14:27:02 +08:00

Table of Contents

• Workflow of GFWList
• Initial stage
• Sorting stage
• In progress stage
• Done stage

Workflow of GFWList

This page introduces how we cope with issues in the tracker, note that Bugzilla bug statuses enlighten the labels we are using.

Initial stage

1. 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.
2. Owner determine type(s) of issue(s). Generally, Assignee will be taken by an owner of the repo, ASSIGNED label will be taken as well.
3. Checking the URLs for the first time. Start tracking with TRACKING label.
4. If assignee can confirm the report immediately, label CONFIRMED will be applied, otherwise heading into tracking stage, NEEDINFO may needed if there are unclear description of issue(s), or obstacles which blocks checking.
5. Results pertinent to issue(s) will be posted one by one, labels based on results will be applied subsequently.

Sorting stage

1. Determine if NEEDINFO is still needed for issue(s) to ask for more useful information.
2. Determine if TRACKING is needed for issue(s) to track longer on specific URLs to get more details.
3. Determine if TODO is needed for issue(s), this often means issue can't be solved instantly.

In progress stage

1. Determine if status of reports have changed.
2. Apply WORKING label to issue(s).
3. Modify the list, update the list checksum, commit to repo with message gfwlist edited: $(date).
4. (Optional) Signing commit(s).
5. Pushing.

Done stage

1. Mention issue number(s) in each commit.
2. Remove labels of issue(s), status labels, e.g. FIXED, INVALID, will be applied.
3. Closing issue(s).
4. (Optional) Locking issue(s).

[[http://i.imgur.com/Aqh61It.png|alt="GFWList Logo"|height=210px|width=210px]]