Re: Problems I'd like to see addressed in Process 2016

On 22/04/15 05:40, Michael Champion (MS OPEN TECH) wrote:


First, thanks for that long message. Inspiring.

> 1.Innovation of new web specs is not happening in W3C; specs begin life
> elsewhere – often in some personal GitHub repo -- and don’t get the
> broad consensus and IPR protections W3C offers until relatively late in
> the game

That is correct: the W3C is only a consortium of industrial members and
most of innovations are born inside the Members' private corporate
space. I don't think it will change, given the complexity of the stuff
we deal with.

> 2.The W3C process in practice is too slow and contentious, often delayed
> for years by a small number of difficult issues, which are often corner
> cases or hypothetical scenarios.

I have a number of cases where the process of releasing some specs has
been delayed by the members themselves, even if they eventually blamed
the W3C Process...

> 3.Recommendations are seldom maintained to reflect what works on the
> actual Web, hence developers turn to other resources for guidance and
> the W3C’s reputation as the source of authoritative standards suffers.

Hmm. Let's take the example of caniuse.com, one of those external
resources web authors rely on; do you think it should be done and hosted
by W3C? I won't disagree but where will the workforce and budget
come from? Is that a Standards Body's role?

> There’s no single process fix for these problems, but one theme cuts
> across most of the proposals I’ve heard*:  The process now is geared
> toward producing normative standards that attempt to specify describe
> how things should work; let’s tweak it to encourage pragmatic solutions
> to actual web developer challenges and iterate them as the world
> evolves.* *TL;DR – Let’s do that by making CGs an explicit part of the
> W3C process and encourage WGs to start with a well thought out spec
> before standardization; let’s relax some of the requirements about
> consensus and testing that sound good in principle but have too high a
> cost in inefficiency; and let’s take spec maintenance more seriously to
> ensure that Recommendations improve with age rather than go stale.*

I am extremely circumspect about our _current_ usage of CGs for 2 very
good reasons I recently discussed with plh:

1. if idea inception is done in a CG, that's yet another ML to follow.
    Technical contributors to the Web Platform easily follow more than
    a dozen of technical MLs and even one more comes at a huge cost.
    So I'm not opposed to having a CG as an incubator for WG work, but
    I recommend they share the same ML to ease the pain. We can use []
    tags in subject lines for discrimination.

2. similarly, if an idea that emerged in a CG eventually moves to a WG
    for progress along the REC track, it means that the non-members and
    individuals who contributed to the original idea in the CG will be
    outside of any patent policy when they contribute to the public
    technical ML of the WG.
    The conclusion is the same as in item 1: CG and WG ok but only if
    they share the same technical mailing-list. The WG can keep an
    administrative private ML.

> In more detail:
>
> *Incubation*: The current process says nothing about Community Groups,
> which started as an experiment in 2011 and have become popular ways to
> get the right set of people involved in designing a spec with the bare
> minimum of process and IPR policy overhead.  The Process Document should
> acknowledge the existence of CGs, encourage open incubation of specs in
> CGs rather than assuming the process begins with a charter and blank
> specification, and describe specific ways a successful CG can contribute
> a spec that is in scope for a WG to jump-start standardization.

I'm not sure the process has to "encourage open incubation in CGs". The
process has to describe the purpose of CGs, how they operate and their
duties and limits. Encouraging is about communication and outreach, not
Process.

> ·I'd like to see the Process Doc somehow (I don't have language to
> propose yet) encourage WGs to start with a concrete spec rather than a
> sense that a spec is needed. Likewise,  I'd like to see an explicit CG
> Contribution mechanism that parallels the (seldom used anymore?) Member
> Contribution mechanism to let a CG formally ask W3C to find a WG home
> for its spec

If we keep WGs as they are today, I'm opposed to spec work done in CGs.

> · I'd like to see some criteria specified to allow / encourage a WG can
> take a CG spec (presumably a mature one with a Final Specification
> Agreement indicating a reasonable amount of support and IPR commitments)
> and publish it quickly as a Candidate Recommendation.

Same as above.

> · Picking up on a suggestion others have made (Sam and Wayne, IIRC)
> there should be some way for a WG and one or more CGs to align with each
> other, so that the CG scope is a subset of the WG scope  and there is
> explicit coordination among groups.  This would  make it easier for WG
> members to join the CG) , would help keep inter-related specs in sync,
> and would allow the WG to "adopt" the output of a CG once there is
> consensus it is ready for standardization.

Hence my suggestion above: 1 WG + n CGs sharing the same technical ML
would give what you want, with patent policy's benefits.

> *Efficiency*:  The WG process and W3C procedures  should encourage a
> bias for action, promote a culture of getting things done, and counter
> the tendency for consensus building to lead to paralysis.  On paper, the
> Process Document offers good advice for what “consensus” means and how
> to achieve it.  All too often in practice it means that an individual or
> small minority can “hold the spec hostage” with formal objections or
> informal appeals to the Director.  This makes sense if we think of
> Recommendations as Normative visions for how the future should look, but
> in a more Pragmatic process the Real World is  the court of appeal for
> WGs and CGs.  The Director can play a role in short-cutting that appeal
> to the Real World by nixing ideas that clearly won't pass muster (e.g. a
> spec that pays insufficient attention to accessibility, security, etc.)
> but the Director should not be in a position to pick winners and losers
> in technical matters, especially those which are wrapped up in business
> or political issues.  Better to document that there is no consensus and
> encourage experimentation and further discussion than to impose a
> pseudo-consensus.

