Skip to content

Creates CONTRIBUTOR and MAINTAINERS files #353

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.

Sign up for GitHub

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

Merged
merged 8 commits into from
Jun 20, 2018
Merged

Creates CONTRIBUTOR and MAINTAINERS files #353

Changes from 1 commit
Commits
Show all changes
8 commits
Select commit Hold shift + click to select a range
3cd3d9e
* moving CHANGELOG to markdown to get benefits of the format that it …
tarcinil Mar 8, 2018
8f21f44
fixing dco anchor
tarcinil Mar 8, 2018
246c8ee
using markdown formats
tarcinil Mar 8, 2018
6dcf2fc
adding pull request requirements and license information
tarcinil Mar 8, 2018
02d9a59
adding github templates for issues/pull requests
tarcinil Mar 8, 2018
ea2a405
Merge branch 'master' into feature/349
tarcinil Apr 5, 2018
5e9d79e
fixing comments to PR
tarcinil Apr 5, 2018
561f751
Merge branch 'master' into feature/349
perlun Jun 15, 2018
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
adding pull request requirements and license information 
Signed-off-by: Vern Burton <me@vernburton.com>
  • Loading branch information
@tarcinil
tarcinil committed Mar 8, 2018
commit 6dcf2fc7a58c6d2af67d9c33f720397317ee75e3
23 changes: 10 additions & 13 deletions CONTRIBUTING.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -10,7 +10,7 @@ Use your best judgment, and feel free to propose changes to this document in a p
[How Can I Contribute?](#how-can-i-contribute)
* [Submitting Issues](#submitting-issues)
* [Contribution Process](#contribution-process)
* [Code Review Process](#code-review-process)
* [Pull Request Requirements](#pull-request-requirements)
* [Code Review Process](#code-review-process)
* [Developer Certification of Origin (DCO)](#developer-certification-of-origin-dco)

Expand All @@ -32,6 +32,13 @@ We have a 3 step process for contributions:
2. Create a Github Pull Request for your change, following the instructions in the pull request template.
3. Perform a [Code Review](#code-review-process) with the project maintainers on the pull request.

### Pull Request Requirements
In order to ensure high quality, we require that all pull requests to this project meet these specifications:

1. Unit Testing: We require all the new code to include unit tests, and any fixes to pass previous units.
2. Green CI Tests: We are using [Travis CI](https://travis-ci.org/ruby-git/ruby-git) to run unit tests on various ruby versions, we expect them to all pass before a pull request will be merged.
3. Up-to-date Documentation: New methods as well as updated methods should have [YARD](https://yardoc.org/) documentation added to them

### Code Review Process

Code review takes place in Github pull requests. See [this article](https://help.github.com/articles/about-pull-requests/) if you're not familiar with Github Pull Requests.
Expand All @@ -47,9 +54,9 @@ The process at this point is as follows:

Licensing is very important to open source projects. It helps ensure the software continues to be available under the terms that the author desired.

ruby-git uses [the MIT license](https://github.com/ruby-git/ruby-git/blob/master/LICENSE) to strike a balance between open contribution and allowing you to use the software however you would like to.
ruby-git uses [the MIT license](https://github.com/ruby-git/ruby-git/blob/master/LICENSE)

The license tells you what rights you have that are provided by the copyright holder. It is important that the contributor fully understands what rights they are licensing and agrees to them. Sometimes the copyright holder isn't the contributor, such as when the contributor is doing work on behalf of a company.
Detail about the LICENSE can be found [here](https://choosealicense.com/licenses/mit/)

To make a good faith effort to ensure these criteria are met, ruby-git requires the Developer Certificate of Origin (DCO) process to be followed.

Expand Down Expand Up @@ -85,13 +92,3 @@ By making a contribution to this project, I certify that:
consistent with this project or the open source license(s)
involved.
```
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@rvodden I'm not so sure we need the DCO. It feels a bit far-fetched to me. What do you think?

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 with you, in that it is a bit far fetched, but on the other hand all the OS projects i work on them have them... its only a check box, and I don't think its much to ask; On the other hand if we miss it out and have no legal protection at all we risk (admittedly and extremely low risk) losing all our work. I'm minded to leave it in...

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree about the legal implications, they are valid. If it was only a check box, I would be fine with it, but as we have it written now:

In the commit message of the contribution, the developer simply adds a Signed-off-by statement and thereby agrees to the DCO, which you can find below or at http://developercertificate.org/.

...it means more work every time someone makes a single commit and submits it to the project. (OTOH, you can automate it by using git commit -s or --sign-off, but still...)

I think, if we rephrase this to be just a mere checkbox in the PR, I am fine with it.

Copy link
Contributor Author

@tarcinil tarcinil Apr 8, 2018 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@perlun I would be hesitate to change the standard for DCO without understand the legal implications that change could introduce. The DCO depends on the git Sign-Off-By because of the integrity that is built into Git, removing that could nullify the protections that are given to the maintainers of the project.

The IDE that I use has the ability to sign-off a commit built-in, but I do not believe that the addition of a -s in a command line string is asking too much either. GitHub has tools that can check for DCO on a commit.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The IDE that I use has the ability to sign-off a commit built-in, but I do not believe that the addition of a -s in a command line string is asking too much either. GitHub has tools that can check for DCO on a commit.

Alright, I'm willing to give it a try. We can drop this requirement later if it turns out to be too burdensome.


#### DCO Sign-Off Methods

The DCO requires a sign-off message in the following format appear on each commit in the pull request:

```
Signed-off-by: Vern Burton <me@vernburton.com>
```

The DCO text can either be manually added to your commit body, or you can add either **-s** or **--signoff** to your usual git commit commands. If you forget to add the sign-off you can also amend a previous commit with the sign-off by running **git commit --amend -s**. If you've pushed your changes to Github already you'll need to force push your branch after this with **git push -f**.