Maintainers' guidelines and rules

MAINTAINERS.md

+# (ULTRAEARLYACCESSDRAFT) MAINTAINERS: the guidelines and rules for Pleroma maintainers
+## What's this all about
+This document is mostly formalizing unspoken rules and and general "feel" of what Pleroma maintainers are supposed and not supposed to do, based on opinions and existing unwritten processes of pleroma maintainers at the time of writing.
+This should be used in future to have an actual written guideline to refer to when conficts arise or when e.g. bringing new maintainer onboard.
+## What are responsibilitites of a Pleroma maintainer
+* Maintain Pleroma as a project in general:
+  * To the best of your ability, prevent things from falling apart. Try to keep the community together when things start to fall apart. Bring people together to discuss and find consensus.
+  * Participate in discussions about features and future changes.
+    * This includes things outside your scope of your understanding - i.e. frontend developer should still care for what's going on in backend, but it is understandable if you can't make heads or tails of technical things.
+    * This also means start discussions about new features and future changes, either in IRC and/or in pleroma-meta subproject.
+  * Within your scope of understanding, from time to time clean up old MRs and issues, i.e. close stale MRs or MRs that resolve issues that have already been implemented, close issues of things that have been resolved already, separate things into new issues, ping MR authors.
+  * Volunteer to participate in administrative processes e.g. writing this document lmao
+* Maintain your slice of project you have scope of understanding in.
+  * Scope of understanding means - "what you're good at"
+    * PleromaFE dev is expected to take extra care of PleromaFE, less so about other frontend projects i.e. AdminFE, and even less so for PleromaBE.
+    * It's **NOT** forbidden for other devs to participate in inner workings of other subprojects, everyone can approve merge requests, but from technical standpoint people who know specific codebase better have a more important say in things.
+      * E.g. PleromaFE dev can reject an MR in PleromaFE if they think the MR is too messy and they won't have time sorting things out later, even if PleromaBE dev approved it.
+  * Fix bugs in your slice
+    * It is expected for bugs to be fixed by code of people who caused them but only if it happened recently, unless it's happening in part of code someone has massive ownership of (i.e. when chunk of code was written by same person with little to no collaboration from other people, e.g. Pleroma Themes are mostly written by @HJ and it's his duty to fix bugs in there)
+    * Do not leave critical bugs (bugs that people are extremely vocal about and what other maintainers are also considering to be critical) unattended for too long, even if it's beyond your understanding (i.e. aforementioned PleromaFE Themes) - try to fix them to your best ability.
+  * Develop new features
+    * This goes beyond just writing new code:
+      * Coordinating with backend for cross-project features
+      * Reviewing code of new features by other contributors in development
+      * Testing new features, providing feedback both on UX and on technicalities
+  * Review MRs, help contributors by guiding them to get their MRs into mergeable state.
+    * Keyword being **guide**, maintainers don't **have** to handhold contributors and do work for the contributor. Although if changes are urgent or contributor is poorly skilled some extra help might be appreciated.
+    * Situations where MRs are intentionally been merged prematurely (i.e. half-baked urgent fix "we'll fix it later") are up to maintainer's (who intentionally merged the MR) responsibility.
+* Hold responsibilty for the project. Even if you didn't do the code, you still approved or merged it, if you protested - fix it afterwards.
+## Entering, leaving and existing in position of maintainer.
+* To become a pleroma maintainer you need to:
+  * First and foremost - be a Pleroma user and care for project and its future.
+  * Be willing to do it for free
+    * We don't have a funding (yet)
+    * Motivation by money can easily corrupt people. You can still take donations and possibly wages, represent certain agenda etc, but you can't quit because money stopped, only go off-duty.
+  * Have multiple meaningful and imporant contributions to one or more "main" projects (i.e. PleromaBE, PleromaFE, AdminFE etc.)
+  * Have all current maintainers agree on you becoming a maintainer
+* You can be removed from position of a maintainer if:
+  * You weren't performing your responsibilites for a very long time
+  * You did a lot of harm to the project in other way or around
+  * ..and if all other current maintainers agree on you stopping being a maintainer
+    * Principle of presumption of innocence is used - it is duty of the accuser to prove your guilt, you however have duty to properly defend yourself with proof as well, you can't just plead innocent all day when others are convinced of your guilt.
+    * Removal from being a maintainer can be temporary, disciplinary action might be taken first instead etc. Unless specifically stated, you can become a maintainer again later.
+ * This might be obvious but, you cannot be removed from maintainers if you're the only one remaining.
+* If you cannot perform your duties due to lack of time or energy, you are considered "off-duty", it's expected that you won't be able to perform all your duties, but you still hold responsibility for the project and it's still expected from you to participate in discussions.
+* If there's only one active maintainer remains per slice (i.e. only one active PleromaFE) developer, but there are off-duty ones available they should be consulted and coordinated with in regards of future of slice.
+  * If there are no one left to maintain slice (i.e. state of AdminFE at beginning of 2022), coummunity must plan course of action (move functionality to another project, create a replacement, transfer ownership, etc.)
+    * In situation where only one maintainer remains they essentially have absolute power and also absolute repsonsibility.
+
+## Decisions
+Here be a list of main principles for collective decision making:
+- **EVERYTHING IS UP TO DISCUSSION. NO FORBIDDEN TOPICS**
+  - real-life politics should still be avoided tho
+- All discussions must happen in public channels, i.e. IRC or GitLab issues/MRs/etc
+  - If you had a discussion in private, i.e. irl in a bar at a fedi meetup - decision made by this private group cannot be used as an excuse for actions. That means no more "I talked to lain in-person and we decided that...". If you had a discussion and had a decision - it must be approved publicly by the rest of the team.
+    - This goes without a saying but public and community events that are organized for purpose of making decisions are exception. You can't say it was a private meeting if you were invited or were informed about it but not present. You can still object and try to (re)start a discussion but at least first familliarize yourself with the contents/outcomes of the event that you missed.
+- We don't need owner's (lain's) approval for anything.
+- The most desireable outcome is consensus, however when situation is completely stalled a majority vote can be called. If majority cannot be determined (equal or near-equal split) then owner's opinion might be given a bigger priority as a tiebreaker.
+- Pleroma is for everyone, we utilize our flexibility to try and satisfy most people's needs, we shouldn't accept changes that exclusively benefit certain part of populus at expense of code quality, maintainability, or harms/cripples other part of populus in a direct way.
+  - This however needs someone to represent/advocate for said parts of populus in the development community.
+  - Only exception to the rule - we should keep our flexibility. Arguments like "flexibility hurts normies" are not acceptable.
+
+つづく..?