After seven years of co-chairmanship in the CSS WG, I think I have
identified something even more important that "getting things done".
Something that comes chronologically before and is at the root of
everything: the local culture must make it easy, cool and simple to
join and contribute. It says nothing about the future of your
contributions, it only says the standardization table is a "Spanish
Inn" as we say in french, where the door is always open and where
consumers share what they bring.
We famously failed on that front some time ago and are still paying
a high price for that. The process of the HTML WG was so complex and
heavy it made most people flee.

> Somewhat similarly,  the idea that specs must be formally tested to
>   ensure that independent developers can implement features in a way
> that interoperates with others looks good on paper, but has become a
> burden on WGs ability to get things done.  For example, as I understand

Agreed. Please note it's an even greater burden for large specs.
Saved in PDF, html5 is 522 pages' long with lots of features to test
per page, ahem. Counting some of collisions that must be tested,
the magnitude of a minimal test suite for a such a document is
in the 10,000 frame.

> it the Web Messaging spec only recently got to PR even though the spec
> itself has been stable and widely implemented for years.  Things got
> done when the WG decided that the Real World had concluded the test
> failures could be safely ignored.  In any event, many WGs are finding it
> hard to get volunteers to contribute formal tests, perhaps given the
> waning popularity of unit testing in favor of more holistic quality
> assurance approaches in the software industry, and it’s time to rethink
> how much formal testing is needed to advance to Rec.

The CSS WG has been warning about that for a decade. I'm glad seeing you
reach the same conclusion.

> In short, I believe we can make the actual spec process more efficient
> by taking a critical look at the Process Document and the existing
> social norms in W3C to look for restrictive practices that could be
> loosened up a bit.  From a pragmatic POV, a decent spec with actual
> patent commitments SOON is better than a spec with universal consensus
> and unit tests that work in all browsers SOMEDAY. I recognize that many
> in W3C will vigorously disagree, but I think it’s time for a frank
> discussion of which “sounds good in principle, doesn’t work well in
> practice” processes come at too high a cost in real world effectiveness.

In summary, the two options currently on the table are "CR is good
enough to implement and ship" and "There are only RECs".

> *Maintenance*.  We’ve had a somewhat frustrating discussion  of how to
> improve “errata processing” and the draft Process 2015 has tweaks to
> make it easier to make editorial changes to a Recommendation.  But
> improving real world interoperability also requires more extensive
>   maintenance of specs to incorporate what browser implementers and
> website developers have learned, which might result in “breaking”
> changes.  That’s an uncomfortable idea from the Normative perspective,
> since changes that break faithful implementations of a Recommendation
> are something we’ve tried to avoid.  Nevertheless, and especially if we
> adopt some of the efficiency ideas above and get decent specs to Rec
> soon rather than strive for perfection someday, taking maintenance more
> seriously is something we need to think about while revising the process.
>
> I don’t have a specific proposal for how to change the process document
> to encourage more active maintenance of specs.  A couple of ideas I’ve
> heard include:
>
> ·Make interpretation / clarification of mature specs (CR, PR, Rec) an
> explicit, high priority responsibility of WGs; devise and use a process
> to request and process interpretations of how a spec would apply in
> concrete situations; W3C management should use its power to appoint team
> contacts, chairs, and (indirectly) editors to insist that WGs do indeed
> “eat their maintenance veggies” before they get to go out and play with
> new ideas.

Suppose spec A released by B WG that was closed some time ago and the
editors moved to some other project or even left their employer of that
time. Then the ML quoted on the spec is not monitored any more, the
email addresses of the editors are not relevant any more, there is no
way to contact anyone for errata.
So for your idea to work, it will require modifying the status of all
existing RECs to make sure W3C is reachable even if the WG is gone, even
if the editors are gone.

> ·Setup a more informal CG-like venue  where implementers and website/app
> developers can notify the group of interoperability issues, and the
> group sorts out whether these are due to misunderstanding of the spec by
> the user, bugs in the implementation(s), or errors/ambiguities in the
> spec.  The group ensure that their proposed resolution is logged in a
> discoverable place, bug in implementations are filed in the appropriate
> product bug tracking system, spec bugs are filed with the appropriate
> WG, and examples / doc improvements are recorded.

YAML, as I said far above. I don't think we need this. What we really
need is a web page saying where to post feedback, and a link to that
page should be in all our specs, maintained or not, recent or old.

> Admittedly, lots of these points are more about W3C culture or the
> social norms of standardization than about the Process Document per se.

Yes.

> Likewise, I don’t think the formal process necessarily must change to
> address these problems, and arguably some proposals should be tried as
> experiments and only applied to the process document if they succeed.

Well... If we're speaking of our culture of releasing standards, then
we must speak of our WG Charters. Some tend to be quite lax, some tend
to be quite rigid. As I said above, I have the gut feeling that all is a
question of work atmosphere. The Press issues every year a list of the
coolest companies to work for. Are we one of the coolest standards
bodies, are we an attractor for contributors? And if we're not, what
should we do or change to become one again? From that perspective and as
an example, I have always thought the initially super-rigid - later a
bit better - decision policy of the HTML WG was a huge mistake.

</Daniel>

Received on Thursday, 23 April 2015 10:09:20 UTC