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

[Urs Liska]

Am 15.12.2013 19:48, schrieb David Kastrup:
> Urs Liska <address@hidden> writes:
> ...

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

OK, I see your point. But it's not the case here. It was only one 
discussion. In the meantime discussion has broadened through several 
more contributions.

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

Yes, most people don't think about it. We who are familiar with LilyPond 
have got used to finding our way to what we currently need, and take the 
existing website for granted.

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

Probably both, in changing proportions. And maybe add c) not really 
understanding and therefore preferring not to get their feet wet.

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

Plus partly the result of "historic" growth, adding something here and 
there and not cleaning up (cf. GSoC 2012) and presumably other stuff on 
the Community pages.

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

Thanks for your well-balanced comments and thoughts (this also goes for 
those I didn't reply to).

Urs