-
Notifications
You must be signed in to change notification settings - Fork 133
Guidelines on using GitHub issues
In the past, the www-svg mailing list was the location for all SVG spec related discussion. Now, the SVG working group prefer to use GitHub issues as a location for discussion and for tracking the progress of actions related to those issues. This wiki page outlines our preferred way of working.
Discussion of issues on GitHub is preferred over the www-svg mailing list.
We have found that issues raised on the mailing list can be forgotten over time, with no action taken.
GitHub helps to address this as issues are labelled, tracked, and can be assigned to working group members.
Issues must at least be labelled by spec and by chapter (if a multi-page spec).
Other labels may be used to further group issues together and to track the state (see 'Issue lifecycle' below)
Each issue must refer to only one topic.
Ideally issues are raised directly on GitHub, but if issues are raised on the mailing list they should be transferred onto GitHub by a working group member and the list discussion ended with a pointer to the GitHub issue.
Working group members may feel free to modify issues raised by non wg members to more clearly clarify what the issue is about and aid searching in future.
This includes:
- Renaming the issue
- changing/adding tags This does not include:
- Modifying the text of the posters message
In the text of the raised issue, describe only the problem to be solved. Further comments on the issue may provide potential solutions, if you have one in mind. Justification for why the problem should be solved should hopefully not be necessary, but can be provided in later comments if needed. If you are having trouble isolating the issue, try asking for help on www-svg.
Discussion must occur in the GitHub issue (of course).
Github discussions are archived in a w3c hosted mailing list (https://lists.w3.org/Archives/Public/public-svg-issues).
Note that issue #57 is currently blocking the archiving of emails.
This provides a back up as well as offline access for subscribers.
It's possible to comment on github issues by replying to the issue email, though there have been some reports of emails not being linked to github accounts. It is highly recommended that authors sign off such emails with their name.
Labels are used to identify the scope and the current state of the issue.
We have a kanban board to track issue the lifecycle of issues.
Stages:
+--------------------+
| |
| V
| +-------->Proposal
| | |
+--> Need Data ----->|
| |
| V
-> New -------------- Resolved -> Editing -> Closed
| | ^
| V |
+---------------+----------------------------+
|
*On Agenda* +---> Future wish list
'New' issues may go to closed as a result of discussion within the issue or at a telcon.
'Resolved issues' with no assignee may be picked up by anyone for editing.
'Proposal' must be used if an issue contains a proposal that hasn't been accepted.
'Editing' must only be used once a working group member has actually started editing the spec.
'On Agenda' is a special label that is used to request issues as discussion topics for the next telcon/f2f.
Closed issues must reference a resolution and a commit where they exist.
The issue may be closed via a commit, or closed manually and a reference
to a commit included in the comment.
The www-svg mailing list will continue to exist and is a valid place for discussion of some topics. Philosophical discussions, uses of SVG, the direction of SVG, these are all good topics for the mailing list. In general, if the desired end result of a discussion is that some specific spec text is added or changed, then the discussion should be in a github issue.