[neomutt-devel] New marching orders - reviving dead mailing list

[toogley at nixnet.email]

So Neomutt is very complicated and you don't want to create breaking
changes. Also probably only a few people understand the codebase enough
to make big changes (probably only gahr and flatcap?). And last but not
least, it is hard to focus on the big picture since flatcap wants to
think everything carefully through to prevent big mistakes. This limits
your efficiency.

So, I suggest radical change to fix that, basically the OpenBSD way:

for 6 months:
    * make radical refactorings focusing on the big picture of neomutt
    * allow master to be very unstable at this point
    * no feature development, only refactoring
    * work together with gahr and other people who are able to make such
      big refactorings and big committments
    * but don't try to create good first issues and easy tasks
    * after 6 months, finish the old refactoring and try to come to an
      end. If that takes another 3 months, that doesn't matter.
    * remove code which is big, ugly and legacy, you can rewrite it
      after the core architecture/design things work as you want. But
      the advantage is that this frees your mind basically.
    * since it is hard to estimate how long your refactoring will take,
      6 months is only a rough minimal set of how long your refactoring
      will take
    * basically, make necessary radical change easy as it gets

after that:
    * fix bugs and edge cases until neomutt is stable again
    * create many beta releases
    * after one beta release worked a few months, create next stable
      release.
    * start again from above, while the stable relase gets only minimal
      bug fixes.

I think this is the best way to spend your time. Because *after*
thinking first about the architecture, design, and implementation you
want, fixing bugs and edge cases afterwards is much easier and probably
also can be done by newbies since the architecture and stuff is easier
to understand.