Re: What is Process Good For?

TL;DR:
- Paid membership is an important (but not sacrosanct) concept in W3C, which is one of the key differences to ASF.
- Who makes initial decisions isn't that important, and "whoever does the work" is a reasonable first approximation to "The Right Answer™". How serious disagreements are resolved is what matters, and that is more complex.
- Licensing is in large part a red herring. But I am glad that W3C is finally moving on it again, since it matters in ways primarily not relevant to this discussion.
- "quality of management" (eg, but not solely, chairing in W3C) is really important to making groups work.

16.12.2014, 19:22, "Michael Champion (MS OPEN TECH)" <Michael.Champion@microsoft.com>:
>   Sam wrote:
>>    Noting that there doesn't seem to be others agreeing with my points,
>   I am agreeing for the most part.  While replies on this thread talk about the differences between ASF and W3C, I've argued that there are lots of things we can learn from ASF about specific challenges W3C faces now.  Let's change the focus of the thread to talk about specifics.
>>   Consider the fact that it is a different model.  One where all work is
>>    being made available under the CC0 license.  One where contributors are
>>    defined as people who contribute and not by being named by member
>>    companies.  One where contributors become editors by sustained
>>    contributions rather than being named by chairs.  One where a growing
>>    team of editors make technical decisions rather than chairs or directors.

>   Let's take these one at a time:

0: Membership. W3C has a model where members pay a lot of money to support a large staff. We can debate whether that is a good model, but moving to a system where there are a few sponsors instead of a lot of members is a very big change. We should certainly consider the question seriously, but as an instant solution to a particular problem in publishing a small spec, it might be a bit of a short-sighted over-reaction…

>   1. License.  I agree with Jeff that CC0 is a bit too far of a stretch for many people here.

We finally have some new forward motion on making our licenses reflect the apparent consensus of W3C members. We should continue to do so, and we should focus on avoiding proliferation of licenses, since these two things are common sense.

Whether we should push the consensus, e.g. for putting everything in the Public Domain is to a large extent a question for the members, not the Process.

[...]

>   2.  Contributors.  First let's NOT create a system that requires non-W3C members to become Invited Experts.  I think it's very clear that experiment by the HTML WG failed.

I agree that the 800 invited experts was a failure. It isn' the only failure I can think of in sensibly working with the W3C Process and invited experts, but I don't think there is only one model for doing so. 

Webapps gets work done where important contributors do become invited experts, generally without problems, to the benefit of making people comfortable in committing their sometimes very large patent portfolios to RF licensing of the very broad scope of webapps work. But there are useful ways to contribute without being a member of the Working Group, and we have people in that category too.

CSS has used invited experts forever, and I don't think that has been a problem for that group.

In summary, there are numerous examples of success as well as failure in using the invited expert process, and in some cases it offers benefits that seem important.

>   We do want outside people to participate in developing web platform specs,

In general, it is helpful to enable people who have to use our work to have enough input to ensure that it meets their needs and goals. Participation is generally recognised as a cheap way to get that.

Groups that do work tend to be a little like onions in form - on the inside are those consistently maintaining the work, around them are people who provide some contribution regularly, around them are people who occasionally check on some aspect, and then there are those who come into contact for one thing, deal with it, and then disappear back to their lives.

>   including both those who have some philosophical reason not to work at W3C even though their employers are members,

I'm not sure that the effort we put into collaborating with people who don't want to collaborate with us is actually a well-directed use of resources...

>  and the hopefully much larger group of website developers who know what their frustrations are and have ideas on how to improve the experience.

We want ways to get their input. Participation, a sense of ownership of the outcome, are means to the ends.

>   I believe the CG model, or at least the CG CLA as a GitHub license file that people agree to when they make a pull request, is about the right mix of flexibility and legality.

I'm not so sure. For me there is a high value in the "patent pool" model that the real Patent Policy provides, which the CLA approach doesn't. There are ways to blend the two into something useful, but moving wholesale to the CG model strikes me as a serious step backwards.

>   3. Contributor become editors.  YES! 

Yeah, that should be, and is, straightforward in most cases. See HTML post "Plan-2014" for an example. The case where someone wants to edit a spec that W3C publishes, but doesn't want to participate in W3C, is a particular edge case (that happens to exercise us a lot at the moment).

