Re: [GLISS] - alternative viewpoint

[Thomas Morley]

Sorry, forgot to complete the mail adresses.

 2012/9/20 David Kastrup <address@hidden>:
> Marc Hohl <address@hidden> 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 <address@hidden>:

> but in other cases
> you'll need a way to allow users to test patches, and that's more
> difficult,

 -Harm