Urs Liska <u...@openlilylib.org> 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 _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel