lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Web: Download: Add introductory text (issue 40510046)


From: David Kastrup
Subject: Re: Web: Download: Add introductory text (issue 40510046)
Date: Sun, 15 Dec 2013 19:48:28 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

Urs Liska <address@hidden> writes:

> I know that and I fully agree that it's important to be somewhat
> strict about what comes into LilyPond or its parts.

Yes and no.  One wants to avoid unpleasant surprises.

> And I also see that not _each_ of my patches is objected against.

Well, it's basically one of the most visible parts of LilyPond.  And
everybody is qualified for an _opinion_ about that.  In contrast, bad
code often sneaks in and is discovered months later.  The web site is
basically immediate, is seen by tens of thousands of people, and is
translated by all the translators.  So it saves a _lot_ of trouble to
get it right the first time.

> But it's actually quite off-putting when you prepare a patch that is
> more or less based on a broad (and astonishingly productive)
> discussion on lilypond-user, and then (after two steps of fine-tuning)
> someone steps out and asks "why are you doing this?". (This is not
> personal against Graham because I know next it might be someone else.)

Yes.  It is a major part of review processes that

a) some people come late into the game
b) the preceding discussion on the user list is isolated from the actual
   patch review process.
c) people have different opinions.

It is also the nature of electronic communication that every "opponent"
feels more or less like the same person.  If one sees a similar
objection repeated times, one tends to get annoyed even though it may
just be an independent opinion.

> Viewed from the very narrow perspective of the actual patch there
> isn't much I can argue against "People should read Text Input and if
> they don't we can't help them/we should help them find that page" or
> "this kind of stuff should conceptually be dealt with in the
> "Introduction" chapter".

It's input.  In the end, most of the decisions remain with the people
who do the actual work.  If you disagree with particular input, there is
nothing wrong with saying so.

If you find that three people tell you something in a row, then it may
be worth figuring out what the underlying reason might be.  On the one
hand, it may be unfortunate that not everybody reads up on everything
before voicing an opinion.  On the other hand, this helps a bit with
weighing some input.  If you need a discussion for three people in a row
to see your point, chances are that you would need a discussion to make
a user visiting the web site see your point.  But you won't get a
discussion: they just go away.

So just treat it as input.  It's easy to fall into the trap of seeing it
as a controverse, meaning that people try to defend a standpoint that
only became fixed by the want to differentiate oneself from somebody
else.

It's a trap that I see myself in often.  And it has happened a few times
that I convinced somebody with compelling arguments that a proposal of
his was a bad idea and technically infeasible.  Only to implement it
half a year later.  It's usually in the area of "user interface" that
something like this happens, and a web site is a user interface in some
manner.

> But actually my work and suggestions should be considered in the
> context of an overall "user experience on lilypond.org", that's why I
> offered a set of drafts to be read online. From there I was directed
> to propose small, "atomic" patches, and now we're in wrangles about
> details. It's out of proportion given the state some portions of the
> website are in currently.

Perhaps.  The point is that this state has been there for a while, and
all the translation work on it has already been done.

Another point is that the mode of operation of LilyPond tends to
attracts a breed of perfectionists that can be positively unstandable
when occuring in groups.

> I don't want to imagine what happens if I propose my rewrite of the
> Features page (http://www.openlilylib.org/lilyweb/features.html).

Let me tell you: it's not really that more satisfactory to get no
feedback at all.  That's what happens with the majority of my patches.
It might also be due to people a) trusting my judgment b) not being
eager to involve themselves in a discussion with me.

You can expect a rather mixed bag of responses overall: sometimes you
get more than you ask for, sometimes nothing at all.  Getting more
feedback often turns out more directly nettling at least to me, but
sometimes the perceived annoyance does lead to changed solutions that,
if one is honest about it, are an improvement over the original
proposal.

That's a lot of verbiage: the main point being that people take an
active interest in the work you are now doing and which has not been
worked on for a while, or worked on with different goals and
perspectives and views and strategies, and those goals, perspectives and
views and strategies were the result of a lot of thought and discussion.

And even if one has to face that this thought and discussion failed to
converge to an optimal solution, it's not gone in just a moment, and the
intent is not all wrong, but probably just prioritized badly.

Rewriting texts in this context can be tiresome; code and website layout
have fewer variables to have an opinion about, in contrast.

Thanks for caring.

-- 
David Kastrup



reply via email to

[Prev in Thread] Current Thread [Next in Thread]