Jean Abou Samra <j...@abou-samra.fr> writes: > Le 16/10/2021 à 13:09, David Kastrup a écrit : >> Jean Abou Samra <j...@abou-samra.fr> 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-lilyp...@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
