Closed Riksu9000 closed 1 year ago
I modified the merging section. I removed the part about the author being specified as the maintainer of the code, as that's not something we do currently, and replaced it with allowing small maintenance PRs by core developers to be merged with a single approval. This should reduce the wait times for maintenance PRs.
Looks good to me. That's a good start, and we'll probably refine it later on :)
Regarding the merging section, and since @Riksu9000 brought to my attention that we can enable protection rules on branches, do we want to add a "linear history" rule to this guide, and enforce it with this check ?
I think we should enable the branch protection rule, but I'm not sure we need to explicitly mention it in the guide. Following the instructions in the guide will maintain a linear history, and the branch protection rule makes it so you couldn't break the rule anyway. I'll be updating the merging section soon.
This document clarifies how the maintainers should manage the project.
We should write about using the milestones as well, but I want to discuss that first. I'll open an issue about that. If that doesn't get resolved in time, it can be another PR. EDIT: Here's the issue #1515
I've added new instructions on handling stale PRs. Three months is quite conservative, as it concerns any activity, and can be reduced. Let me know what you think.