Re: What is Process Good For?

On 12/15/2014 2:32 PM, Sam Ruby wrote:
> On 12/15/2014 01:43 PM, David Singer wrote:
>>
>>> On Dec 14, 2014, at 8:27 , Sam Ruby <rubys@intertwingly.net>
>>> wrote:
>>>
>>> On 12/14/2014 09:41 AM, Léonie Watson wrote:
>>>> Chaals wrote: "In my own experience on the AB, in principle
>>>> people could read the mailing list and minutes for the last few
>>>> years to find out what had already been discussed before they
>>>> joined, but it seems rare that it actually happens, resulting in
>>>> revisiting things that don't need to be rehashed (as well as
>>>> revisiting questions that are due to be revisited - it isn't as
>>>> if the answers to questions that were given from 5-10 years ago
>>>> should never be re-opened)."
>>>>
>>>> I can't speak for TAG specifically, but generally with these
>>>> things it's helpful to have some work-mode continuity too.
>>>> Otherwise there tends to be a period with minimal productivity
>>>> whilst the new group figures out its approach. It's difficult to
>>>> discover how things are done just by reading minutes/mailing
>>>> lists, no matter how diligent someone is.
>>>
>>> I don't think that there is any question that continuity is
>>> desirable.
>>>
>>> I will simply note that in the W3C there seems to be an
>>> institutional propensity to define process with the intent of
>>> preventing undesirable things from happening.
>>
>> This is an aside to the current discussion:
>
> OK, new subject is therefore in order.
>
>> I actually think that handling difficulty, preventing undesirable
>> things, and so on, is the main point of a process;  to help guide you
>> when life gets tough.  Is this OK? What are we supposed to do? and so
>> on.
>>
>> No-one needs process when everyone is in agreement with what’s going
>> on; and no-one likes having to apply a point of principle once it’s
>> in the course of being violated — you want to have settled the
>> principle ‘in the abstract’ before you hit an ‘instance’, if at all
>> possible.
>>
>> Problems arise when the process gets in the way, of course.
>
> Again, I'll simply note that you and others are proving my point: in 
> the W3C there seems to be an institutional propensity to define 
> process with the intent of preventing undesirable things from happening.
>
> Overall, I must say that I'm much happier with the ASF.  We do 
> document rules for external interaction, but for internal interaction: 
> not quite so much.

It is interesting that you compare to ASF - a foundation whose defined 
purpose is open source software projects.

W3C, does not define its mission in terms of open source.  Its mission 
is defined with respect to leading the Web.  Its focus is on standards 
rather than software.  It is harder to say for standards "take my work 
and do with it as you like" because that perspective leads towards 
fragmentation rather than standardization.  The OpenStand principles 
focus more on consensus (which is hard, but important) rather than "take 
my work and do with it as you like".

We also love open source.  We have practices that (I believe) are 
appreciated by the open source community such as removing patent 
encumbrances.  We've recently introduced permissive licenses (CC-BY) for 
some specifications.  We are currently polling the AC with a proposed 
general document license for W3C which would make re-use much easier and 
clearer - as long as it is not aimed on confusing the industry with 
derivative specifications.

>
> I'd sum up the general philosophy in this way: in matters involving 
> collaboration, what matters is that the people involved have common 
> goals.  If they do have common goals, rules aren't necessary.  If they 
> don't have common goals, rules don't help.
>
> Part of what makes this work is a liberal license.  If you don't want 
> to work with me?  That's fine.  Take my work and do with it as you 
> like...  Our few rules are structured around ensuring that projects 
> that nominally are working together actually ARE working together.
>
> - Sam Ruby
>

Received on Monday, 15 December 2014 20:04:00 UTC