[neomutt-devel] Shooting for Zero

[David Sterba]

On Sat, Feb 25, 2017 at 03:08:55PM +0100, toogley at mailbox.org wrote:
> 
> > On February 25, 2017 at 2:51 PM Richard Russon <rich at flatcap.org> wrote:
> > [...]
> > What should we do with the long-standing issues?
> > Should we put time limits on certain types?
> > 
> > What should we do with:
> > - Questions we can't answer
> > - Enhancements we'll never attempt
> > - Discussions that won't end
> > - Bugs we can't fix
> 
> 1. What do you mean with list points? I ask because its written as absolut ("can't"), so excluding very difficult questions. Therefore the question for clarification.
> 
> 2. I think we should keep enhancements which are unlikely to be implemented open (e.g. having a GUI for mutt (i know we have no such suggestion, but its just an example for sth very unlikely to happen in the next years), having true color support, etc.) Just look at mutt's history, it lasted about 20 years and still continues. I conclude from that that we don't know when and even if neomutt will ever stop being developed. That also means that we won't be able to predict what'll happen in 5 years or so. 
>     2.1 Maybe we have such a good codebase until then, that such issues are rather easy to implement?
>     2.2 Maybe some hero implements one of the difficult suggestions in a way we like?
> 
> Closing such enhancement issues will prevent/slow this development down, IMHO. Therefore i would just keep them open and leave a note that this will probably take a long long time to be implement.

> 3. IMHO, we are a projekt of multiple developers with different opinions. So when a diskussion hasn't finished, we have not found a consens we can all agree on. And IMHO, that's important in an open source projekt. (Of course, persons discussing should be sensible and argument rationally)

I'd suggest to move the listed types of issues to documentation or wiki,
possibly linking back to the original issue and explaining why it's
considered impractical to fix/answer/etc. Best if there's a consensus
for particular issue and all arguments are voiced. I do not mean issues
or tasks that have an active developer behind them, more like avoid
polluting the tracker. Not listing the dead issues would make it appear
cleaner for an issue to pick.