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

On 4/23/2015 6:08 AM, Daniel Glazman wrote:
> 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?

I think this is a sensible role for a Standards Body, but I agree there 
could be a resourcing question.  How is this resourced today? Is it 
mostly volunteers?

I would have no objection putting this in W3C (if that's what people 
wanted) and conversely I don't feel an imperative to put it in W3C (if 
people are happy with how it is managed today).

>
>> 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.

I read Michael's suggestion that the Spanish Inn for W3C standards 
should be the Community Groups - which are structured for that.

Once the sharing and boiling down takes place (and to your point Daniel, 
with care about IP commitments), then we can advance to a WG.

>
>> 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 14:31:31 UTC