Re: What is the point of bug-lilypond?
Jean Abou Samra writes: > (Sorry, not replying to all was an oversight.) > > On 16/10/2021 17:31, Dan Eble wrote: >> On Oct 16, 2021, at 10:58, Jonas Hahnfeld via Discussions on >> LilyPond development wrote: >> > >> > in my opinion we want to >> > send users to the mailing list by default. >> >> I don't devote much time to handling bugs (until I'm tagged), but >> the reports that have come directly through the GitLab UI have been >> of mixed quality. Triage on the mailing list is beneficial. > > OK, I'm the only weirdly opinionated one in the room. Let's scrap the > proposal. I think it's worth pointing out that "triage on the mailing list is beneficial" is glossing over the real point: James is doing a great job. This discussion is sort of staying in the abstract about this point but without someone dedicated to actually maintaining the connection between mailing list and bug tracker (historically, we had a "bug squad" with a "Bug Meister" who is still listed as Colin Hall, but unless I am mistaken, it's mostly James who is actually working in this function in addition to being "Patch Meister") the situation would look different under evaluation. The setup involving a number of volunteers as a precursor to getting them more into the project was something that Graham set up and was rather successful at keeping at work. It eroded during my tenure and current developers may take for granted the position(s) that James has unerringly been serving in for a really really large amount of time now. Given the rather large and ongoing service he has provided to LilyPond, it's a bit jarring to see that kind of discussion where his role and involvement are sort of given the kind of consideration that a CI script gets. Not that I am guilty of that here myself: the average LilyPond developer's experience and opinion about the topic may differ from Jean's exactly because we've seen and discussed the difference this makes to LilyPond, but part of the reason it does of course is that there actually are/is people/someone who care/s. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: What is the point of bug-lilypond?
(Sorry, not replying to all was an oversight.) On 16/10/2021 17:31, Dan Eble wrote: On Oct 16, 2021, at 10:58, Jonas Hahnfeld via Discussions on LilyPond development wrote: > > in my opinion we want to > send users to the mailing list by default. I don't devote much time to handling bugs (until I'm tagged), but the reports that have come directly through the GitLab UI have been of mixed quality. Triage on the mailing list is beneficial. OK, I'm the only weirdly opinionated one in the room. Let's scrap the proposal. Thanks for the feedback, Jean ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: What is the point of bug-lilypond?
On 10/16/21, 4:55 AM, "lilypond-devel on behalf of Jean Abou Samra" wrote: A factor to consider is that, as far as I can read http://lilypond.org/bug-reports.html (but I can't remember how it worked for myself), posting to bug-lilypond requires being subscribed to the list, thus receiving all subsequent bug reports, which is not what a user wants. On GitLab, just turn on notifications for an issue if you are interested in it. This is turned on by default if you are the author of the report. When I started with bug-lilypond, posting did not require subscribing. Now, apparently, it does, probably to avoid spam (we had a problem with spam on bug-lilypond for a while). However, one can subscribe to the list and turn off all emails. It's also a question of communication. With bug-lilypond, a bug report is supposedd not to immediately interface with developers (for some definition of this term). A drawback of GitLab issues is that everyone there receives notification for all reports including those that are not actually valid. I would actually turn this to an advantage: it's often interesting to see common failure patterns (leading to better interfaces and/or better documentation). I have turned off GitLab issues, because I don’t want to be swamped with the updates. I am, however, subscribed to bug-lilypond so I can see what problems come up and will respond to those that I feel a need to. I would be really disappointed if we replaced bug-lilypond with GitLab issues. GitLab issues give you the whole history. bug-lilypond just gives you the report and the issue number for the created issue (if I want more information). I would stop interacting with bug reports entirely if bug-lilypond is replace with direct submission to GitLab issues. Thanks, Carl ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: What is the point of bug-lilypond?
On Oct 16, 2021, at 10:58, Jonas Hahnfeld via Discussions on LilyPond development wrote: > > in my opinion we want to > send users to the mailing list by default. I don't devote much time to handling bugs (until I'm tagged), but the reports that have come directly through the GitLab UI have been of mixed quality. Triage on the mailing list is beneficial. — Dan ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: What is the point of bug-lilypond?
Am Samstag, dem 16.10.2021 um 16:33 +0200 schrieb Jean Abou Samra:
> > > > 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/msg1.html
> > > https://lists.gnu.org/archive/html/bug-guile/2021-08/msg7.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.
> > Pointing to bad experiences with other projects is not exactly a
> > convincing argument to me with respect to LilyPond.
>
> I gave an example with a LilyPond user above.
>
> Given that I have for some time not frequently been
> wondering if something in LilyPond was a bug where
> others could tell it to me, it is not easy to find
> anything better.
I would interpret this fact as "the current process works" (mostly).
> > > >- 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}.
> > I think this is unrelated to the current discussion. It definitely
> > feels wrong on a page titled "Bug reports".
> >
> > > @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.
> > No no no! Everybody thinks their problem is unique and is absolutely
> > "certain" about that, that's why we can also use bug-lilypond to
> > deduplicate reports.
>
>
> Can you propose a better phrasing, please?
I would *only* change the "DO NOT" warning above to maybe "If an issue
has already been added to the tracker, feel
Re: What is the point of bug-lilypond?
Le 16/10/2021 à 16:03, Jonas Hahnfeld a écrit :
Am Samstag, dem 16.10.2021 um 15:49 +0200 schrieb Jean Abou Samra:
Honestly, it doesn't make sense to extrapolate from you to others. I
certainly do if I'm interested in the history of particular decisions,
and I think I've shared collections of links for past discussions.
There is no point in discussing this if we've agreed
on the resolution.
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/msg1.html
https://lists.gnu.org/archive/html/bug-guile/2021-08/msg7.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.
Pointing to bad experiences with other projects is not exactly a
convincing argument to me with respect to LilyPond.
I gave an example with a LilyPond user above.
Given that I have for some time not frequently been
wondering if something in LilyPond was a bug where
others could tell it to me, it is not easy to find
anything better.
- 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}.
I think this is unrelated to the current discussion. It definitely
feels wrong on a page titled "Bug reports".
@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.
No no no! Everybody thinks their problem is unique and is absolutely
"certain" about that, that's why we can also use bug-lilypond to
deduplicate reports.
Can you propose a better phrasing, please?
-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
Re: What is the point of bug-lilypond?
Am Samstag, dem 16.10.2021 um 15:49 +0200 schrieb Jean Abou Samra:
>
> 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.
Honestly, it doesn't make sense to extrapolate from you to others. I
certainly do if I'm interested in the history of particular decisions,
and I think I've shared collections of links for past discussions.
> 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/msg1.html
> https://lists.gnu.org/archive/html/bug-guile/2021-08/msg7.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.
Pointing to bad experiences with other projects is not exactly a
convincing argument to me with respect to LilyPond.
> > - 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}.
I think this is unrelated to the current discussion. It definitely
feels wrong on a page titled "Bug reports".
> @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
>
Re: What is the point of bug-lilypond?
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/msg1.html https://lists.gnu.org/archive/html/bug-guile/2021-08/msg7.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
Re: What is the point of bug-lilypond?
Jean Abou Samra writes: > Le 16/10/2021 à 13:09, David Kastrup a écrit : >> Jean Abou Samra writes: >>> Hi James, Werner, all, I would say that 'most' emails to the bug list do NOT need an issue, they are either replies to emails or pointers to existing Issues that explain bug or technical discussions about why something is not a bug but a limitation of what is possible based on how we code things (which itself engenders more emails). >>> Yes, absolutely -- and you're doing this very well. However, when >>> you decide that the report calls for an issue, do you edit it >>> (change example, use different terms) or is it good enough to be >>> pasted as-is? I may be wrong, and I certainly do not want to >>> diminish your work on bug reports, but I had the impression that >>> most often the issue was made just from the email thread. That's >>> also what I usually do. To be clear, I am not proposing that we >>> change anything to the way we respond to bug reports (discussing >>> whether it's a bug, pointing to documentation, etc.) which is >>> handled very well as it is. It just appears to me that the >>> bug-lilypond mailing list is redundant as the same tasks can be >>> done better via the issue tracker. >> I disagree. "can be done better via the issue tracker" glosses over >> who does the stuff. Having a mailing list to report bugs gives us a >> low barrier to receive user feedback regarding problems, perceived >> and genuine. Leaving only the tracker requires anybody encountering >> a problem to a) register an account on GitLab > > > Well, compare this to subscribing to the list > and receiving others' bug reports afterwards. bug-lilypond@gnu.org is not a subscribers-only list and it is expected that responses include a Cc: to the sender. >> 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? >> 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. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: What is the point of bug-lilypond?
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 ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: What is the point of bug-lilypond?
Le 16/10/2021 à 13:09, David Kastrup a écrit : Jean Abou Samra writes: Hi James, Werner, all, I would say that 'most' emails to the bug list do NOT need an issue, they are either replies to emails or pointers to existing Issues that explain bug or technical discussions about why something is not a bug but a limitation of what is possible based on how we code things (which itself engenders more emails). Yes, absolutely -- and you're doing this very well. However, when you decide that the report calls for an issue, do you edit it (change example, use different terms) or is it good enough to be pasted as-is? I may be wrong, and I certainly do not want to diminish your work on bug reports, but I had the impression that most often the issue was made just from the email thread. That's also what I usually do. To be clear, I am not proposing that we change anything to the way we respond to bug reports (discussing whether it's a bug, pointing to documentation, etc.) which is handled very well as it is. It just appears to me that the bug-lilypond mailing list is redundant as the same tasks can be done better via the issue tracker. I disagree. "can be done better via the issue tracker" glosses over who does the stuff. Having a mailing list to report bugs gives us a low barrier to receive user feedback regarding problems, perceived and genuine. Leaving only the tracker requires anybody encountering a problem to a) register an account on GitLab Well, compare this to subscribing to the list and receiving others' bug reports afterwards. 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". Adding labels is the role of the same people who triage bug-lilypond now. c) triage their bug and determine the proper categories and severity Similarly, no. 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. There may be a generational effect in views on the ease of working with mailing lists. I can at least see a lot of software not primarily intended for programmers directing bug reports to a web system directly. Examples: Firefox, WikiMedia, GIMP (GNU software), LibreOffice, MuseScore, Frescobaldi. Additionally having a bug-...@gnu.org mailing list for receiving bug reports is standard for GNU applications, so even for some important subset of programmers it is the expectation that this should be a way to enter problem reports. What the guidelines say about it is Once a program is in use, you will get bug reports for it. Most GNU programs have their own special lists for sending bug reports. The advertised bug-reporting email address should always be ‘bug-pack...@gnu.org’, to help show users that the program is a GNU package, but it is ok to set up that list to forward to another site if you prefer. We also have a catch-all list, bug-gnu-ut...@gnu.org, which is used for all GNU programs that don’t have their own specific lists. But nowadays we want to give each program its own bug-reporting list and move away from using bug-gnu-utils. “Most GNU programs” does not suggest that this is a requirement. If it is a concern nevertheless, the bug-lilypond address can be made to redirect to a GitLab address that opens issues (every GitLab user can have one per project; this one could be LilyPond Bot's). Regards, Jean ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: What is the point of bug-lilypond?
Jean Abou Samra writes: > Hi James, Werner, all, >> >> I would say that 'most' emails to the bug list do NOT need an issue, >> they are either replies to emails or pointers to existing Issues that >> explain bug or technical discussions about why something is not a bug >> but a limitation of what is possible based on how we code things >> (which itself engenders more emails). > > > Yes, absolutely -- and you're doing this very well. > However, when you decide that the report calls > for an issue, do you edit it (change example, > use different terms) or is it good enough to > be pasted as-is? I may be wrong, and I certainly > do not want to diminish your work on bug reports, > but I had the impression that most often > the issue was made just from the email thread. > That's also what I usually do. > > To be clear, I am not proposing that we change > anything to the way we respond to bug reports > (discussing whether it's a bug, pointing to > documentation, etc.) which is handled very well > as it is. It just appears to me that the bug-lilypond > mailing list is redundant as the same tasks can be > done better via the issue tracker. I disagree. "can be done better via the issue tracker" glosses over who does the stuff. Having a mailing list to report bugs gives us a low barrier to receive user feedback regarding problems, perceived and genuine. Leaving only the tracker requires anybody encountering a problem to a) register an account on GitLab b) read up on the categories and flags we use for bug reports c) triage their bug and determine the proper categories and severity 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. Additionally having a bug-...@gnu.org mailing list for receiving bug reports is standard for GNU applications, so even for some important subset of programmers it is the expectation that this should be a way to enter problem reports. Something like bug-gu...@gnu.org immediately gates into a debbug tracker: that's sort of punting on having a bug reporting list (and the documentation does not really mention the list I think) but at least gets stuff into the system (where it sometimes is left to rot without further feedback). That's still preferable to what you propose, but quite worse than having an actual bug reporting list like we have now. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: What is the point of bug-lilypond?
Hi James, Werner, all, Le 14/10/2021 à 08:43, James a écrit : Hello, My own thoughts on this. On 14/10/2021 01:31, Jean Abou Samra wrote: Hi, After having opened a few GitLab issues in response to bug reports on bug-lilypond, I find James extraordinarily patient for having done this over the years. However, I don't get the value in this system compared to letting people creating issues on GitLab directly. When we transfer an issue to GitLab, it's usually just pasting the text from the email report. No it is more than that. It is parsing said bug report - is the thing you are reporting valid? Is it just something a user needs to ask on a different list (e.g. the user is expecting X and is getting Y because they don't understand something but LP is working correctly), is it actually working as designed where the design is not broken but just a hard problem to solve and so on. My day job involves having to tell end-users over and over that X is actually correct because 'reasons' and, at the same time, trying to understand why users think X is a bug when it is not (perhaps improved documentation is all that is needed). So perhaps I am good at this because I have had 20+ years of having to explain this kind of thing to non-technical (or mostly non-interested) people. Sometimes emails to the bug take the form of 'I do X is this expected or is this a bug' which again requires a slightly different tack. I would say that 'most' emails to the bug list do NOT need an issue, they are either replies to emails or pointers to existing Issues that explain bug or technical discussions about why something is not a bug but a limitation of what is possible based on how we code things (which itself engenders more emails). Yes, absolutely -- and you're doing this very well. However, when you decide that the report calls for an issue, do you edit it (change example, use different terms) or is it good enough to be pasted as-is? I may be wrong, and I certainly do not want to diminish your work on bug reports, but I had the impression that most often the issue was made just from the email thread. That's also what I usually do. To be clear, I am not proposing that we change anything to the way we respond to bug reports (discussing whether it's a bug, pointing to documentation, etc.) which is handled very well as it is. It just appears to me that the bug-lilypond mailing list is redundant as the same tasks can be done better via the issue tracker. Right now, bug reports often take a week to be acknowledged, Maybe but what's the rush? It's not like we have KPIs or Sprints to complete or other arcane methodologies to acknowledge to release LP. The information is there, it isn't going anywhere, if someone fees THAT strongly about wanting conformation (or usually affirmation) then they will just reply to their own emails and someone will look, Point taken. and some of them are not acknowledged by us at all. Take https://lists.gnu.org/archive/html/lilypond-user-fr/2021-01/msg00014.html reported 9 months ago, which I just added to the tracker. Which proves my point although this is not from the bug list this is a user list. So the report is not being put to the correct list in the first place. Sorry, that one is just silly me doing too much at a time and pasting the wrong link. The correct one is https://lists.gnu.org/archive/html/bug-lilypond/2021-01/msg1.html The wrong link I gave earlier is actually the lilypond-user-fr thread where, as a user support person, I advised this person to report the behaviour as a bug -- not doing it myself to educate to the good practice of reporting any flaws you find in LilyPond. He did so, and, as a contributor, I (or anyone else) didn't react to the bug report. So I feel this is kind of pointless... 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.) I like the separation of lists (user, dev, bug) I don't subcribe to the user list at all in fact (I am not that interested) and I knew that some developers don't subscribe to the bug list for their own good reason. I am not saying we will catch everyone in a timely manner but we do a pretty good job considering (and this bug was reported on the user list). 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
Re: What is the point of bug-lilypond?
Hello, On 14/10/2021 08:30, Werner LEMBERG wrote: Since James is doing most of the work, I think we should do what he prefers. This doesn't prevent other developers to chime in and help with handling bug reports. And frequent *and experienced* bug reporters should be told to directly use the bug tracker. Oh God! Don't start doing that! ;D I wasn't trying to say 'my way is best'. I was just trying to give a point of view. I think to be very fair to Jean, he has done a lot of bug reports as have others (and he even gets them of the user lists - unlike me!) I was just trying to see if this suggestion is really better than what we do now and if so how or if not perhaps it is better in some ways and not others. If in the end the development team would prefer it changed/different then I will go along with whatever. Regards James ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: What is the point of bug-lilypond?
>> After having opened a few GitLab issues in response to bug reports >> on bug-lilypond, I find James extraordinarily patient for having >> done this over the years. However, I don't get the value in this >> system compared to letting people creating issues on GitLab >> directly. When we transfer an issue to GitLab, it's usually just >> pasting the text from the email report. > > No it is more than that. There are two point of views. Some people (for example, the HarfBuzz developers) don't want e-mail on their mailing list; they prefer that users open issues for both user questions and bug reports. I guess this works because HarfBuzz is a very specialized library, not to be used by Joe User but by developers who already know how good bug reports should look like. The other point of view is that bug reports should be collected in a database, being correctly tagged and as concise and compact as possible. I agree with James that it makes sense to parse and filter reports in advance to achieve that, so I'm on his side. >> Right now, bug reports often take a week to be acknowledged, Well, yes. Not a big problem IMHO. >> So how about retiring bug-lilypond and directing to GitLab instead? >> Tickets can be triaged there, closing invalid ones, adding a >> minimal example if not present, perhaps changing the title. The >> requirement from the same page of GNU guidelines, > > I don't see the difference between triaging GitLab vs triaging Bug > apart from the fact that it is very easy to use bug-list interface > to track email threads - it's so easy to spot of something on the > bug list has had a reply or not. [...] Since James is doing most of the work, I think we should do what he prefers. This doesn't prevent other developers to chime in and help with handling bug reports. And frequent *and experienced* bug reporters should be told to directly use the bug tracker. Werner ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: What is the point of bug-lilypond?
Hello, My own thoughts on this. On 14/10/2021 01:31, Jean Abou Samra wrote: Hi, After having opened a few GitLab issues in response to bug reports on bug-lilypond, I find James extraordinarily patient for having done this over the years. However, I don't get the value in this system compared to letting people creating issues on GitLab directly. When we transfer an issue to GitLab, it's usually just pasting the text from the email report. No it is more than that. It is parsing said bug report - is the thing you are reporting valid? Is it just something a user needs to ask on a different list (e.g. the user is expecting X and is getting Y because they don't understand something but LP is working correctly), is it actually working as designed where the design is not broken but just a hard problem to solve and so on. My day job involves having to tell end-users over and over that X is actually correct because 'reasons' and, at the same time, trying to understand why users think X is a bug when it is not (perhaps improved documentation is all that is needed). So perhaps I am good at this because I have had 20+ years of having to explain this kind of thing to non-technical (or mostly non-interested) people. Sometimes emails to the bug take the form of 'I do X is this expected or is this a bug' which again requires a slightly different tack. I would say that 'most' emails to the bug list do NOT need an issue, they are either replies to emails or pointers to existing Issues that explain bug or technical discussions about why something is not a bug but a limitation of what is possible based on how we code things (which itself engenders more emails). Right now, bug reports often take a week to be acknowledged, Maybe but what's the rush? It's not like we have KPIs or Sprints to complete or other arcane methodologies to acknowledge to release LP. The information is there, it isn't going anywhere, if someone fees THAT strongly about wanting conformation (or usually affirmation) then they will just reply to their own emails and someone will look, and some of them are not acknowledged by us at all. Take https://lists.gnu.org/archive/html/lilypond-user-fr/2021-01/msg00014.html reported 9 months ago, which I just added to the tracker. Which proves my point although this is not from the bug list this is a user list. So the report is not being put to the correct list in the first place. I like the separation of lists (user, dev, bug) I don't subcribe to the user list at all in fact (I am not that interested) and I knew that some developers don't subscribe to the bug list for their own good reason. I am not saying we will catch everyone in a timely manner but we do a pretty good job considering (and this bug was reported on the user list). 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. 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). In spite of us not advertising this as a way to report problems, a number of users have been creating issues on GitLab themselves, likely because that has become enough of a standard in other places. When replies are made on bug-lilypond, someone has to paste them on the ticket as well, for completeness, which leads to an awkward split where one does not know where the discussion is supposed to happen or whether the other person has read a remark on the other channel. But that has always been a problem and will always remain a problem (again I refer you to the bug report you found on the user list, the French user list as well, which is even more removed) also how many times have things been sent to the other user lists or dev lists or even direct to Han-wen/Jan et al? Again I think this is not that big a deal. So how about retiring bug-lilypond and directing to GitLab instead? Tickets can be triaged there, closing invalid ones, adding a minimal example if not present, perhaps changing the title. The requirement from the same page of GNU guidelines, I don't see the difference between triaging GitLab vs triaging Bug apart from the fact that it is very easy to use bug-list interface to track email threads - it's so easy to spot of something on the bug list has had a reply or not. I haven't use GitLab's interface that much
