Open javier-godoy opened 3 years ago
Good. I have some ideas:
Naming convention for branches: For the sake of easiness, I'm tempted to propose to use the same naming conventions as a commit message.
What about PRs that piggyback other unrelated changes? (If the changes are related, we can adopt the convention that the most dominant commit names the PR, for instance if you are committing a rebase and a feature).
Also, note that the question is about the branch name (not the PR title, although we also need to agree on it).
For instance, if the commit is build: set version to 1.0.0-SNAPSHOT
should the branch be build/1.0.0-SNAPSHOT
? (with the commit header reused as PR title)
How to choose a reviewer for a pull request: Just take one from the pool?
We can define the pool as code owners
When is the POM version updated, if needed: this is an interesting point. One think that pops into my mind is that pom modifications should be the only modifications that could me made directly to the base branch. Of course this also, I think, should be a decision for the specific project.
Agree. When merging features and breaking changes, the reviewer should check that the version in master is aligned with the kind of changes that the PR contains (you can merge features into a x.y.0-SNAPSHOT only , and you can merge breaking changes into a x.0.0-SNAPSHOT only)
Define a procedure for managing Pull Requests: