-
Notifications
You must be signed in to change notification settings - Fork 132
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.
Each issue must have one label from each of the following categories:
- Specification
- Filters
- SVG Animations
- SVG Integration
- SVG Mapping
- SVG Markers
- SVG Streaming
- SVG Strokes
- SVG 2
- SVG Parameters
- Accessibility
- Chapter (for a multi page spec)
- Entire spec
- Introduction
- Rendering Model chapter
- Basic Data Types and Interfaces chapter
- Document structure chapter
- Styling chapter
- Geometry Properties chapter
- Co-ordinates chapter
- Paths chapter
- Basic shapes chapter
- Text chapter
- Embedded Content chapter
- Painting chapter
- Paint Servers chapter
- Scripting chapter
- Linking chapter
- Appendices
- State
- Needs discussion - Needs initial discussion to clarify the issue and potential solutions.
- Needs resolution - Some potential solutions identified. Working group needs to identify the preferred solution and make a formal resolution.
- Needs editing - Resolution has been reached, or the issue is purely editorial. Changes are required to the specification to close the issue.
- Needs removal - Spec work needed to remove the feature.
- Needs data - The working group doesn't have the required data to propose solutions.
Other labels are optional:
- On Agenda - For discussion at the next telcon.
- Needs CSS WG - Something that should be discussed with the CSS WG
- Outcome
- duplicate
- wontfix
- Future wish list
- Meeting
- e.g. London2016
'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.