Re: What is the point of bug-lilypond?

[Jonas Hahnfeld]

Am Samstag, dem 16.10.2021 um 12:55 +0200 schrieb Jean Abou Samra:
> We're all volunteers and nobody is entitled
> to respond to bug reports. So if one slips
> through the cracks occasionally, I believe
> it's better to have it in the database and
> keep it for future developers walking around
> there than let it be forgotten about. (I do
> walk around a lot in the tracker, including
> 10-year-old issues, and sometimes they give
> nice ideas. \vshape was born like that.)

In my opinion, this is a very weak argument: The archives of bug-
lilypond go back more than 20 years (first month is 2001-07). This is
longer than any bug tracker was used (Google Code, SourceForge) and I
would bet it is longer than GitLab will be used.

> > > Ignoring a report is my opinion the worst of all outcomes since
> > > it not only loses information but discourages people to engage
> > > in later reports or further investigation. 
> > 
> > Nothing is lost. Also I am not so sure it does discourage engagement 
> > that much, if a bug is that big a deal and we miss it, then I am sure 
> > that another person would report it, again we've plenty to do as it is.
> 
> I was talking about engagement from the user reporting
> the bug.

Honest question: Do you really expect this to change if issues are
opened on GitLab instead of sent to a mailing list? If it's a good
report but nobody starts to work on it immediately, there won't be a
response on GitLab either. Right now, there's at least the
acknowledgement that it is considered a bug and an issue was opened.

> 
> > > The information for maintainers of GNU software agree with me:
> > > 
> > > https://www.gnu.org/prep/maintain/maintain.html#Replying-to-Mail
> > > 
> > >    When you receive bug reports, keep in mind that bug reports are
> > >    crucial for your work. If you don’t know about problems, you cannot
> > >    fix them. So always thank each person who sends a bug report.
> > Which we do but this assumes that everything sent to bug email list is 
> > a bug (they aren't).
> 
> See the following paragraphs though:
> 
>     You don’t have an obligation to give more response than that,
>     though. The main purpose of bug reports is to help you contribute
>     to the community by improving the next version of the program. Many
>     of the people who report bugs don’t realize this—they think that
>     the point is for you to help them individually. Some will ask you
>     to focus on that instead of on making the program better. If you
>     comply with their wishes, you will have been distracted from the
>     job of maintaining the program.
> 
>     For example, people sometimes report a bug in a vague (and
>     therefore useless) way, and when you ask for more information, they
>     say, “I just wanted to see if you already knew the solution” (in
>     which case the bug report would do nothing to help improve the
>     program). When this happens, you should explain to them the real
>     purpose of bug reports. (A canned explanation will make this more
>     efficient.)

I read the second paragraph as yet another argument in favor of having
a mailing list because this type of discussion (is it a bug or not?) is
better suited there.

> [...]
> 
> How about experimenting with it? We can recommend
> GitLab for bug reports on the website during two months
> and see how it fares.

This doesn't make sense to me, bug reporting isn't something you do A/B
testing with. Either we decide on something or we don't.

So let me add my two cents to the discussion:
 - I agree with David and the quoted excerpts of "Information for
Maintainers of GNU Software" that we should continue to accept bug
reports via a mailing list. In parts because this is an expectation for
GNU software, in parts because some people might consider it easier
than using a web interface, and lastly because gitlab.com is not
officially endorsed by the FSF (one of the reasons why the main
branches continue to be mirrored to Savannah).
 - In my opinion, it doesn't make sense to move this type of task to
lilypond-devel - the entire point of bug-lilypond is that reports stay
out of development discussions.
 - Users are already opening issues on GitLab. Maybe it makes sense to
rephrase http://lilypond.org/bug-reports.html to not discourage this
for advanced people, but for all the reasons that James mentioned, I
think it makes sense for bug-lilypond to remain the "default" place
where users report issues / bugs / things they are not sure about.

Jonas

signature.asc
Description: This is a digitally signed message part