Re: [GLISS] - alternative viewpoint

[Marc Hohl]

Am 20.09.2012 11:56, schrieb David Kastrup:
> David Kastrup <address@hidden> writes:
>
> > Within your own scores, be consistent in your choices.  How this
> > consistency looks, does not matter.  Within LilyPond, there is a large
> > consistency which elements are uppercase, and which lowercase.  The one
> > thing that actually gets annoying is CamelCase.  However, as a rule,
> > camelcase starts with lowercase letters.  With recent changes in the
> > lexer, it would be possible to replace the CamelCase words with dashed
> > words.  That would allow for things like
> >
> > \slur-up \slur-down \voice-one \one-voice \voice-two and so on.  I am
> > personally not a big fan of CamelCase.  You would, of course, get the
> > same principal problem "I can't remember where and whether to put
> > dashes" when making use of that option.
> >
> > Weeding out CamelCase would not, in itself, change the classes of things
> > that we use uppercase for, lowercase for, and dashes for (there would be
> > some overlap in classes since we _do_ have a few existing
> > words-with-dashes and \commands-with-dashes, but distinguishing those
> > classes is actually not important, unlike the pure lower/uppercase
> > distinction we actually use for Grob and Context names).
> Just quoting this as yet another example where I offer some concrete
> suggestions in a GLISS thread with nobody bothering to even reply.
It is not that I am not interested in this kind of
discussions/proposals, it is just that I have no problem
with camelCase/uppercase/lowercase stuff, so I don't need
a change here; on the other hand, if this would make it
easier for everyone, then I would not object to a
"lilypond is all lowercase" change.
> > I don't think that this characterization is doing justice to the
> > developers since it basically assumes that their main incentive is
> > making fun of users.
> >
> > Part of the reason working on LilyPond is less rewarding than it could
> > be is this atmosphere of distrust, and the urge to rein in developers
> > who apparently have nothing better to do than damage LilyPond.
> "distrust" is maybe too strong a word.  "non-involvement" may be closer
> to the truth.  Regarding the GLISS discussions and proposals in that
> context becoming official project policy, participation of programmers
> is actively discouraged.  Goals are being set without bothering to look
> at how the existing and developing code base and its underlying design
> will support them.
I think that defining _goals_ can be done seriously only by
taking the underlying design, the developers etc. into account,
but _discussions_ should have any amount of freedom they
need.


> [...]
>
> "Stealthily" may seem like too strong a word, but quite a few of the
> actual usability/language features are proposed and finally implemented
> in the way we see in
> <URL:http://code.google.com/p/lilypond/issues/detail?id=2717>.  There is
> minimal feedback by few persons (this particular issue has already
> gotten more feedback than usual in its first iterations and will
> presumably pass into LilyPond silently once nobody can think of
> something to particularly dislike).
You are right.

I can only speak for myself, but the main "problem" is that most
of the time I can spend for working on LilyPond is put into the
actual patches; the reviewing process is handled rather shabbily,
I confess.
I take a look at nearly *every* issue when I got an email notification,
but I often do not find the time to get deeper into the problem to
understand what the current proposal means or what the patch
to be review actually does. And just a quick "LGTM, but not tested"
doesn't help anybody.
> If you take a look at our "Changes" file from 2.16 and take a look at
> how many of those changes were the result from following through with
> active and planned policy decisions rather than spontaneously done work,
> it does not appear that our purported planning is connected much to what
> actually gets done, and users could exercise more influence if they
> actually commented on issues in the tracker accompanying actual work in
> progress rather than participating in a hypothetical discussion detached
> from the realities of both our code base and worker base.
>
> One issue/review that recently profited a lot from interaction of
> developers and users was
> <URL:http://code.google.com/p/lilypond/issues/detail?id=2823> where
> people cooperated in collecting and completing information, leading to a
> much better informed approach to actual work.  If you take a look at
> _who_ collected the various bits of information, however, you'll see the
> usual suspects again: seasoned programmers, just that some of them acted
> in the capacity of users in the context of this issue.
Do you propose that the user base should get more information
about development work?

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.

> 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.

Regards,

Marc