IRC is fine for almost synchronous communication - but dealing with things that work on the timescale of days or weeks, IRC becomes difficult to maintain a discussion about a fix or feature over that timeframe that includes all the interested participants.

Mailing lists often come with an archive and a sufficiently large project will have multiple lists for different aspects of the project. Consider gcc ( gcc.gnu.org/lists.html )and you’ll see that bugs and patches are their own lists. Going into there you can also see the archives for the project… and if the mailing list software has support for it, viable by thread gcc.gnu.org/pipermail/gcc-bugs/

lkml.org/lkml/2013/11/25/519 is another fun read (that entire thread).

git has support for (and was originally used via) email. git send-email (docs) and git am (docs) are part of its original functionality and that workflow can make use if it.

I’m personally most comfortable with GitHub or GitLab, followed by email. An IRC or discord project lacks the ability to properly research the “why was this done that way back in 2016”… unless the project doesn’t aspire to be a long lived open source project.

Managing email is something that should be considered as part of this. Setting up a separate email address for that project, or using the + addressing as part of the email to make it so that your email filters can operate on them better (Exchange, gmail). This may require deeper familiarity with email clients than is common today - smart mailboxes in Mac Mail, client side rules in Exchange, or old school procmail with a shell account.