Re: w3process-ISSUE-60 (Ch7-Evolution): Chapter 7 should be moved to Github to encourage and facilitate contributions to its evolution [Document life cycle (ch 7)]

On Wed, 27 Nov 2013 20:06:43 +1100, Marcos Caceres <w3c@marcosc.com> wrote:

> On Wednesday, 27 November 2013 at 00:36, Charles McCathie Nevile wrote:
>
>> On Tue, 26 Nov 2013 18:47:10 +0700, Revising W3C Process Community Group
>> Issue Tracker <sysbot+tracker@w3.org (mailto:sysbot+tracker@w3.org)>  
>> wrote:
>>
>> > w3process-ISSUE-60 (Ch7-Evolution): Chapter 7 should be moved to  
>> Github
>> > to encourage and facilitate contributions to its evolution [Document
>> > life cycle (ch 7)]
>> >
>> > http://www.w3.org/community/w3process/track/issues/60
>> >
>> > Raised by: Arthur Barstow
>> > On product: Document life cycle (ch 7)
>> >
>> > The entire "Web Community" (not just the Consortium) should be
>> > encouraged to help with the evolution of Chapter 7. As such, the
>> > document should be moved to GitHub (or some similar service) to
>> > facilitate contributions from non Consortium members.
>>
>> If people have good ideas for improving W3C process, that fit with the
>> needs of W3C, they are welcome. But I think "encouraging drive-by Pull
>> Requests" is a Bad Idea™, for several reasons:
>>
>> I don't have the bandwidth to do spam management for the process.
>>
>> W3C Process is not a community-wide open source project, it is an
>> agreement between W3C and its members, which happens to explain how
>> non-members are welcome to participate in development of W3C work too.
>> While doing the development of the process in public seems important to
>> me (enough that I spent a lot of time making it possible), the content  
>> is not a public decision, it is a question for W3C and its members.
>
>
> The whole "drive-by pull request" thing is a red herring. That rarely,  
> if ever, happens. Basing your argument on that, and that you will have  
> to do span management is ridiculous. At worst, someone sends you a PR to  
> fix a typo or two, which should be appreciated - not classed as "spam".

People do send me notes on typos, and I appreciate and act on them.

>> And while it is sorely in need of some updating, it is actually  
>> unhelpful to have it in the sort of unstable state Github is designed
>> to support.
>
> The above statement makes me think you have a somewhat misguided view of  
> the GitHub (and Git) development flow. It's precisely designed to avoid  
> what you say.

To avoid what? Pull Requests?

>> People need to use the process, which means they need to know what it  
>> is, and following a chain of github requests isn't particularly
>> conducive to keeping track of it.
>
> You can't seriously say this.

Sure I can.

> How can it be good enough for a million other software/documents/
> projects, but not good enough for this one project? This project is not
> so special.

This project is indeed not so special. But it is also not a software  
project. Nor is it all kinds of document. It is a specific agreement about  
how a large number of people with varied levels of available time and  
skill in reading english documents will work, and if there is a change in  
the requirements that they don't expect, this is likely to call problems.

>> So I don't plan to move the work to Github. Having it on the existing
>> mercurial repository where W3C people can make patches, and getting  
>> better at recording the changes that are made, seems useful. Moving
>> to github doesn't.
>>
>> IMHO. Other editors may volunteer for something different.
>
> I think you should try it and you might be surprised. It sounds like
> you are being lazy about learning something new or you are afraid people  
> might actually have an easy way to contribute and track changes - and  
> you will lose control because there will be too much participation.

I think you are leaping to conclusions based on assumptions made in  
apparent ignorance of facts.

I do use Github for certain types of project. It is great for e.g.  
developing a test suite and tracking results. It's really good for  
enhancing explanatory documentation.

I'm not concerned about losing control. I did a significant amount of work  
to get this development done in a public forum, to allow further input and  
pressure for changes that matter to the people who are party to the  
agreement that this document represents. Offering visibility into how that  
happens seems like a reasonable thing to do.

But replying to statements like this, as well as dealing with concrete  
questions about the actual document we are working on, increases my  
workload, therefore slowing progress. I don't hold "working in Public" as  
an absolute value, it is a useful pragmatic compromise between the  
requirements and constraints for what I am trying to achieve.

Github is excellent for very public projects, where all input is welcomed  
and all contributions are expected to be treated equally. As I said above,  
this is not such a case, and setting expectations that are unmet tends, in  
my experience, to lead to more work. Part of the trade-off by not going to  
github is some people who use it a lot might decide they can't be bothered  
noting things like typos that they would have done if they just needed to  
make a Pull Request. That's part of the trade-off I make in working as  
editor.

As noted, other volunteers choose different approaches. And all W3C  
editors serve at the pleasure of the relevant chairs.

cheers

Chaals

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

Received on Sunday, 1 December 2013 07:17:59 UTC