Learning from the ASF (was: What is Process Good For?)

On 12/16/2014 11:21 AM, Michael Champion (MS OPEN TECH) wrote:
> 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.

OK, I've changed the subject.

>> 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:
>
> 1. License.  I agree with Jeff that CC0 is a bit too far of a stretch
> for many people here.  To be pedantic, it's not a "license" it's a
> *waiver* of all rights. That creates the sort of confusion we have
> with some WHATWG folks who put a CC0 waiver on their documents but
> then complain when people do things they don't like with the text.
> Let's say what we mean; we want to encourage collaboration but
> recognize that forking is a legitimate option if it becomes clear
> that different parts of a community have different goals or
> fundamentally different ideas about how to achieve them.  So I would
> prefer a workmode that either re-uses the Apache 2.0 license (since
> it seems to be acceptable to Mozilla while encouraging attribution)
> for specs or another document license that does not create barriers
> to participation.  (Yes, I am aware that some colleagues at Microsoft
> disagree, but I'm not attempting to speak for them in this CG)

Noting that you and Wayne have been discussing this, all I have to add 
is that here are the use cases: 
http://lists.w3.org/Archives/Public/public-html/2009Feb/0388.html

And I encourage you to check the following resources, and select only an 
existing license that these two organizations have pre-approved:

https://www.gnu.org/licenses/license-list.html
https://www.mozilla.org/MPL/license-policy.html

> 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.  We do want outside people to
> participate in developing web platform specs, including both those
> who have some philosophical reason not to work at W3C even though
> their employers are members, and the hopefully much larger group of
> website developers who know what their frustrations are and have
> ideas on how to improve the experience.  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.

It is not clear to me what the disagreement is here.  I sense that we 
want to encourage those who are interested in actually contributing to 
do so.  This is independent of whether or not they are employed by a 
member company?

Use case: should I ever become unemployed (to be clear: my company seems 
happy with me, but many companies do periodic "reductions in force" with 
no apparent rhyme or reason), I would still be interested in working on 
the URL specification; and would be willing to sign a CLA like the 
ASF's, but would not be willing to sign the current Invited Experts 
agreement.  The wording of section 2.2 of the W3C Community Contributor 
License Agreement (CLA) confuses me.  In particular, the copyright grant 
(per section 2.1) is non-exclusive, and I (and others who make 
contributions) should continue to be able to do with my (and our) 
contributions as we like.

> 3. Contributor become editors.  YES!  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.  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.  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.

Cool.

> 4. Team of editors make technical decisions rather than chairs. 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.  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).

This merits more discussion.

For starters, I'm not advocating for a model where a single editor for a 
document gets to make all of the decisions.  What I am advocating for is 
a community model where there is a team of active comitters/editors who 
work together based on consensus.  Once such has been obtained, I don't 
see a need for an appointed outsider to be placed in a privileged position.

On a related topic, it is too easy at the W3C to create a Community 
Group, which leads to a number of abandoned efforts.  It also isn't 
currently possible for a Community Group to produce a Technical Report.

Again, I would draw from the ASF where it is easy to create an incubator 
"podling", which is actively mentored.  Once that podling has 
demonstrated that it can self-govern, it gets approved as a full-fledged 
project.  Such a project appoints their own editors/committers, and 
chair.  The ASF board has the authority to disapprove of new committers 
or outright replace the chair, but these actions are rare.

Details here:

http://incubator.apache.org/incubation/Process_Description.html

- Sam Ruby

Received on Tuesday, 16 December 2014 18:44:59 UTC