[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: the "r" in "git pull -r"
From: |
Graham Percival |
Subject: |
Re: the "r" in "git pull -r" |
Date: |
Mon, 10 Aug 2009 02:01:30 -0700 |
User-agent: |
Mutt/1.5.18 (2008-05-17) |
On Mon, Aug 10, 2009 at 10:50:09AM +0200, John Mandereau wrote:
> Le lundi 10 août 2009 à 01:18 -0700, Graham Percival a écrit :
> > We've lost 50% of potential contributors to the website because of
> > git.
>
> And we've lost the same percentage of potential French translators; I'm
> sorry to remark that most of them who didn't spend the effort to master
> Git and stopped contributing didn't spend much effort either to look for
> accurate translation of musical and other technical terms, or even
> respecting Texinfo format editing (I once got a translation in ODT!)
> which is yet far simpler and comfortable than XML-based formats or PO.
I agree that there's a correlation between willingness to learn
git and quality of work. I'm not opposed to asking contributors
to jump through _some_ hurdles; I just think we don't have the
right balance yet. Off the top of my head, I'd guess that we want
to discourage 25% of potential contributors.
> > We want people working on lilypond, not working at understanding
> > git.
>
> Agreed. Many people are scared by just using command line, and I doubt
> we'll manage to get the procedure above simpler, so the only solution is
> providing another way to contribute, e.g. a web interface that is not
> read-only but that allows retrieval and submission of individual files
> or file sets,
IIRC you or Valentin have mentioned this in the past. How would
this work with, say, documentation? Would a potential contributor
retrieve the "doc file set" (autogen.sh + Documentation/,
potentially trimming out the translations)?
I'm not eager to drop the "does it compile?" question for
contributors, even for documentation. Apart from people on
windows who *cannot* compile the docs, I'd still ask doc
contributors to build the docs locally.
Cheers,
- Graham
- Re: lilycontrib.tcl, was Re: the "r" in "git pull -r", (continued)
- Re: lilycontrib.tcl, was Re: the "r" in "git pull -r", Johannes Schindelin, 2009/08/11
- Re: lilycontrib.tcl, was Re: the "r" in "git pull -r", Maximilian Albert, 2009/08/12
- Re: lilycontrib.tcl, was Re: the "r" in "git pull -r", Johannes Schindelin, 2009/08/12
- Re: lilycontrib.tcl, was Re: the "r" in "git pull -r", Maximilian Albert, 2009/08/12
- Re: lilycontrib.tcl, was Re: the "r" in "git pull -r", Johannes Schindelin, 2009/08/11
- Re: lilycontrib.tcl, was Re: the "r" in "git pull -r", Jonathan Kulp, 2009/08/11
- Re: lilycontrib.tcl, was Re: the "r" in "git pull -r", Jonathan Kulp, 2009/08/11
- Re: lilycontrib.tcl, was Re: the "r" in "git pull -r", Johannes Schindelin, 2009/08/11
- Re: lilycontrib.tcl, was Re: the "r" in "git pull -r", Johannes Schindelin, 2009/08/11
- Re: the "r" in "git pull -r", John Mandereau, 2009/08/10
- Re: the "r" in "git pull -r",
Graham Percival <=
- Re: the "r" in "git pull -r", Francisco Vila, 2009/08/10
- Re: the "r" in "git pull -r", Trevor Daniels, 2009/08/10
- Re: the "r" in "git pull -r", Graham Percival, 2009/08/10
- Re: the "r" in "git pull -r", John Mandereau, 2009/08/10
- Re: the "r" in "git pull -r", John Mandereau, 2009/08/10