Skip to content
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

Closed
wants to merge 1 commit into from

Conversation

asraa
Copy link
Contributor

@asraa asraa commented Dec 9, 2021

Include PR process, review process, and other communication details.

Signed-off-by: Asra Ali [email protected]

@coveralls
Copy link

coveralls commented Dec 9, 2021

Pull Request Test Coverage Report for Build 1560595099

  • 0 of 0 changed or added relevant lines in 0 files are covered.
  • No unchanged relevant lines lost coverage.
  • Overall coverage remained the same at 69.337%

Totals Coverage Status
Change from base Build 1559969196: 0.0%
Covered Lines: 2051
Relevant Lines: 2958

💛 - Coveralls

Copy link
Collaborator

@mnm678 mnm678 left a 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.
Copy link
Collaborator

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.

Copy link
Member

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:
Copy link
Collaborator

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:
Copy link
Collaborator

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

@rdimitrov
Copy link
Contributor

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
Copy link
Contributor

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).
Copy link
Contributor

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.
Copy link
Contributor

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).
Copy link
Contributor

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

Copy link
Member

@trishankatdatadog trishankatdatadog Jan 26, 2022

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.

Copy link
Contributor

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.).

Copy link
Member

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

Copy link
Member

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

Copy link
Member

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).

Copy link
Member

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.

@rdimitrov
Copy link
Contributor

rdimitrov commented Mar 17, 2022

In regards to #234, we should add content in the guideline for these topics too:

1. Convention for writing commit messages

  • Upon release, the changelog is built automatically and it will group commits based on a given regex and title.
  • This is especially important when we are introducing breaking changes because such will be highlighted in e separate group on top of the changelog for any new release.
  • The available groups will be - Breaking changes, Features, Bug fixes, and Others
  • To mark that a commit should be part of a given group, its commit message should have some of the following keywords - BREAKING CHANGE, feat, or fix. Everything else is added to the Others group.
  • The responsibility for doing that is first to the author who created these commits and second to the maintainers reviewing and thus merging them. For example, if it introduces a breaking change and the commit messages do not inform of that, the maintainer should alter the message of the merge commit upon merging it so it includes the expected keyword.

2. How to tag releases and prereleases

  • Use Semver-like versioning, i.e v1.2.3 and v1.2.3-rc1?

3. How to tag breaking changes

  • Increment the MAJOR version or something else?

@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

@rdimitrov
Copy link
Contributor

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 👍

Copy link
Contributor

@rdimitrov rdimitrov left a 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.

@znewman01
Copy link
Contributor

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.

@rdimitrov
Copy link
Contributor

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?

@znewman01 znewman01 mentioned this pull request Jun 8, 2022
znewman01 added a commit to znewman01/go-tuf that referenced this pull request Jun 8, 2022
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.
asraa added a commit that referenced this pull request Jun 9, 2022
* add contrbuting guidelines

Signed-off-by: Asra Ali <[email protected]>

* 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 <[email protected]>
@znewman01
Copy link
Contributor

Superceded by #309

@znewman01 znewman01 closed this Jun 9, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Contributing guidelines link redirects to an unrelated page
7 participants