- 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