The solution spaces include
- don't publish the spec
- ignore the person who doesn't want to collaborate
- run around trying to please everyone all the time

Some of these solutions may be too expensive to be good ones.

> This both touches on the "merit" aspect of the Apache Way Sam and I pointed to earlier,  and addresses the very real problem that W3C editors are traditionally bottlenecks.

In W3C it isn't necessarily the editor, but groups that fail to have a workable process, that is the problem. 

A lot of the complaints about WHATWG centre on how editors there have total power to be bottlenecks, and a lot of the complaints about how WHATWG managed HTML were precisely that the editor could be an effectively immovable roadblock.

>  Let's try to move toward a model of people who want something changed CHANGE THE SPEC (in a fork), and request their change be pulled back into the main spec.

Different groups, and different editors, find different processes more comfortable. I have no in-principle objection to such a model for the Process document, for example, but on the same basis that I have no objection to somebody who thinks that moving to system XYZ is an important thing to do agreeing to take over the responsibility of editor. Github is the flavour of the moment, but the same thing has applied for about half a dozen tools in my time as an editor at W3C, including xmlspec, some stuff used for HTML4 and CSS, respec, anolis, etc etc

I would rather we try to move to a model where groups focus on getting important work done, such as producing or modifying specs, test suites, implementation guides, and the like, instead of spending a lot of discussion on meta-questions of theory such as which publishing tool-chain to use, or (as you note) wordsmithing trivia.

> That's where the community has a chance to weigh in, not in interminable calls for consensus about whether to do something in the abstract, or weeks-long wordsmithing exercises.

That seems like a call for well-organised and well-chaired groups, with clear ways to get input that encourage relevant people to use them. If so, we agree entirely.

> 4. Team of editors make technical decisions rather than chairs.

As a shorthand for "who makes the first call on what probably has consensus", I think this is a perfectly reasonable way to work, if the group is happy with it. The question is what happens where there are genuine serious disagreements, i.e. people will not decide they can live with a decision they aren't very pleased about.

> I'm not sure I agree with Sam on this point.  I like the spirit of "those who can, do" but I want to steer away from the WHATWG model of whispering in the editors' ear on IRC about a change and having the editor go do it.  We want to empower people to learn to write good specs, not perpetuate a privileged group of editors who maintain control.   I think chairs can still play a valuable role in assessing the degree of consensus / opposition to re-integrating a particular fork, and there is something to be said for chairs as the checks/balances on editors.

Yes. I think this is one of the areas where well-run W3C groups are vastly better than the alternatives I know. But badly-run groups fritter away goodwill by burning people's time and effort for very little outcome.

>  But I agree that the model of appealing to the Director is not working and needs to be avoided in the new model (and eventually scrapped from W3C).

If you have a consensus model, you need a reasonable chain of appeal to engender trust.

Noting that in any open group, you can look for allies to show that "most people support my opinion" - and that not very representative groups divorces the discussion from reality - the WHATWG appeal chain is

participant -> editor.

The W3C model, which has

participant -> editor -> chair -> "director" (which in practice is often a compound chain something like "team contact -> domain lead -> director" - that could profitably be clarified).

and provides for successively stricter requirements of documentation and so on as you move along the chain is in this sense far better, IMHO. 

To put things in kindergarten terms, the WHATWG model degenerates into "yes - no" without much clarity on how to resolve it. The W3C model has "I'll tell my mum / the teacher / …" with the sense that if you do, you're going to lose something for frivolous complaints. But while a lot of decisions are trivial, we generally prefer to have a grown-up supervise the sandpit so actual bullying can be acted upon by someone sensible.

Which is to say that I am not sure we should do away with the model of escalation, but we should look carefully at how it works and make sure it does what we expect.

>   ________________________________________
...
>   Noting that there doesn't seem to be others agreeing with my points,
>   perhaps this thread should be wound down.  At a minimum, I'll respond
>   less frequently.

Disagreement shows far more obviously than agreement, especially without formal mechanisms calling for statements like "+1".

cheers

--
Charles McCathie Nevile - web standards - CTO Office, Yandex
chaals@yandex-team.ru - - - Find more at http://yandex.com

Received on Wednesday, 17 December 2014 11:58:37 UTC