search

w3c / modern-tooling

Work of the modern tooling task force
http://w3c.github.io/modern-tooling/
MIT License
44 stars 39 forks source link

Tracking horizontal review issues in github #22

Open r12a opened 9 years ago

r12a commented 9 years ago

The appManifest folks have been tracking issues in github. The i18n WG raised some issues on their spec (through a complicated route actually, but let's keep this simple for now), and we wanted to be able to receive notification to the www-international list when comments were raised on those issues (only). (ie. in the way bugzilla allows).

Dom put in place a mechanism to do that, which relies on tagging the relevant issues with "i18n WG". Any comments raised on those issues, and only those issues, are then forwarded to www-international.

If more groups handle comments on github, it would be important to roll out this patch, or something similar, to those repositories, so that i18n or other horizontal groups can be notified when there is new information about an issue they have raised. The selective nature of the notification is important, since we'd otherwise be swamped with information, and in a very bad place.

(Btw, it's our experience that it is likely to significantly reduce complications if groups that manage issues on github, bugzilla or such encourage people to use those tools directly in their SoD, and only have a link to email as a last resort.)

darobin commented 9 years ago

This is not something that we need to decide on right this second, but do you think it would be a good idea if groups could themselves label any of their bugs "I18N" which would cause www-international to be notified? In addition to the I18N WG using this label to track the bugs it opens, it would allow groups to themselves decide that a given issue is something they would like you to look at.

I've added this to the document, it's very relevant — thanks!

r12a commented 9 years ago

[Not sure of the protocol here, whether to just comment or open and comment. I'll choose the latter until i know whether that affects its visibility, i suppose.]

"I wonder: how much of that do you think could be handled as an application that talks to the GitHub issues of another group, basically looking at all the bugs across the w3c organisation that have an "I18N" label (as mentioned in the other issue) and showing them in an easy interface? This would at least obviate the need to create products."

Creating a product in tracker is trivial, actually. The product buckets are handy, since they allow the horizontal group to organize the world as they prefer, rather than having no control over groupings. One way in which that has been useful so far is that when a new version of a spec is developed, say css-counter-styles-4, we will typically use the same product as we used for css-counter-styles-3 to group the issues raised. This is an easy way for us to compare new and old comments, regardless of whether the new spec is developed in github rather than cvs, etc, etc.

The example page you point to looks nice, but it is indeed very simplistic, fwict. Just compare our product list at http://www.w3.org/International/track/products, and you'll see that we need progressive disclosure of detail, due to the number of specs we are dealing with. (Btw, we still think of tracker as fairly recent - there's another list of older specs we've reviewed elsewhere. It would be nice to integrate that, but that's perhaps just a pipe dream.) In addition, it would be nice to be able to sort the list in various ways: by number of outstanding issues, by most recent comment, alphabetically, etc. It would be nice to have a flag for each spec so that we could group specs into 'current work' and 'done for now'. etc...

There is certainly much room for improvement in tracker, however, and better dynamic linking with a github issue list may be of help, particularly for the display of information about a particular issue. Bear in mind, however, that we need to be able to manage comments across all systems: github, bugzilla, email, .... whatever the spec devt team prefers.

In some ways, although there's plenty that could be improved on, tracker is fairly useful (in addition to the drill down, it has useful features such as hiding closed issues if you prefer, showing how many issues are open for a given product, etc.) It would certainly help to have something that better reflects the 'live' status of the issue by picking up information from, say the github repo. But bear in mind that the horizontal group needs a way to control things such as the status and grouping of issues separately. For example, we don't want the status of an issue to revert to closed until we have decided that we're done with it – ie. we don't want to suddenly lose sight of it because someone else closed the issue in github.

It's this separation of control by the spec group and the horizontal group that makes our requirements a little special compared to those of the people actually developing the spec. (Or of ourselves when we develop our own specs.)