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

Received on Wednesday, 27 November 2013 09:05:20 UTC