Re: Remove old "News" entry from home page

[David Kastrup]

Federico Bruni <address@hidden> writes:

> Il giorno sab 18 lug 2015 alle 20:42, David Kastrup <address@hidden> ha
> scritto:
>> Federico Bruni <address@hidden> writes:
>>
>>>  Il giorno sab 11 lug 2015 alle 9:28, Urs Liska
>>> <address@hidden> ha
>>>  scritto:
>>>>  These are all good ideas and suggestions. Now we need someone to
>>>>  give it a try. I won't be able to do anythong about ut
>>>>  unfortunately.
>>>
>>>  Unfortunately I'm scared away by texinfo, texi2html, the build
>>> system,
>>>  etc.
>>>
>>>  I wish we could use a modern tool for the website (there are nice
>>> static website generators around.. I've recently started testing
>>> cactus¹). I'm pretty sure that other people might be more motivated
>>> to contribute if we changed the tool for the website only.
>>
>> We use the same input language for the website as for the rest of the
>> documentation.  As a consequence, our website and main documentation
>> are maintained and kept up-to-date with respect to one another, and
>> one can search any website material in Emacs' info browser.
>
> I understand that having to learn two input languages is not optimal,
> but I don't think that it's a big problem.  On the other hand I think
> that it's safe to assume that few people out there know texinfo and
> many more know markdown or HTML. If we care for contributors...

If we care for contributors, we better not fall apart into even more
technologies and tools than we currently do.

>> What "tool for the website" will be maintaining literally thousands
>> of LilyPond code examples and the resulting images?  And if we have
>> people motivated to contribute to web-only documentation, what is
>> supposed to happen to the PDF manuals and the Info manuals?
>
> I don't see any value in having the website in PDF or Info format and
> I'm pretty sure that at least 90% of lilypond users have the same
> opinion.

So let's remove all the manuals from the website because 90% of LilyPond
users rather want to have something written up ad-hoc by some website
maintainer.

Then remove all the websites in the dozen languages that we provide and
let all of the translators learn to work with the new website creation
framework in addition to translating the manuals.  We have an abundance
of translators so half of them can focus on translating the web
material, and the other half on the manuals.  Assuming we even want to
put the manuals online in HTML.

>> And our web pages currently render perfectly well on pretty much
>> every browser (including text browsers).  Many content creation tools
>> don't render convincingly on less common browsers or screen
>> resolutions.
>
> Current website is not mobile friendly and this is not good for SEO:
> https://support.google.com/adsense/answer/6196932?hl=en

"Search Engine Optimization" is for pushing yourself in front of
competitors providing the same kind of standard service or software.
That's totally a non-issue for LilyPond.  "mobile friendly" would be
more of an issue in case people like to get relevant information about
LilyPond on mobile devices.  Now in what respect visible to humans
(rather than to "SEO") is LilyPond's web presence not mobile friendly?
If there are actual shortcomings rather than the placation of web
crawler criteria involved, addressing them makes sense of course.  But
completely dropping everything that we currently have working in favor
of something that no active contributor uses in the hope of magically
making more contributors appear is not likely to help.

> The tools I'm thinking of use Bootstrap, which is responsive and
> mobile first:
> http://getbootstrap.com/

But we don't want "mobile first" since LilyPond works with chunks of
information regarding its input and output that are not primarily suited
to the comparatively small screens of mobile devices.  So the main work
environment for doing more than cursory information hunting and
gathering will not be a mobile one.

> I see a totally different reality, but I might be wrong. Let me list
> some points:
>
> 1. All the persons who built the lilypond build system left the
> project. Correct me if I'm wrong.

More LilyPond contributors are working with the LiilyPond build system
than would be working on whatever you want to replace parts of it with
for the sake of the web pages.

Correct me if I'm wrong.

> Who is going to fix all the issues related to website generation and
> translation?

Well, how is _your_ tool magically going to crank out translations of
the web page into 10 languages or so?  Because that is what we currently
have.  Translators do not need to learn anything different for manuals
or web pages.  And how is your tool going to embed images created from
LilyPond source code?

Who is going to write up things like
<URL:http://lilypond.org/doc/v2.19/Documentation/changes/index.html>
currently written by the programmers along with the rest of their code,
and translated by the translators along with the rest of the material?

> Who is going to spend work on trying to understand something extremely
> complex which can be useful only within the LilyPond project? I would
> not be optimistic...

So let's change this to some system almost no LilyPond programmer has
ever touched.  All the issues will magically fix themselves.  The truth
is rather that the person pushing for the change will be fixing
everything alone until he runs out of steam at some point of time and
then the stuff will be left in limbo and as-is.  It's been that way
always.  And then it's an advantage if it is not-yet-another different
technology.  We want fewer of them rather than more.

> 2. We still depend on texi2html and the help request by Jean-Charles,
> who tried moving to texi2any, not surprisingly was ignored:
> http://lists.gnu.org/archive/html/lilypond-devel/2015-05/msg00032.html

You are trying to replace minor problems with major ones.  We have
something that is working.  It will take a lot of work to get to
comparable state, and it will mean that either magically a number of new
contributors appear or the current contributors learn yet another tool
that they'll need for nothing except maintaining the web site.

> I tried a very small contribution such as updating the screenshots of
> Denemo and Frescobaldi, but I was stuck and no one else did this
> apparently simple job:
> https://github.com/gperciva/lilypond-extra/issues/20

You cannot really expect LilyPond developers to keep track of some
GitHub issue tracker.

> The website home page should be the easiest thing to update. Let's see
> who will volunteer for this.
>
> Refusing any change because it's a change is not good for the LilyPond
> project.

That's ridiculous.  The problem is not that "it's a change" but because
the expected benefits of a change need to more than offset the expected
costs in the long term.

And the current website infrastructure as well as how it is kept up to
date with ongoing work by developers and translators, as much as you
detest it, is a rather high hurdle to pass for any proposed alternative
system.

And that means that there is a _lot_ of work to do before it will make
sense switching the website out.  And it is quite possible that the
project will not make it to a state where switching the existing website
out would even make sense.

> It brings only to stagnation.

There are lots of projects that could only dream of stagnating at the
level of our web pages.  The purpose of the web pages has not changed
over the last few decades.  Neither has the basic HTML rendering
technology changed.  A new tool set will still have to operate within
the existing frameworks and paradigms.

Texinfo has been there for something like 30 years and will still be
there in 10 years.  Can you say the same about Getbootstrap and Cactus?
If not, who will be responsible for migrating the web pages to the next
new technology?

-- 
David Kastrup