Re: Choice of bug tracker

[Dmitry Gutov]

On 29/08/2023 14:26, Eli Zaretskii wrote:
> > Date: Tue, 29 Aug 2023 00:16:09 +0300
> > Cc: philipk@posteo.net, danny@dfreeman.email, stefankangas@gmail.com,
> >   emacs-devel@gnu.org, manuel.uberti@inventati.org
> > From: Dmitry Gutov <dmitry@gutov.dev>
> >
> > > The problem from my POV was that alternatives were researched, the
> > > results of the research were published and discussed, the downsides
> > > identified, and then the process stalled, perhaps because people got
> > > disappointed by the deficiencies.
> >
> > Last time we produced this overblown list which mixed necessities with
> > nice-to-haves: https://gitlab.com/gitlab-org/gitlab/-/issues/28152
>
> That list is just our reference and a repository of ideas that came up
> in the discussions.  The real requirements are simpler:
>
>    . we must have support for feature we have now on debbugs

As a very reluctant user of Debbugs, I have say this is not a clear 
description for me. But as mentioned previously, the main features like 
modifying bug reports from email should either work, or are possible to 
implement/fix in a reasonable time frame.

The main thing I'm not sure about are bug reports from users without 
accounts, without requiring them to make accounts before making a bug 
report. We could even create an email address with an account which 
would create reports under its name, but forwarding subsequent 
correspondence on those issues back and forth seems more difficult. It's 
like we'd have to reimplement a mailing list, basically, but not a 
public one.

>    . we should decide which additional features are the absolute
>      minimum to justify the switch (those which will attract
>      contributors, make feedback easier, and help people who are more
>      used to PR-type workflow)

FWIW, PRs/MRs can be initially disabled, if most of the heavy 
contributors prefer to stay on the email-driven workflow.

Then, as people get comfortable with the rest of the changes, we can try 
and see how the presence of MRs from various contributors affects 
everybody's ability to review code and comment on them. Enable them for 
a certain period, and experiment, and so on.