-
Notifications
You must be signed in to change notification settings - Fork 107
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
docs: Add contributing guidelines for go-tuf #190
Conversation
Signed-off-by: Asra Ali <asraa@google.com>
Pull Request Test Coverage Report for Build 1560595099
💛 - Coveralls |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for putting this together! I left some comments inline
## Pull Request review policy | ||
|
||
* Anyone is welcome to review any PR, whether they are a maintainer or not! | ||
* Maintainers should aim to turn around reviews within one business day. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One day might be a bit optimistic. While this will usually be the case maintainers might take a week off, etc and I don't want to set expectations too high.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How does a 5 business days sound? Also, it's unlikely all the maintainers are off, and I think we can make exceptions for regional holidays.
* See [MAINTAINERS](MAINTAINERS) for the current list of maintainers. | ||
* It is expected that two maintainers from differing organizations approve the PR before a merge. This may be waived for PRs which only update docs or comments, or trivial changes to tests. | ||
|
||
Maintainers should: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we can also have something here about ensuring compliance with the TUF spec and overall code quality
|
||
To make a pull request, you will need a GitHub account. See GitHub's documentation [forking](https://help.github.com/articles/fork-a-repo) and [pull requests](https://help.github.com/articles/using-pull-requests). | ||
|
||
Pull requests should be targeted at the `master` branch. Before creating a pull request, go through this checklist: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This section is a great addition, especially for new contributers
It would be also nice if we can add a Contributing chapter to the README file too where we refer to this guideline 👍 |
When all of the tests are passing, maintainer(s) will be assigned to review and merge the PR. | ||
|
||
|
||
## Communication |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe it would be nice to mention the community meeting schedule as well 👍
|
||
## Pull Request Procedure | ||
|
||
To make a pull request, you will need a GitHub account. See GitHub's documentation [forking](https://help.github.com/articles/fork-a-repo) and [pull requests](https://help.github.com/articles/using-pull-requests). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: "Github's documentation ON forking..."
|
||
## Contributing Code | ||
|
||
Unless you are fixing a known bug, we strongly recommend discussing it with the community via a GitHub issue or Slack before getting started to ensure that your work is consistent with TUF's specification. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe: ...or Slack (see [Communication](#Communication))
|
||
When creating a PR, | ||
|
||
1. Accept the Developer's Certificate of Origin on all commits (see above). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we require this, probably worth adding the DCO bot
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I hate that DCO bot. Can we instead use an app that checks whether a contributor has signed a DCO CLA agreement? Something like what the Linux Foundation uses.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🤣 🤣 I'm not attached to any particular bot, just saying that if it's "required" that should be enforced :)
Though I can't find what you're talking about -- I checked a few LF repos and the ones I found all use the same bot (ex.).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, I meant a CLA bot, which many orgs have their own apps for, here's the LF one: https://github.com/apps/lf-cla-application
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TLDR: no to DCO, yes to CLA
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why the preference for CLA?
As I understand it (I am not a lawyer) both are assertions that the submitter has the right to submit a change and grants the right to the receiver to use the submitted change. A CLA is a legal contract while the DCO is a more lightweight statement of the contributor asserting ownership. As a consequence of a CLA being a legal contract, they can be a barrier to contributors (requiring, i.e., a corporate legal representative to sign-off).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Simply because DCO is extremely annoying (must remember to --sign-off
, otherwise rebase and force-push hell; does not work with commits done from the website), whereas CLA is a one-time deal.
In regards to #234, we should add content in the guideline for these topics too: 1. Convention for writing commit messages
2. How to tag releases and prereleases
3. How to tag breaking changes
@asraa - Let me know in case you are not available to spend some time on that, so we can merge this one with what we have so far and I'll address these in another PR 👍 UPDATE [03/21/22]: Updated the keyword for marking changes as breaking so it's in line with what the spec says - ref. https://www.conventionalcommits.org/en/v1.0.0/#specification |
Since #234 got merged, maybe we should proceed with finalising this one too, so the contributing guidelines are consistent with what the CI expects to verify 👍 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@znewman01 - Let's merge this as it's already a great start for having such a guideline 👍
We'll address some of the comments in follow-up PRs and I'll open a separate issue for discussing whether we want to use CLA or DCO.
I'd prefer to remove the contentious stuff (e.g. DCO vs. CLA) before we merge even a first-pass, so nobody confuses it for official, set-in-stone policy. If we pull that out, I'm happy to approve it. |
Got it 👍 @asraa - Would you like to address this one or if you don't have the time maybe I can fork your branch and do this on top? |
Follow-up from theupdateframework#190 (thanks @asraa!). I did not add a DCO requirement at this point, as that was controversial in theupdateframework#190. I filed theupdateframework#308 to track that. I tried to address all *other* feedback in theupdateframework#190. Fixes theupdateframework#212. Fixes theupdateframework#306.
* add contrbuting guidelines Signed-off-by: Asra Ali <asraa@google.com> * Update CONTRIBUTING.md, add MAINTAINERS.md Follow-up from #190 (thanks @asraa!). I did not add a DCO requirement at this point, as that was controversial in #190. I filed #308 to track that. I tried to address all *other* feedback in #190. Fixes #212. Fixes #306. * Move docs into a "docs" folder. Fixes #303. * Whitespace fixes * Address PR comments - TODO for testing instructions - Remove obsolete TODO * Full URL in testing * Fix @joshuagl suggestions Co-authored-by: Asra Ali <asraa@google.com>
Superceded by #309 |
Include PR process, review process, and other communication details.
Signed-off-by: Asra Ali asraa@google.com