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

On 2015-04-23 03:08, 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?
>
>> 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.

Having a Community Group affiliated with a Working Group doesn't require 
a Process Document change.  It just requires a Community Group Charter 
that describes how the CG is organized and how a Working Group plays a 
role, and a WG that decides to interact with that CG.  e.g. CG Charter 
says the CG stops work on their specs when WG does a CfC to adopt them 
and doesn't work on them further unless the WG asks them to.

So, this is something the HTML WG or Web Apps WG or DAP could choose to 
do, to enable incubator work rather than to have to debate whether to 
add deliverables to the Charter.  Contribution based patent obligations 
makes it easier to add exploratory work without everyone being obligated 
for it.  WGs could choose not to have an affiliated CG, and others may 
want one.

Over time, it could become clear that some features are useful to always 
have in Affiliated CGs and then something may be appropriate for the 
Process Document.  For now, CGs are flexible enough that their Charter 
is the Process they'd need to set it up.  Then the WG can influence 
them, the way the CG Charter says they can, like the CG Charter could 
say the WG writes and modifies the CG charter by some process like a CfC 
-- and the WG can choose to do that or not.

>
>> · 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 18:25:11 UTC