Maintainers' guidelines and rules

mentioned in merge request pleroma!3632 (closed)

marked this merge request as draft

From the last meeting I also get that decisions should be done in a consensus based way.

This of course means that we need to define a bit what that means, so here's my definition and view on it.

Definition: Consensus means that no one reasonably objects.

In practice this means that things should be discussed in the proper fora and that people should be given ample time to raise objections.

Proper fora depends on what the decision is about, but for Pleroma in general I would say

Changes to the code happen in Merge Requests on the corresponding repository
If people want feedback on things without/before making changes themselves, that can be done on the corresponding issue tracker (for things that don't have a specific issue tracker, there's the meta issue tracker)
You could always get a feel of how people see things by asking in the chat or discussing on fedi or w/e, but this also excludes people, so you can't assume there wont be objections later on

For ample time it depends on some factors, mostly

How controversial can the decision be
How easy can the decision be reverted

Some examples

Every one wants clear documentation, if someone does a spelling or formatting fix, then that's probably not controversial and it can always be easily reverted if needed. This can be fixed/merged quickly.
A feature with many changes means that people need to have/make more time to properly review, let things sink in, and respond if they see something wrong. Because of this AND because a bigger change set means more chance for controversial bits, this needs to be given more time.
A feature that everyone wants, but can't be reverted (e.g. a non-invertible migration is needed), shouldn't be merged too quickly

I assume some of the maintainers already have an opinion based on experience how long something should remain open, so that can be used as a guideline. Personally I think for a project where many people are volunteering, two weeks could be a good baseline. Less than two weeks is not enough to allow people to provide feedback.

Also note that not every comment is necessarily an objection. Sometimes it can just be general feedback, or a question, or a way they see to get something even better than it already is. But if someone makes it clear that something is an objection, it should be taken seriously.

Question: Is this only about the maintainer role, or can other roles also be included? If only maintainer role, do we create a separate document for the other roles, or where is that defined?

Owner
- Is this the same as maintainer, or are extra things expected?
Developer
- ATM that role is more a recognition that someone did work for Pleroma and a way to hopefully motivate people to contribute more. But some of the responsibilities that maintainers have (fixing bugs, adding/discussing features...) could also be seen as responsibilities for people with developer role