search

spokecommunity / Spoke

mass-contact text/SMS distribution tool
MIT License
3 stars 1 forks source link

Set up contributor/maintainer access rules #2

Open harpojaeger opened 5 years ago

harpojaeger commented 5 years ago

I propose a version of the Moya contributor practices, with a couple changes/clarifications:

  1. We'll require two approving reviews before merging, not one. We could change this in the future if it seems like the reviews are mostly redundant.
  2. Add some language around maintainers creating new feature development branches on the primary repo (I think this is fine, but I want to make sure we clean up those branches when they're merged, and that we clearly communicate about what we're working on so people don't accidentally step on each other's work). This is a powerful capability, especially if people are working on a feature together, so let's keep the codebase organized to take advantage of it.

Anything else come to mind on this?

bchrobot commented 5 years ago

To clarify 2 -- you're saying we should encourage maintainers to push PR branches to spokecommunity/Spoke rather than to their own forks for Spoke? I think that is a good idea. Regarding clear communication of what is being worked on, I think we want to strongly encourage use of and lively discourse on GitHub issues for both bug fixes and new features. The easier it is to search through GitHub issues to find something the better (rather than wading through Git blame history and commit messages).

I think a Core Team is important to have as a backstop.

harpojaeger commented 5 years ago

Re: 2: I don't think we need to encourage people to do their development work on branches, but I think we can make it clear that it's an option. I more meant that we should encourage people to name branches intelligibly and make sure there's a record in an issues somewhere of what's being worked on in which branches.