-
Notifications
You must be signed in to change notification settings - Fork 23
Automation requirements
Requirements for automation of the tool chain used for notification and tracking of WG issues by the i18n WG.
These requirements are described in terms of the i18n WG’s needs, but it’s likely that they are relevant to other horizontal groups.
- It should not be necessary to manually set up notifications by editing the page at https://github.com/w3c/github-notify-ml-config/blob/master/mls.json for repos in the W3C domain. All repos should be able to notify the i18n group as soon as someone adds a first i18n-specific label.
- The current setup sets the topic to “Review comments”, which is good to keep.
- The current evenFilter is set as follows: "eventFilter": { "label": ["i18n","i18n-comment","i18n-tracking","HR:i18n-comment","HR:i18n-tracking","i18n-review”]. The event filter looks for a variety of labels, due to WGs adding their own in the past. We would like to standardise on the i18n-tracking and i18n-comment labels.
- These notifications are sent daily to www-international.
- The same notifications are also sent weekly to public-i18n-core on a Wednesday (the day before the telecon).
- We’d want to be able to adjust notification topics and dates, if we wanted to.
This is relevant for WG issues to which the i18n-tracker label is applied. It isn’t relevant for WG issues to which an i18n-comment label is applied, since those are generally created manually by the i18n WG from an exisiting tracker issue.
The current manual process for this can be found at https://www.w3.org/Team/wiki/I18n/Review_procedures.
- When either an i18n-tracking label is added to a WG issue, in any WG repo, a tracker issue should be created in the i18n-activity repo’s issue list.
- The tracker issue should have the same format as, for example, https://github.com/w3c/i18n-activity/issues/754
- the title should be the same as that of the WG issue
- The first comment should start with the paragraph: “This is a tracker issue. Only discuss …”
- There should be a link back to the WG issue in a separate paragraph, of which the first character must be §. Eg. “§ w3c/csswg-drafts#4171”
- Add the ‘track’ label.
- Add a ‘pending’ label: This will signal to the i18n group that they need to do a couple of manual things: (a) add a document/spec label, (b) add an advice-requested label if that is the case, (c) add a yellow label for typographic feature, if appropriate
- If the WG-issue has any labels of the pattern i18n-*lreq, the corresponding labels should be assigned to the tracker issue. The corresponding issues are currently the same, but without the ‘i18n-‘ prefix. Also, a spec-type-issue should be added to the tracker issue.
- Any time i18n-*lreq labels are added to or removed from the WG-issue this should be reflected in the i18n tracker issue.
- If a WG-issue is closed, the label “close?” should be added to the tracker issue.
- If the WG-issue is reopened, the “close?” label should probably not change.
To make this kind of thing easier (and comparison of lreq labels), it probably makes sense to store a list of tracker arrays and their corresponding WG-issues somewhere on the server, with information about lreq labels and open/close status, so that comparisons can be made quickly.
This is similar to the requirements above for WG-issues, but the trigger comes from a specific (but editable) set of repositories and is only applied when an issue in one of those repositories has the label Question applied. Examples of the tracker issues for this type of item can be seen at https://github.com/w3c/i18n-activity/labels/type-info-request.
(These issues are tracked in the layout tracker page at http://w3c.github.io/i18n-activity/textlayout/ and allow us to view what questions are currently outstanding for a variety of scripts and typographic features.)
- The tracker issue should have the same format as that described above, in terms of the title and first comment.
- The label type-info-request should be added, and an appropriate *lreq label.
- The yellow label indicated the typographic feature will need to be added manually.
- Add a “pending” label to indicate that this is new and the typographic label needs to be added.
This is likely to take additional thought and longer to implement.
The basic idea is that WGs could request a review using a tool that requests relevant information, such as URL of the spec, date when the review needs to be finished, contact name, GH repo for comments, etc.
Then the software would raise an issue automatically in the i18n-activity or some other repo in sucha a way that it can automatically be added to the project page at https://github.com/w3c/i18n-activity/projects/1 or similar (the review radar).