Policy / Guidelines for PR merges

[mal0ki]

• Create policy / guidelines for what and how we merge PRs to Florence Masto.

We want to have a solid foundation for people to make their decisions on. Clear cut ones will make it easier for people to merge, or accept PRs in review process.
Other, which may require more discussion will become clearer that way.

[BanjoFox]

Thoughts on PR's

• Has clearly defined purpose?
• Only tries to solve one issue? (Limit scope to reduce impact).
• Has been tested in a dev branch?
• Code review has been signed off by subject expert? (UI folks may not be familiar with backend function)

ADDENDUM:
This is the "Standard issue CONTRIBUTING.md" that Aardwolf uses. Might help to flesh out some of the other ideas :)

https://github.com/Aardwolf-Social/aardwolf/blob/master/CONTRIBUTING.md

[1011X]

There seem to be different "categories" that a PR could fall into. These include:

• Security patches
• Feature implementations
• Upstream merges

For automated security PRs, I'd recommend the following:

• High severity: Merge ASAP
• Moderate severity: Take a week to verify if it affects us. If no clear answer, merge anyways.
• Low severity: Take 2 weeks to a month to verify if it affects us. If no clear answer, merge anyways.

For feature implementations, we can use the guidelines that @BanjoFox mentioned (altho idk how we'd test stuff considering we don't currently have an instance to do so).

Upstream merges could be a lot like feature implementations, except we would compile a summary of all features/changes in the PR, and then decide what (if anything) we should merge from it.

[BanjoFox]

You could also add "- Documentation Updates" to that bulleted list :)

And yes. "Has this PR been tested" does require functional code ;)
Since this issue is related to policy questions then it still fits.