Re: [RFC] Use GitLab Milestones

[Valentin Villenave]

On 6/23/20, Jonas Hahnfeld <hahnjo@hahnjo.de> wrote:
> I knew that description and, honestly, that would be a show stopper for
> me reporting any issue to a project in 2020.

Why?  Because mailing lists are a thing of the past in your view? :-)

Sending an e-mail to an open mailing list is much more universal and
accessible than requiring a GitLab subscription (which mandates to go
through at least one if not several Google ReCaptchas, is blocking
some public proxies and Tor nodes, etc.).

It’s simple enough: we don’t forbid anyone from opening issues
directly on the tracker, but we do discourage it because most of the
time it turns to be either not a bug (LilyPond is a complex program
with its fair share of unexpected or inconsistent behaviors) or an
already known bug (and with 6000 tracker pages of which more than 1000
are still open, finding duplicates is actually pretty difficult for a
newcomer).

Besides, going through the bug list allows users to interact with
knowledgeable people who (unlike on -user) are used to turning a large
example into a minimal one, to translating layman terms into LilyPond
jargon that the devs are more likely to be familiar with, etc. Look
for example at this recent issue opened directly on the tracker, and
compare the original report (which I had to re-label and edit because
of a Markdown syntax error) with the comment I left:
https://gitlab.com/lilypond/lilypond/-/issues/6004

On the Google tracker (IIRC), any new issue was automatically given
the label Status::New. That doesn’t seem to be the case here, so there
*could* be an argument that “unlabelled” should be the new
“Status::New”. I don’t like it that much (ideally, “Status” should
behave like “Patch” and follow a predictable sequence of states, from
“New” to “Verified”) but if that’s technically more convenient, why
not.

Cheers,
-- V.