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