docs: Update CONTRIBUTING.md #53
Conversation
Signed-off-by: David Hirsch <[email protected]>
| These guidelines are not set in stone and are subject to change. | ||
|
|
||
| Each repository has its own set of labels. Here is the current [label set](https://github.com/open-feature/spec/labels) for the spec repository. |
There was a problem hiding this comment.
Should we define a set of labels available in each repo ?
There was a problem hiding this comment.
right now we have different labels for each repo, we could try to align them. I'm not sure what the effort would be @thomaspoignant @toddbaert any thoughts?
There was a problem hiding this comment.
I would like to align. I wonder if we can do this in peribolos... the challenge is it seems like when you create org labels they are only created in subsequent new repos :(
|
|
||
| When submitting a pull request, it's important to make sure that it can be cleanly merged into the upstream repository. In some cases, conflicts may arise when attempting to merge a pull request, such as when changes have been made to the same file or lines of code. | ||
|
|
||
| To resolve conflicts, we always use the `git rebase` command rather than git merge. This helps to ensure a clean and linear history of commits. |
There was a problem hiding this comment.
We actually do this automatically in all repos I know of. Contributors can add as many commits as they want, and rebase OR merge main as then please, but when the final "merge" is done, it's done as a squash rebase on main automatically, giving us one linear commit.
There was a problem hiding this comment.
@toddbaert do you suggest removing this part or rewriting?
There was a problem hiding this comment.
The spirit of the section is really good, which is why we automate it.
While for git-history reasons I definitely like rebasing better, I think for reviews, NOT rebasing is actually nicer in most cases, because it doesn't generate new hashes for old commits (rebasing does). Github keeps track of hashes you've "seen" so it can help in reviews that take days or more.
I suggest you mention that we squash/rebase PRs automatically, making the commit message the PR title (which we also audit). This has the net result of keeping a very clean commit history and also makes PRs and reviews pleasant for everyone.
adding more details on how to contribute, come from the incubation proposal