Sorry, forgot to complete the mail adresses. 2012/9/20 David Kastrup <d...@gnu.org>: > Marc Hohl <m...@hohlart.de> writes: [...] > But we don't have users involved either. And those are actually the > ones for which such additions are made. Involving them instead in a > planning stage largely disconnected from actual developments is a poor > substitute. [...] > the target audience are users (a superset of developers, > hopefully). But we don't have them involved in the feedback. > > And I don't think we should wait with getting them involved until my > devious plan of turning users into programmers almost without noticing > bears fruit. > >> Do you propose that the user base should get more information >> about development work? > > Yes. > >> When working on tablature features, I got an *overwhelming* >> response of other users, a lot of "how about x/can you do y" >> stuff which more often than not found its way into tablature.scm. >> >> In other areas, the response was about nil. >> >> So there is no common rule how to get people involved. > > Sure. But with our issue tracker, users don't get involved as a rule. > Even on issues started from a user report. > >>> We definitely can make use of a _lot_ more of this kind of user >>> involvement and exchange of knowledge, interest, and inspiration, but I >>> don't see that the syntax discussions and decisions detached from the >>> actual development are facilitating this. >> >> Well, I am still not sure about the latter. > > Within specific sub-areas like tablature support, this apparently works > better than when LilyPond as a whole is concerned. > > "Let's write a subsystem/package for this" is just much more manageable > than "let's change LilyPond as a whole". > > Obviously, we should strive to change LilyPond as a whole in order to > make it easier to delegate problems to the subsystem/package level. > That allows for much more parallelized processing. > > -- > David Kastrup
Hi David, Marc, speaking only for me: I'm terrible sorry that I currently can't give you the feedback you desire. Since my injury, I wasn't able to concentrate on any more involved project or to finish any larger one. Also, I let Marc alone with the bar-line-code, we started to tackle together. Marc, please accept my apologies. So I mostly limited my activities to answer questions on the user-list, FWIW. But perhaps you may accept some summarizing thoughts about involving users in the development-process. (Most of them already mentioned) Or better: why it doesn't work, currently. Thinking of an average user, subscribing the user-list only: (1) He's often not informed that sth is planned/discussed/in-work. (2) If he's informed and looks at the code on Rietveld, he doesn't know what to do with it, because very often there's no example/regtest/snippet _how_ to use the new syntax/feature/code/whatever. Ok, Rietveld is not the place to put in such additional, illustrating examples, etc. But I think you get my point. (3) Thinking of more involved tasks like testing a patch (and managing the tools needed to do so), I assume this is not a task an average-user is expected to manage, with the current system. At least I had some larger problems installing LilyDev (I wasn't able to install the required fontforge-version, I had to ask for help) Also, learning how to deal with the new world of git-commands is time-consuming. etc etc So I second Marc: 2012/9/20 Marc Hohl <m...@hohlart.de>: > but in other cases > you'll need a way to allow users to test patches, and that's more > difficult, -Harm _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel