Re: What is Process Good For?

On 2014-12-16 08:21, 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.
>
>> 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)

Why use the Apache license with patent grants for a copyright spec? Is 
that to change the W3C patent policy too?

What's wrong with something like the BSD license?  or asking Creative 
Commons to create a simple document license that is compatible with GPL 
(and other popular software licenses) and that requires things like 
preserving copyright notices and disclaimers?

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

with the hard part deciding when the commitments need to be from their 
employer, not the individual (because they're doing it as part of 
employment for a corporation with a relevant patent portfolio).

But, I agree GitHub contributing and licensing files are a good 
approach, and also CLA like rules for WGs for contributions.

>
> 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.
>
> 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).
>
> ________________________________________
> From: Sam Ruby <rubys@intertwingly.net>
> Sent: Tuesday, December 16, 2014 2:47 AM
> To: Jeff Jaffe
> Cc: public-w3process@w3.org
> Subject: Re: What is Process Good For?
>
> 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.
>
> On 12/15/2014 05:52 PM, Jeff Jaffe wrote:
>> On 12/15/2014 3:51 PM, Sam Ruby wrote:
>>> On 12/15/2014 03:03 PM, Jeff Jaffe wrote:
>>>> On 12/15/2014 2:32 PM, Sam Ruby wrote:
>>> And while fragmentations is a theoretical possibility, it is one that
>>> rarely occurs.
>> Fragmentation in open source is quite frequent.  Linux has many forks
>> and many incompatibilities.  This might be a feature - a similar code
>> base has different requirements in different systems. But fragmentation
>> happens.
> Valid.  But if you use that definition of fragmentation, then
> fragmentation of standards is also a reality.  To keep this conversation
> lighthearted, I'll steer away from anything contentious.
>
> Select pretty much anything at this web site: http://caniuse.com/
>
> Different browsers are implementing different features at different
> rates.  All, however, are heading in the same general direction.
>
> This is what you see with Linux.  Neither Linux 3.19 nor ECMAScript 6
> are released yet, but both will roll out over the next few years.
>
>>> Can you name a fork of the Apache Web Server?  In fact, it has been my
>>> observation that there has is a greater fragmentation around standards
>>> (*cough* URI *cough* IRI *cough* URL *cough*) than there is around
>>> software.
>> If it is true that standards tend to fragment, some might view that as
>> an important reason to discourage fragmentation.
> My concern is that the fragmentation counter-measures that have been
> selected to date have the effect of DIScouraging cooperation, which will
> indirectly ENcourage fragmentation.
>
>>> And the ASF has an equally strong position on the need for consensus.
>>>
>>> I'd encourage you to not dismiss this so readily:
>> I don't know what led you to believe that I was dismissive of anything.
>> I noted that software and standards are different.  And I explained why
>> fragmentation in standards is bad.  I don't consider that as being
>> dismissive.
> OK.  In that case, I disagree that they are different in ways that
> affect community, consensus, fragmentation, or other topics that we have
> discussed.
>
>>> Meanwhile, I will caution you: if you continue to attempt to keep a
>>> tight grip on the standards you have through onerous Invited Expert
>>> terms and conditions and Document Licenses, what I suspect is that you
>>> will increasingly find that standards will be defined -- WITH
>>> CONSENSUS! -- elsewhere.  And the W3C will be reduced to belatedly
>>> giving their stamp of approval.
>>> In fact, an instance of this is exactly what I briefed the AB on
>>> earlier today:
>>>
>>> https://github.com/webspecs/url/blob/develop/docs/workmode.md#preface
>>>
>>> Is that leadership?
>> I'm not sure I understand this question.
>>
>> You have been proposing a workmode for URL and I have been encouraging
>> you all the way in my remarks in this process CG.  Are you suggesting I
>> should not be supporting this proposal?
> 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.
>
> Ponder whether this is a prototype for a new way of working.
>
> I will say this: I'm personally 33 years into a 30 year career with IBM.
>    I have no plans on leaving, but at some point IBM may have other
> ideas.  At which point, I will likely retire instead of looking for
> another employer.  Even so, I expect I will continue to work on the URL
> specification, but I will have no interest in signing the current
> Invited Expert agreement.
>
> - Sam Ruby
>
>
>

Received on Tuesday, 16 December 2014 17:21:13 UTC