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

Tracker #8

Open r12a opened 9 years ago

r12a commented 9 years ago

I'd like the document to also address the tracker system.

PLEASE NOTE that the i18n WG has a special way of using Tracker, to support its horizontal reviews. We have developed the system so that products are associated with specs that are reviewed – enabling us to track the issues down to zero for each spec, and to find issues easily for previous reviews of the same spec. See http://www.w3.org/International/track/products. It's the use of tracker for managing these reviews that I am particularly interested in.

One enabler for the setup we use at the moment was the introduction of issue tags starting with i18n- to prevent our issues being mixed with those of another WG when we send emails. We'd need to keep this.

We have a process that describes how to review specs and raise issues, then review the issues and work with the respective WG. See http://www.w3.org/International/reviews/review-instructions. It would be nice to automate much of that, since our review contributors keep missing things. It would also be nice to have a fresher, less clunky looking UI.

It would also be nice to enable discussions to take place in the tracker itself, or do a better job of importing information from emails and external bugzilla dbs. It would be interesting to develop some ideas around how that could happen.

Hope that's helpful, and eventually fruitful. ri

darobin commented 9 years ago

This process is indeed convoluted. (I'm not saying it isn't without good reason, just that I'm not surprised stuff would slip through.)

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.

A very simplistic example of the sort of stuff that can be built can be seen at http://igrigorik.github.io/issue-tracker/, which is used to track the issues of multiple specs on a single page. Something a bit more complex (but not much) might go some of the way towards addressing your needs?

darobin commented 9 years ago

I've added mention of this issue and your review steps in the doc. 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.)