Governance of Akkatecture

[Aaronontheweb]

So per my original comment on ThembisileNGQ/Akkatecture#446 (comment)

We, the Akka.NET project team, will not take on the burden of maintaining Akkatecture under any circumstances - it should be an independent project with its own goals, roadmaps, and leadership.

However, what we can do is solve the "homing" problem for Akkatecture using our megaphone to seed a new "official" Akkatecture organization that can act as the successor to Lutando's work.

I've taken some first steps here to help get a fork of Akkatecture situated, but ultimately it will come down to @AfterLutz/maintainers to lead the project and run it. There's no clear roadmap, organizational structure, or direction set for the project yet. That's what I'm going to try to help seed here.

Maintainers and Roles

What is the role of the maintainer? In short, to ensure that the underlying OSS software is maintained - bugs are triaged, releases are pushed, and so forth. Ultimately the maintainers' power comes from showing up and putting in the work to keep the software up-to-date.

Most OSS organizations have an informal structure - maintainers are people who regularly make quality contributions to the project and agree to adhere to the project's standards (CoC, CONTRIBUTORS.md, et al.) Other organizations have a more formal structure with designated roles - at Akka.NET I'm basically the release manager, which means I prepare the new releases, set the milestones for each release, and am responsible for making sure everything that gets merged in follows our QA process. But that's basically it - otherwise all of the other contributors tend to either work on issues that affect their own consumption of Akka.NET (i.e. we have some heavy Akka.Persistence users who work primarily on that) or things they personally find interesting.

I would recommend that the Akkatecture project begin with an informal structure that starts with members of the @AfterLutz/maintainers team and any other interested users doing the following:

1. Filing issues / creating bug reports about problems that affect them;
2. Organizing those issues into milestones;
3. Defining a set of shared standards for releases - i.e. I'm working on formalizing that for Akka.NET here https://github.com/akkadotnet/akka.net/projects/7 and
4. Specify under what conditions a pull request can be merged by a maintainer.

These agreements among the maintainers are crucial to the health of the project - they define the set of conventions and courtesies (i.e. wait for feedback on a PR for at least 3-4 days before merging it yourself) that help ensure that the project keeps moving without creating disruptions (i.e. SemVer and wire format compatibility.)

I recommend, generally speaking, sticking with Practical Semantic Versioning and there are tools you can use to help enforce it, such as API Approvals. More importantly, treat your wire / persistence format as sacred and avoid ever forcing users to migrate in order to upgrade at all costs. You will all be a lot happier if you do.

Inactive Maintainers

One thing I periodically do on the Akka.NET project is remove maintainers who have been inactive in the project for N years. This is done primarily for security purposes - you don't want to leave doors open to popular projects by people who are no longer involved. I recommend that all projects adopt a similar process - no commits, no participation, no activity for 2+ years? Remove maintainer, admin, owner, or write access. Make it an expectation from the beginning and it will be less of a shock if and when it happens.

To Dos

So the @AfterLutz/maintainers group needs to make some agreements on how they want to manage the project going forward. Of everything I've included in here, what do you think you'll want to include going forward? What are some things I didn't cover that you feel should be raised?

[Aaronontheweb]

Here's a current example of the "Inactive Maintainers" bit coming to bite some NPM users: https://twitter.com/campuscodi/status/1456519373024268313