Skip to content

Automation requirements

Jump to bottom
r12a edited this page Sep 25, 2019 · 20 revisions

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.

Notification of changes to WG issues we are tracking

  • 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.

Automatic assignment of i18n labels to new (and old) repos

Any new W3C repo should automatically have i18n-tracking and i18n-comment labels (preferably using our preferred mauve background). This will standardise usage and allow WGs to use the i18n-tracking label straight away.

While setting this up for new repos, we should ensure that all exist repos in use also have those labels.

I18n also uses some i18n-*lreq labels, but it will probably be better not to automatically add those. They can be added as needed by i18n staff. This is because there are a largish number of such tags, and they are typically only needed for a small number of repos.

Automatic creation of tracker issues for WG issues being tracked

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.

Automatic notification of closure of WG-issues

  • 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.

Automatic creation of tracker issues for lreq issues with the Question label

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.

Automatically add tracker issue for review requests

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).

Clone this wiki locally