Maintainers' guidelines and rules

MAINTAINERS.md

+# (EARLYACCESSDRAFT) 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.
+
+## Who are the maintainers?
+
+People with maintainership status can be seen here: https://git.pleroma.social/groups/pleroma/-/group_members?sort=access_level_desc
+
+## 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 responsibility for the project. Even if you didn't do the code, you still approved or merged it. If there were things you approved even though you feel it needs fixing, 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 can't guarantee a stable source of income
+    * 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 (i.e. 3+ years)
+  * You did a lot of harm to the project in one way or another
+  * ..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), community 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**
+  - Discussion should be kept on-topic however, no devolution into discussion which political ideology is better for some country.
+- 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 familiarize yourself with the contents/outcomes of the event that you missed.
+      - This implies that any such event MUST have a record (i.e. written report, audio/video recording of a meeting, public announcement) and it's event organizers' duty to provide those in timely fashion. Any events that lack this cannot be deemed solid but possibly can be still valid.
+      - Of course, "timely fashion" is subjective, and technical issues can still occur, therefore conflicts of "i missed event and didn't get to vote" nature should be solved on case-by-case basis
+- There is no need to consult with project owner (lain) on anything, asking lain's opinion is possible but it should not have higher importance than other maintainers.
+- For decisions we always try to reach consensus. If no consensus can be reached, then we need at least consensus on the decisions making process. Consensus means that people have been a proper chance to object and no one does, keeping [Pleroma's goals](https://git.pleroma.social/pleroma/pleroma-meta/-/merge_requests/3) in mind.
+- 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.
+
+# Merge requests handling guidelines
+## Code changes
+- All code changes should be submitted through merge requests. Exceptions are possible - i.e. maintainers can commit tiny (i.e. 1-2 lines of code) bug fixes directly to `develop` to save time, as long as it's easy to revert, but default still should be through merge requests.
+- All code changes (unless small fixes or extremly important fixes (i.e. fixing crashing and dysfunctional UI)) should be reviewed and preferably tested by at least one other person. 
+  - Bigger changes or controversial changes warrant more testing and review. Those should not be merged hastly!
+  - Review means code review as well as functional review, i.e. confirming there are no issues with new and existing functionality.
+- Changes to behavior should have option for changing back to original behavior when possible and applicable. Breaking existing behavior with no way of restoring it can be a concession, but never a default.
+- "Controversial"-ness and "Big"-ness are subjective and up to bigger community (both developers and users) to decide. Here are some hints/examples
+  - Anything that is difficult to revert from, either in terms of version control or database migration with no way back are always considered "big and controversial"
+    - Major refactoring of part of frontend/backend is always a "big" change that needs extensive (multiple weeks, possibly months) testing and review. The more approval for code review the better.
+    - Minor refactoring of a smaller component is considered "big and controversial" but one reviewer/approval should be enough. Testing should be extensive but shouldn't take months.
+    - Tiny refactoring that permanently changes database with no way back (i.e. removal of extraneous table) is still considered "big" and should have at least one reviewer and should have extensive testing.
+  - Smaller changes like bugfixes usually aren't big unless they also involve refactoring, however if there are questions raised about the fix or there are negative feedback about prospect of the "fix" from users, then it's considered "controversial" and needs more attention.
+    - Common example could be fixing issue of some usecase at expense of other usecase - what one person sees as a bug, other might see as a feature. Common solution is to make it an option, but it's up to discussion.
+    - Another example might be "lack of feature as a bug" reasoning. **New features should always be discussed**, as supporting those features is a responsibility, which might be undesirable.
+    - Lastly, "hotfixes" and "dirty hacks" might or might not be accepted and it's up to maintainers to decide whether it's the case or not. Our codebase isn't always clean and we do have some legacy lying around, and in some places it might be acceptable to introduce a "temporary" fix, while in other there might be enough code dirt already and adding more won't help.
+      - This doesn't mean that "dirty part" is under a "freeze", it means that fixes for it should also involve refactoring to clean it up.
+  - Tiny fixes, i.e. spelling errors, minor stylistic (CSS) changes are most likely not controversial nor big.
+  - Big **additions** that don't affect other code, i.e. someone writing a documentation or entirely new translation can be considered "not big" despite the amount of content, as it most likely be "better than nothing".
+  - Any major **removals** are automatically controversial.
+  - Any change that attracts too much attention might be considered controversial.
+- Changes that affect both backend and frontend must be properly coordinated between projects.
+  - "properly coordinated" means "consensus has been reached", this only really affects intentional backend-and-frontend changes, if something unintentionally changes the other part (i.e. backend changing CSP rules that break FE, FE having a bug that accidentally DDoSes BE) such changes should be re-coordinated, i.e. change reverted and approach looked at by both sides.
+  - *PleromaFE specific: PleromaFE should still work with older backend versions*
+
+## Timeframes
+- All MRs should be taken care of within certain time frames. The timeframe can change depending on situation and subject, i.e. reviewing and testing major refactoring MR might take several weeks, but smaller MRs should be resolved within smaller period of time.
+  - Since we're non-profit and barely have any donations at the moment, it's unreasonable to expect people to be "on call" or even respond in time. The proposed baseline is 2 weeks, but it can be increased or decreased depending on situation, i.e. if some or most maintainers are on "vacation" or "sick leave" this period can be extended to 3 or 4 weeks.
+  - The meaning "taken care of" and timeframes are iterative, i.e. when MR is submitted maintainer can just respond with some questions about functionality or raise concerns about code, then it's considered that "ball is on other side" and time frame only starts again when other side (i.e. contributor submitting the MR) responds to queries, updates their MR etc. There is no hard limit on this process, but we might have some (soft) deadlines on releases which in turn impose harsher time limits on MRs, however this should be discussed and agreed upon between maintainers and involved contributors.
+
+## Acceptance criteria
+- One or more approval where applicable.
+- No objections to merging.
+- Changelog entries present (if applicable, i.e. no need for changelog entry if it's a tiny fix for a previously merged feature that already has changelog entry)
+- *Preferably* should have (unit) tests.
+
+つづく..?