docs: add CONTRIBUTING.md #2
Conversation
|
should information regarding contributor licensing be included here? |
|
this can be removed before merging, i just added it to demonstrate that the current contents are meant to be generic enough to be included in all of our repos and that repo specific information can be added at the end |
CONTRIBUTING.md
Outdated
| Welcome to the Strangelove contributor guidelines. We are excited to have you here and look forward to your contributions! | ||
| Contributors are expected to adhere to the guidelines outlined in this document as well as our [code of conduct](./CODE_OF_CONDUCT.md). | ||
|
|
||
| [Should Contributor Licensing information be included here?] |
There was a problem hiding this comment.
I'd put it at the end of this doc, not at the beginning.
There was a problem hiding this comment.
sounds good to me! i'd like to hear @chipcope's opinion on what the verbiage around this should be
There was a problem hiding this comment.
I added @chipcope proposed phrasing to the end of the document under a new section titled Contributor License Agreement
There was a problem hiding this comment.
@jtieri - So, I still don't know how to submit a PR...I know, disappointing... So, if it works for you, I'll just drop some language below for inclusion?
Before opening a PR, please review LICENSE.md and familiarize yourself with it's terms. Please be advised that by opening a PR, you are granting Strangelove (or the owner of the relevant repository) a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable license, in copyright and in patent, with respect to your Contribution and any portion thereof.
|
@beckettsean I have updated the document with a section on contributor license agreement and this should be ready for review again |
CONTRIBUTING.md
Outdated
| ### Bug Reports | ||
|
|
||
| First thing to note is that if you believe you have discovered a security vulnerability *DO NOT* use the issue tracker. | ||
| Please report it via email to [email protected]. For more information on reporting security vulnerabilities, |
There was a problem hiding this comment.
We have a couple ways for folks to report. I do like having the more official automated way for people who are security aware, and this dead simple obvious way for others.
Just calling it out that we might have two channels to monitor, but I'm okay with that.
There was a problem hiding this comment.
good call out, this was before we recently decided to make use of the security vulnerability reporting via GitHub. I could add a sentence here pointing to our SECURITY.md file which would direct folks to the built in reporting functionality on GitHub but also leave our email in place as a secondary option?
or i could just remove our email and only link to our SECURITY.md file
There was a problem hiding this comment.
I ended up adding our email as a secondary option to SECURITY.md and pointed users to this document inside of CONTRIBUTING.md
This PR is a first pass at establishing a set of norms and conventions as part of the contributor guidelines that will be included in our open source repos. My goal was to write a basic set of contributor guidelines that are generalized enough to be included in all of our repos, with room to add repo specific information where needed.
I opened this as a PR instead of pushing to
mainso that we could have a conversation around the contents of the document.When building this document I referred to a few sources: