Re: improving our contributing tools and workflow

[Joseph Rushton Wakeling]

On 26/09/13 14:26, David Kastrup wrote:
> So Graham organized the infrastructure where this would not easily
> happen again in the same manner, and the Contributor's Guide reflects
> it.
>
> But we haven't exactly seen a flurry of patches from newcomers appearing
> on the lists.  Of course, part of the reason is that any good mailing
> list citizen will, before contributing, study some of the mailing list
> archives to figure out how things are usually done.

There may be another side to this.  Post-GitHub there has been a pretty 
substantial increase in the user-friendliness of DVCS.  What's currently 
advocated in the Contributors' Guide stands in stark contrast to the ease of 
contribution (and contribution management) that many people experience as the 
norm now.

I'll give one example, because it's not clear to me that people have understood 
my past objections to git-cl etc.

Here's a currently-open pull request of mine in another project that I 
contribute to:
https://github.com/D-Programming-Language/phobos/pull/1533

You'll see that below the summary there is a report from the project 
auto-testing facility, with a link to a more detailed overview of the test results.

What that means is that -- as a contributor -- I just submit a pull request via 
GitHub's UI.  Testing is taken care of for me, and the feedback is there and 
integrated into my pull request for me to read and (if necessary) respond to.

Or, if I were a reviewer, I again wouldn't need to worry about the testing, 
except as information useful for my review.

In other words testing is a completely automated process that requires no manual 
intervention from anyone and no changes to the standard GitHub workflow. 
Contrast that with git-cl, and also bear in mind how user-friendly GitHub makes 
pull request submission and review.

Unfortunately in this case the tool is a custom-written one for the project, 
because they had some very specific requirements and at the time no one tool 
supported all of them.  It's possible of course that now the existing tools 
would satisfy what they needed.  So, it's not likely to be directly useful for 
Lilypond, but it _is_ a very good model of how testing can be integrated into 
code review in a non-intrusive way.

Similarly, the project's bugzilla listens in on pull requests and can be 
automatically updated when an appropriate pull request lands (the requirement is 
that the pull request title contain the issue number, so in this case it's not 
100% automatic, but then, how could it be?).

All of this is orders of magnitude more user-friendly than what Lilypond 
currently operates and I don't think I'm wrong in saying that this kind of easy 
DVCS experience is now the expected norm for many developers.