Re: Choice of bug tracker

[Eli Zaretskii]

> Date: Wed, 30 Aug 2023 03:11:21 +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>
> 
> >    . we must have support for features 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.

We could produce a detailed list of capabilities that must not regress
wrt debbugs, if that would be useful.  The number of those
capabilities is small.

> 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.

I think it would be unfortunate to ask users to create an account just
to report a bug and ask questions about it.  At least the email
gateway should be free of this complication (for casual submitters,
not for the developers and maintainers whom we could ask to register).

> >    . 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.

I thought that was the single most important deficiency of debbugs?

If they aren't, then which capabilities _are_ important to have that
we don't have on debbugs?