Re: Remove old "News" entry from home page

[Urs Liska]

I'm afraid David is right with many things here, although I'd prefer him
being more moderated in his tone. Federico is laying his finger on an
obviously problematic issue, and he's actively thinking about possible
solutions. Maybe his ideas aren't going to work out for inherent
problems, maybe not simply because he might not be persuasive enough.
Anyway I don't see a reason or even a justification to be so harsh.

I agree that changing *anything* in our system to build documentation
and website is a huge undertaking, and it may be an all-or-nothing issue
with enormous implications. And I can agree to some extent that it may
even be the right way for LilyPond to be "old-fashioned" or conservative
in such things. It is not enough to think about "standard conforming"
technologies but they have to be able to be used by a vast majority of
browsers/readers, and they should think in terms of decades.

But it *is* a problem that changing anything on the website is such an
involved process - both in terms of the used infrastructure *and* in
terms of the review process. This *is* scaring away people who would be
able to support the project with their work and creativity.

I will only comment on a very small number of things below, but in
general I would say that it shouldn't be ruled out a priori to separate
the documentation from the website.
The website is a kind of showcase and a place for general information,
and it's a place for advertising. It would be good if that could be
developed in a more "fluid" way to react to trends more accurately. And
it might be useful to keep that part more "modern" and thus "appealing",
even if it means doing significant changes in technology every once in a
while.
On the other hand we have the manuals which are inherently complex and
much less open to changes. And they are very much tied to actual
development, that's right.
But the "website" doesn't have to be available as PDF or as info
documents if the manuals are. So I don't see anything speaking against
having a "website" that is developed using arbitrary technologies that
may even change every two years and having the manuals in their
traditional infrastructure and appearance, located at their proper
places inside or attached to the website.
In fact the current construct has some striking glitches that are
confusing for developers and visitors alike and that are due to the fact
that the "website" is maintained as part of the "documentation". Just
one example: Why on earth can you access a (fuzzy) copy of the website
as part of the documentation? Just compare
http://lilypond.org to
http://lilypond.org/doc/v2.18/Documentation/web/index.html
and the respective paths in the build directory.

Am 18.07.2015 um 23:35 schrieb 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.

I have to disagree here. The documentation inherently has to be
maintained by the developers but the website doesn't. The website
actually can be edited by people without having any technical knowledge
about LilyPond. And if website and documentation were separated this
wouldn't be an issue but would  allow an unknown number of people  to
consider contributing to the website.

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

That's unfair argumentation.
Federico suggests that *the website* doesn't have to be available in PDF
or info format. He doesn't speak of manuals.


> ...
>

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

This link is part of the manuals and should be separated from the
website part. So the answer to your question is: the documentation
writers/translators will write this page as now.

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

That's wrong.
If you want to change anything involving media files you have to update
github.com/gperciva/lilypond-extra. Therefore the people with the
appropriate privileges on that repository have the duty to handle pull
requests.
(This is not meant to be anything against these people - I don't know
what was the problem here)

>
>> The website home page should be the easiest thing to update. Let's see
>> who will volunteer for this.
>>
>>
>> ...
> 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?
>

Yes, that's of course true. But nevertheless I think one shouldn't rule
out the question of separating website and documentation - technically
and conceptually.

Urs