Re: we now have "lilypond" organization on GitHub

[David Kastrup]

Urs Liska <address@hidden> writes:

> Am 18.09.2013 09:46, schrieb David Kastrup:
>
>> Well, it facilitates looking at stuff in context (though that's fairly
>> trivial to do by actually applying the patch in a cloned repository, and
>> in-file-system clones of git repositories are _really_ cheap).
>>
>> It's pretty lousy for actually incorporating the feedback which, to be
>> fair, is mostly due to Rietveld not being made for Git.
>
> So (as an uninformed shot in the dark) wouldn't it make sense to
> switch to a code review tool which _is_ made for Git?  (Equally
> uninformed:) I just read about Gerrit which "simplifies Git based
> project maintainership by permitting any authorized user to submit
> changes to the master Git repository, rather than requiring all
> approved changes to be merged in by hand by the project maintainer".

The main problem is that we can talk about doing things all day.  But
any change has to be accompanied by people working on it and solving the
related problems.

Of course, a "no-tool" approach is easiest to pull off in that regard:
you declare everything the user/programmer's responsibility and are
done.

As it would seem, Gerrit is a replacement mostly for Rietveld, not for
project management, so it would need to get tied into our existing work
and review flows.  It also needs hosting, so if we are getting serious
about it, we'd have to talk to Savannah or others.

>> The one area where I'd consider a web interface a possibly good
>> tradeoff of matching tools to skills would be translation work: that
>> could/should be a lot more crowdsourced than it is now.  It turns out
>> that organizing and tracking incremental translation work requires
>> being able to work with various scripts and stuff: the translation
>> workflow does not benefit from web-based tools at all.  As a
>> consequence, we have at most one translator per language.

> That's what I said.

No, it isn't.  I said "the _one_ area" while you are trying to sell
web-based interfaces as a panacea.  For by far _most_ of the involved
work areas, web-based interfaces scare more potentially serious
contributors away than otherwise.

Linux is not developed using web interfaces.  Git isn't developed using
web interfaces.  Most _development_ is not done using web interfaces.
When we are talking about maintenance of text rather than development of
code, the balance is different.

> This kind of work would greatly benefit from allowing 'anybody' to
> contribute directly to a repository, with the developers' only having
> to approve or reject the change.

Turns out that our translators work on their own separate mailing list
in a Linux type of development style and "the developers" don't get to
approve or reject any change.  Translation workflows don't use our
review system or issue trackers.

And I don't even think they would benefit from it.  If we take a look at
the few reasonably tightly tracked translations (French and Spanish, I
think), I very much doubt that you'd improve the quality of the work of
the respective translators by forcing a web frontend on them.

And I doubt that a crowd-sourced German (say) translation would lead to
a consistent quality _unless_ several people get fully immersed into it
and again work at a level of thoroughness where web/crowdsourced
interfaces get more in the way than anything else.  Program
documentation is not a Wikipedia-like task.

-- 
David Kastrup