Background of Epyrus
Epyrus was first conceived of sometime around March or April of 2022, after I started to feel another UXP-based e-mail client was needed, but found that there were complications that would prevent the revival of Fossamail. The original codename was actually Mercurius Civicus very briefly, before I came up with the codename Hermopolis and finally settled on Epyrus as the browser's final name.
IceDove-UXP was out there and seemingly had good bones, but too much that I found useful had been stripped out due to FOSS principles, it was really only maintained for a specific Linux distro, it had a different setup than what I was used to working on Pale Moon, and wasn't really tested on other platforms at all.
Look and Feel of Epyrus
Most other UXP-based e-mail clients are loosely based on some kind of historical precedent. Mine is intended to be based on an alternate history that isn't too hard to imagine. Imagine that instead of Thunderbird being spun off and dealt with by the SeaMonkey team and the people who develop the suite, it had been developed as a first-class application alongside pre-Australis Firefox and given a similar "Phoenix" treatement. Also, imagine that the AppMenu had been implemented as planned in Thunderbird at one point, rather than being skipped in favor of the hamburger menu.
The AppMenu in Thunderbird was meant to be blue originally, much like Pale Moon's AppMenu. So in this parallel reality, Thunderbird would be an application with a blue AppMenu, and Firefox would be an application with an orange AppMenu. And with Epyrus and Pale Moon, which forked from them... this would be swapped around, with Pale Moon having blue and Epyrus having orange.
Development Philosophy of Epyrus
Epyrus development is intended to be similar to Pale Moon development in a very broad sense so that it's fairly easy for people who are used to working on Pale Moon to start working on this application, and most of the same rules and procedures carry over.
The idea is that it will be a slightly "sloppier" way of development than the way I've been trained in and grown accustomed to working on MCP projects over the years, but still overall done in a similar way. For instance, with Epyrus... while creating the issue first is still preferred, I won't consider it a big problem if I see a development branch where someone has fixed something and they have a placeholder for an issue number (something like Issue #TBA or Issue #XXX). I would probably just create an issue, cite the commit and the fact that I've created an issue to track the problem they attempted to fix, and go along with it. If I see something mostly complete on someone else's branch that's been sitting there for a while in that state, I may expedite the process, pick up where they left off, and do part of the work myself if I think I understand what is needed, or think that it's complete enough to be worth risking. If something is merely untested, I may just try to test it myself rather than wait on someone to test their own PR if that is what is holding things up.
If there were more contributors competing for attention or offering to deal with the same issue, the process would theoretically become more like the standard MCP process and scale up naturally, but as long as there are less than a handful of contributors and I can personally watch everything they are doing with their forks, this works fine.