Re: What is the point of bug-lilypond?

[Jean Abou Samra]

Le 16/10/2021 à 14:28, David Kastrup a écrit
> bug-lilypond@gnu.org is not a subscribers-only list and it is expected
> that responses include a Cc: to the sender.


Ah, ok. I had inferred the contrary from
http://lilypond.org/bug-reports.html


> > > b) read up on the categories and flags we use for bug reports
> > Again, I was _not_ proposing to ask users to do that
> > at all. To report a problem, open an issue and that's
> > all. Just like "send an email and that's all".
> And ignore all the bits and pieces shown in the bug tracker?  Basically
> force people to use a complex tool and give them the option of either
> appearing incompetent by not actually using the tool as intended or
> investing a lot of additional time for figuring out things?
>
> > Adding labels is the role of the same people who
> > triage bug-lilypond now.
> Doesn't sound like you are saving those "same people" a lot of work
> while adding it (or the impression) to those reporting it.
>
> > > c) triage their bug and determine the proper categories and severity
> > Similarly, no.
> And how are they to figure this out?  Particularly when they see how
> other people are cleaning up their issue and changing it around?


By reading an updated version of the guidelines at
http://lilypond.org/bug-reports.html


> > > d) enter their bug into GitLab and deal with responses That's
> > > basically giving the message "non-programmers and casual users:
> > > don't even bother". For a programming library, that may be sort of a
> > > reasonable tradeoff. For an application intended for musicians, I
> > > don't see that.
> > For the reasons above, I don't think so.
> I think your model of what a "user" should be thinking, doing, and
> feeling might be assuming too much.  There is a reason we arrived at
> such a low-barrier method of doing things.  We already were working with
> web-interface based bug trackers when we designed our current processes
> and the discussions are not new.  Lowering the barrier of participation
> for an application primarily addressing the needs of musicians rather
> than programmers was a real issue already while Graham had been leading
> the project.  I don't think that the principal problems have changed,
> really.
>
> Personally, I know that I myself (and I am not really a non-programmer)
> tend to think twice about reporting problems to applications that
> require me to sign up to some tracker or whatnot before accepting my
> feedback.  I won't enter into that kind of commitment for something
> unless really necessary.


Le 16/10/2021 à 14:18, Jonas Hahnfeld a écrit :
> 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.


Is anybody actually reading these archives though?
I don't. I would if they supported filtering out
all the bugs that have been fixed in the meantime.


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


Take the bug report:

https://lists.gnu.org/archive/html/guile-user/2021-06/msg00065.html
https://lists.gnu.org/archive/html/guile-devel/2021-07/msg00001.html
https://lists.gnu.org/archive/html/bug-guile/2021-08/msg00007.html

Ignored on guile-user, ignored on guile-devel.
So I finally sent it to bug-guile, where nobody
reacted either. I feel safer having dumped it
on the Guile bug tracker (through bug-guile) because
when in 2 years (let's hope...) Guile gets
developers who look at bug reports, they might
notice it.



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

Hm. Non-FSF-endorsement is a good point
(those I'm not replying to are as well).


>   - 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
> rephrasehttp://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.


Why not. How would those involved in this discussion
feel about the following?


diff --git a/Documentation/en/web/community.itexi 
b/Documentation/en/web/community.itexi
index 0602ddcace..2a75edcd7f 100644
--- a/Documentation/en/web/community.itexi
+++ b/Documentation/en/web/community.itexi
@@ -383,35 +383,30 @@ quite often 4 lines are enough to demonstrate the 
problem!
 @node Bug reports
 @unnumberedsec Bug reports

-
 @divClass{heading-center}
 If you have input that results in a crash or wrong output,
-then that is a bug.
+then that is a bug.  We handle feature requests in the same
+way as bug reports; collectively, they form @qq{issues}.
 @divEnd

 @divClass{column-center-top}
-@subheading Step 1: Known bugs
+@subheading Step 1: Known issues

-We may already know about this bug.  Check here:
+We may already know about this issue.  Check our issue tracker:

 @example
 @uref{https://gitlab.com/lilypond/lilypond/-/issues}
 @end example
-
-@warning{Please @strong{DO NOT} add bug reports directly to the
-bug tracker.  Once an issue has been added to the tracker, feel
-free to add more information to that report.}
-
 @divEnd


 @divClass{column-left-bottom}
-@subheading Step 2: Creating a bug report
+@subheading Step 2: Creating a report

-If you have discovered a bug which is not listed,
-please help us by creating a bug report.
+If you have discovered a bug that is not listed, or wish
+an enhancement that is not listed, please let us know.

-@warning{We only accept reports in the form of
+@warning{We only accept bug reports in the form of
 @ref{Tiny examples}.  We have very limited resources,
 so any non-minimal example will be rejected.  Almost
 every bug can be demonstrated in four notes or less!}
@@ -433,41 +428,56 @@ Here is an example of a good bug report:
 @divEnd

 @divClass{column-right-bottom}
-@subheading Step 3: Sending a bug report
+@subheading Step 3: Sending a report

-Once you have verified that the issue is not already known and
-created a bug report, please send it to us!
+If you are certain that your report is not already in the
+database, you may add it to the tracker directly.  Pick a
+short and informative title, and write a description, with
+sample code enclosed in backticks.

-Unfortunately there is no longer an interface for posting to the
-bug-lilypond list without subscribing; see
 @example
-@uref{https://lists.gnu.org/mailman/listinfo/bug-lilypond}
+Here is a minimal example:
+
+```
+\version "2.10.1"
+
+\relative c'' @{
+ bes1 ~
+ bes1
+@}
+```
 @end example
-for more information.
+
+We will add appropriate labels for you.
+
+If you are not overly certain, or if you prefer email, please
+write to the @uref{https://lists.gnu.org/mailman/listinfo/bug-lilypond,
+@code{bug-lilypond}} mailing list at @uref{mailto:bug-lilypond@@gnu.org,
+bug-lilypond@@gnu.org}.  We will examine your report and add
+it to the tracker if appropriate, taking care of details.
 @divEnd

 @divClass{column-center-bottom}
 @subheading Step 4: Wait for a response

-Once your bug report has been sent to the list, our Bug Squad will
-examine it; they may ask you for more information.  You will be notified
-when the report will be added to the bug tracker.  Please allow up to 4
-days, as we have a limited number of volunteers for this task.
+If you sent the report to @code{bug-lilypond}, you will be
+notified when the report has been added to the bug tracker.
+Please allow some days, as we have a limited number of
+volunteers for this task.

-Once a bug has been added to the tracker, you can comment it to add
-more information about it.
-In order to be automatically notified about any activity on the
-tracker issue, you may subscribe by clicking the envelope
-symbol next to the issue title.
+Once an issue is in the tracker, you can comment on it to
+add more information about it.  If you have not created
+the issue yourself, you may choose to be notified about
+any activity on the issue using the dedicated button in
+the right pane (after logging into GitLab).
 @divEnd

 @divClass{column-center-bottom}
 @subheading Optional help: show the desired behavior

-Once an issue has been added to the tracker, it can be very
-helpful if we can see the desired output.  Feel free to add input
-code and/or images (possibly created with other tools) which
-demonstrate what you think it should look like!
+A helpful adjunct to a bug report is the desired output.  Feel
+free to add input code and/or images (possibly created with other
+tools) which demonstrate what you think it should look like!

 @divEnd


Regards,
Jean