- From: Stephen Zilles <szilles@adobe.com>
- Date: Tue, 14 Oct 2014 13:40:29 +0000
- To: public-w3process <public-w3process@w3.org>
Elika/Fantasai's response to Action Item 26 -----Original Message----- From: fantasai [mailto:fantasai@inkedblade.net] Sent: Monday, October 13, 2014 7:16 PM To: Stephen Zilles Subject: Re: Open Action on Process CG On 10/13/2014 07:35 PM, Stephen Zilles wrote: > > I know that your plate is overflowing with work, but you had an action > that you accepted to describe how to work with (experiment with) Wide Review as part of the Process 2014 discussion: > > http://www.w3.org/community/w3process/track/actions/26 > > Is there a chance that this might happen? The topic is Wide Review is > hot right now and is on the agenda for the Process TF discussion at > 7AM pacific tomorrow, Tuesday, Zakim, 7762#. Okay! Here's the ideas I had: 1. Allow WGs to subclass the W3C status name, to create, document, and use custom sub-statuses and create their own process around them. For example, a WG might decide to create Alpha Working Draft Beta Working Draft Release Candidate Working Draft as subclasses of Working Draft. Or it could create Experimental Working Draft Feature-Complete Working Draft Stable Working Draft Last Call Working Draft or whatever else it thinks might be useful. The templates and pubrules should allow for this, provided that the WG clearly documents what the statuses mean, and drafts up a bit of boilerplate that the W3C Comm Team can include in its announcements. 2. Some kind of section-tagging might be in order, particularly for modules that are collections of related features rather than integrated systems. It could just be a colored box under the section header for now, and we could look into integrating it into the style sheet redesign later. Like the whole-document statuses, said boxes should have a uniform style across W3C, even if their text contents don't. 3. Once the boilerplate is cleared out of SOTD, have W3C Staff Contacts really enforce the "write a useful status" aspect of the Process, and include either there, or in some other templated section of the document, an explanation of what the editors would particularly like feedback on at the moment. 4. Encourage WGs to regularly reach out to their public lists and impacted communities outside the WG. Perhaps create a worksheet that can help the W3C Staff Contact track this kind of thing (which could then be used as part of the CR transition to demonstrate such wide review). Best practices include posting regular updates to a WG blog and other outreach channels, and reaching out directly to affected WGs and other standards groups at regular intervals. Such communication should be frequent enough, but also high-level enough, that overloaded review groups like a11y and i18n (and developers!) can effectively follow what's going on, and make decisions about timing and what to focus on for reviews. Failure modes include: A. Not giving useful public status updates, either by not communicating at appropriate times, or not providing enough context and information. B. Only spewing details on everything that happens and expecting every relevant person in the broader community to filter through it all for high-level understanding of the WG's spec progress and plans. (Publicly posting all details is great. Not everyone can handle such a firehose, particularly when tracking other firehoses, so a low-flow faucet needs to also be installed and maintained.) Review groups like i18n and a11y can draw up some notes on what status information they would find helpful in their reviews, so that WGs can be sure to provide that. We can encourage implementers to do the same. Let me know if that helps. I can try to join the call tomorrow; ping me via SMS if I don't show up, means I've confused something about timezones or sth. ;) ~fantasai
Received on Tuesday, 14 October 2014 13:41:01 UTC