From 0c885425ea8b52ba41fd94aae3f1a37bc7cc8a60 Mon Sep 17 00:00:00 2001 From: Jared Kerim Date: Thu, 14 Feb 2019 11:38:17 -0500 Subject: [PATCH 1/4] Add contributing.md fixes #927 --- README.md | 8 +-- contributing.md | 146 ++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 147 insertions(+), 7 deletions(-) create mode 100644 contributing.md diff --git a/README.md b/README.md index f1679add68..52646ba571 100644 --- a/README.md +++ b/README.md @@ -251,13 +251,7 @@ Example: PATCH /api/v1/experiments/my-first-experiment/accept ## Contributing -1. Fork the repo! -1. File a new issue describing the change you want to make: Change the things #123 -1. Create your feature branch with the issue number: `git checkout -b 123` -1. Commit your changes: `git commit -am 'Changed the things fixes #123'` -1. Push to the branch: `git push origin 123` -1. Submit a pull request :D - +Please see our [Contributing Guidelines](https://github.com/mozilla/experimenter/blob/master/contributing.md) ## License diff --git a/contributing.md b/contributing.md new file mode 100644 index 0000000000..2e90dd627d --- /dev/null +++ b/contributing.md @@ -0,0 +1,146 @@ +# Contributing + +When contributing to this repository, please first discuss the change you wish to make via issue, +email, or any other method with the owners of this repository before making a change. + +Please note we have a code of conduct, please follow it in all your interactions with the project. + +## Filing an issue + +1. Look for a similar issue that may already describe the proposed changes. + +1. If none exists, create a new issue and describe the proposed changes. + +1. Apply any relevant labels to the issue and set the milestone to Backlog. + +## Pull Request Process + +1. Find the issue that describes the changes you are going to make. If no issue exists +for the changes you want to make, see above and file an issue describing the changes, then +continue to the next step. + +1. Assign the issue to yourself, and change the milestone from Backlog to the currently active +milestone. + +1. Create a branch in your local fork with the issue number in the name. + +1. Implement the code changes described by the issue. All Python code changes should +be accompanied by any relevant tests, either by modifying existing ones or adding new +ones. Front-end changes (HTML/CSS/JS), and infrastructure changes (Docker related things) +do not require tests. + +1. When all your changes are complete to your satisfaction, run `make check` to run the +full test, linting, formatting, and coverage suites. Fix any linting issues or breaking tests, +and make sure coverage remains at 100% by adding new tests for any uncovered lines. + +1. When all tests and checks are passing, commit all your changes into a single commit and name +the commit with a brief description of the change and 'fixes #123' where #123 is the issue number. +You can add any additional descriptive information to the message body of the commit, but the issue +number must be present in the first line of the commit. Example: `Add new dashboard link fixes #123` + +1. Push your branch up to your fork and submit a pull request on to master. Add any additional +information you'd like to the pull request body, including descriptions of changes, screenshots +of any UI changes, special instructions for testing, etc. + +1. Find a reviewer. If you're not sure who should review, please contact us on #experimenter on +[IRC](https://wiki.mozilla.org/IRC). + +1. If you receive feedback that requires changes to your pr, make the changes locally, and then +ammend them to the commit you submitted rather than adding additional commits. A PR will only be +merged if the entirety of the change is contained in a single commit that references the issue +number. + +1. Thank you for submitting changes to Experimenter :D + +### Tagging Process + +1. After a milestone is complete and all changes have been merged into master, we can create +a new tag for deployment. + +1. Update your local master with the remote master: `git pull origin master` + +1. Make sure all checks are passing: `make check` + +1. Create a new tag with the milestone version: `git tag vX.YY.0` + +1. Push the tag: `git push origin --tags` + +1. This will automatically start building a container to deploy and push it to the staging instance +for testing. + +## Code of Conduct + +### Our Pledge + +In the interest of fostering an open and welcoming environment, we as +contributors and maintainers pledge to making participation in our project and +our community a harassment-free experience for everyone, regardless of age, body +size, disability, ethnicity, gender identity and expression, level of experience, +nationality, personal appearance, race, religion, or sexual identity and +orientation. + +### Our Standards + +Examples of behavior that contributes to creating a positive environment +include: + +* Using welcoming and inclusive language +* Being respectful of differing viewpoints and experiences +* Gracefully accepting constructive criticism +* Focusing on what is best for the community +* Showing empathy towards other community members + +Examples of unacceptable behavior by participants include: + +* The use of sexualized language or imagery and unwelcome sexual attention or +advances +* Trolling, insulting/derogatory comments, and personal or political attacks +* Public or private harassment +* Publishing others' private information, such as a physical or electronic + address, without explicit permission +* Other conduct which could reasonably be considered inappropriate in a + professional setting + +### Our Responsibilities + +Project maintainers are responsible for clarifying the standards of acceptable +behavior and are expected to take appropriate and fair corrective action in +response to any instances of unacceptable behavior. + +Project maintainers have the right and responsibility to remove, edit, or +reject comments, commits, code, wiki edits, issues, and other contributions +that are not aligned to this Code of Conduct, or to ban temporarily or +permanently any contributor for other behaviors that they deem inappropriate, +threatening, offensive, or harmful. + +### Scope + +This Code of Conduct applies both within project spaces and in public spaces +when an individual is representing the project or its community. Examples of +representing a project or community include using an official project e-mail +address, posting via an official social media account, or acting as an appointed +representative at an online or offline event. Representation of a project may be +further defined and clarified by project maintainers. + +### Enforcement + +Instances of abusive, harassing, or otherwise unacceptable behavior may be +reported by contacting the project team at [INSERT EMAIL ADDRESS]. All +complaints will be reviewed and investigated and will result in a response that +is deemed necessary and appropriate to the circumstances. The project team is +obligated to maintain confidentiality with regard to the reporter of an incident. +Further details of specific enforcement policies may be posted separately. + +Project maintainers who do not follow or enforce the Code of Conduct in good +faith may face temporary or permanent repercussions as determined by other +members of the project's leadership. + +### Attribution + +This contributing.md is adapted from https://gist.github.com/PurpleBooth/b24679402957c63ec426 + +This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, +available at [http://contributor-covenant.org/version/1/4][version] + +[homepage]: http://contributor-covenant.org +[version]: http://contributor-covenant.org/version/1/4/ From a54e89307ae29e064f864c1f404eb1b40ff721fc Mon Sep 17 00:00:00 2001 From: Jared Kerim Date: Tue, 26 Feb 2019 16:52:06 -0500 Subject: [PATCH 2/4] Address all the feedback --- contributing.md | 138 +++++++++--------------------------------------- 1 file changed, 26 insertions(+), 112 deletions(-) diff --git a/contributing.md b/contributing.md index 2e90dd627d..f7f5711c6e 100644 --- a/contributing.md +++ b/contributing.md @@ -1,23 +1,24 @@ # Contributing When contributing to this repository, please first discuss the change you wish to make via issue, -email, or any other method with the owners of this repository before making a change. +email, or any other method with the owners of this repository before making a change. -Please note we have a code of conduct, please follow it in all your interactions with the project. +## Code of Conduct + +Please note we have a [https://www.mozilla.org/en-US/about/governance/policies/participation/](Code of Conduct), please follow it in all your interactions with the project. ## Filing an issue -1. Look for a similar issue that may already describe the proposed changes. +1. Look for a similar issue that may already exist. -1. If none exists, create a new issue and describe the proposed changes. +1. If none exists, create a new issue and provide as much description and context as possible. 1. Apply any relevant labels to the issue and set the milestone to Backlog. ## Pull Request Process -1. Find the issue that describes the changes you are going to make. If no issue exists -for the changes you want to make, see above and file an issue describing the changes, then -continue to the next step. +1. Find the issue you want to work on. If no relevant issue exists, see above and file an +issue, then continue to the next step. 1. Assign the issue to yourself, and change the milestone from Backlog to the currently active milestone. @@ -25,122 +26,35 @@ milestone. 1. Create a branch in your local fork with the issue number in the name. 1. Implement the code changes described by the issue. All Python code changes should -be accompanied by any relevant tests, either by modifying existing ones or adding new +be accompanied by any relevant tests, either by modifying existing ones or adding new ones. Front-end changes (HTML/CSS/JS), and infrastructure changes (Docker related things) do not require tests. -1. When all your changes are complete to your satisfaction, run `make check` to run the -full test, linting, formatting, and coverage suites. Fix any linting issues or breaking tests, -and make sure coverage remains at 100% by adding new tests for any uncovered lines. +1. When all your changes are complete to your satisfaction: + - Run `make check` to run the full test, linting, formatting, and coverage suites. + - Fix any linting issues by running `make code_format` or by hand if the auto formatter is unable to fix it. + - Fix any broken tests + - Ensure coverage remains at 100% by adding new tests for any uncovered lines. -1. When all tests and checks are passing, commit all your changes into a single commit and name +1. When all tests and checks are passing, commit all your changes into a single commit and name the commit with a brief description of the change and 'fixes #123' where #123 is the issue number. -You can add any additional descriptive information to the message body of the commit, but the issue +You can add any additional descriptive information to the message body of the commit, but the issue number must be present in the first line of the commit. Example: `Add new dashboard link fixes #123` -1. Push your branch up to your fork and submit a pull request on to master. Add any additional +1. Push your branch up to your fork and submit a pull request on to master. Add any additional information you'd like to the pull request body, including descriptions of changes, screenshots -of any UI changes, special instructions for testing, etc. +of any UI changes, special instructions for testing, etc. 1. Find a reviewer. If you're not sure who should review, please contact us on #experimenter on [IRC](https://wiki.mozilla.org/IRC). -1. If you receive feedback that requires changes to your pr, make the changes locally, and then -ammend them to the commit you submitted rather than adding additional commits. A PR will only be -merged if the entirety of the change is contained in a single commit that references the issue -number. - -1. Thank you for submitting changes to Experimenter :D - -### Tagging Process - -1. After a milestone is complete and all changes have been merged into master, we can create -a new tag for deployment. - -1. Update your local master with the remote master: `git pull origin master` - -1. Make sure all checks are passing: `make check` - -1. Create a new tag with the milestone version: `git tag vX.YY.0` - -1. Push the tag: `git push origin --tags` - -1. This will automatically start building a container to deploy and push it to the staging instance -for testing. - -## Code of Conduct - -### Our Pledge - -In the interest of fostering an open and welcoming environment, we as -contributors and maintainers pledge to making participation in our project and -our community a harassment-free experience for everyone, regardless of age, body -size, disability, ethnicity, gender identity and expression, level of experience, -nationality, personal appearance, race, religion, or sexual identity and -orientation. - -### Our Standards +1. If you receive feedback that requires changes to your pull request, make the changes locally, +run `make check` again to ensure all tests and linting are passing, and then create a new commit +that describes what feedback was addressed. This commit can be formatted however you like, it will +be squashed before it is merged into master. -Examples of behavior that contributes to creating a positive environment -include: +1. When your pull request is approved, it can be closed by using the 'Squash and Merge' button to +squash all of the commits into a single one that refers to both the issue and the pull request and +contains any additional descriptive information. -* Using welcoming and inclusive language -* Being respectful of differing viewpoints and experiences -* Gracefully accepting constructive criticism -* Focusing on what is best for the community -* Showing empathy towards other community members - -Examples of unacceptable behavior by participants include: - -* The use of sexualized language or imagery and unwelcome sexual attention or -advances -* Trolling, insulting/derogatory comments, and personal or political attacks -* Public or private harassment -* Publishing others' private information, such as a physical or electronic - address, without explicit permission -* Other conduct which could reasonably be considered inappropriate in a - professional setting - -### Our Responsibilities - -Project maintainers are responsible for clarifying the standards of acceptable -behavior and are expected to take appropriate and fair corrective action in -response to any instances of unacceptable behavior. - -Project maintainers have the right and responsibility to remove, edit, or -reject comments, commits, code, wiki edits, issues, and other contributions -that are not aligned to this Code of Conduct, or to ban temporarily or -permanently any contributor for other behaviors that they deem inappropriate, -threatening, offensive, or harmful. - -### Scope - -This Code of Conduct applies both within project spaces and in public spaces -when an individual is representing the project or its community. Examples of -representing a project or community include using an official project e-mail -address, posting via an official social media account, or acting as an appointed -representative at an online or offline event. Representation of a project may be -further defined and clarified by project maintainers. - -### Enforcement - -Instances of abusive, harassing, or otherwise unacceptable behavior may be -reported by contacting the project team at [INSERT EMAIL ADDRESS]. All -complaints will be reviewed and investigated and will result in a response that -is deemed necessary and appropriate to the circumstances. The project team is -obligated to maintain confidentiality with regard to the reporter of an incident. -Further details of specific enforcement policies may be posted separately. - -Project maintainers who do not follow or enforce the Code of Conduct in good -faith may face temporary or permanent repercussions as determined by other -members of the project's leadership. - -### Attribution - -This contributing.md is adapted from https://gist.github.com/PurpleBooth/b24679402957c63ec426 - -This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, -available at [http://contributor-covenant.org/version/1/4][version] - -[homepage]: http://contributor-covenant.org -[version]: http://contributor-covenant.org/version/1/4/ +1. Thank you for submitting changes to Experimenter :D From 2e6f1d4b6771b9060ec55f7d0f994dcfab7e8b2d Mon Sep 17 00:00:00 2001 From: Jared Kerim Date: Tue, 26 Feb 2019 16:53:42 -0500 Subject: [PATCH 3/4] Add backtick quotes --- contributing.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contributing.md b/contributing.md index f7f5711c6e..f1117df521 100644 --- a/contributing.md +++ b/contributing.md @@ -37,7 +37,7 @@ do not require tests. - Ensure coverage remains at 100% by adding new tests for any uncovered lines. 1. When all tests and checks are passing, commit all your changes into a single commit and name -the commit with a brief description of the change and 'fixes #123' where #123 is the issue number. +the commit with a brief description of the change and `fixes #123` where `#123` is the issue number. You can add any additional descriptive information to the message body of the commit, but the issue number must be present in the first line of the commit. Example: `Add new dashboard link fixes #123` From 946a64d458cd71c7097e3f2d3e4160c870cdb117 Mon Sep 17 00:00:00 2001 From: Peter Bengtsson Date: Tue, 26 Feb 2019 16:58:24 -0500 Subject: [PATCH 4/4] Update contributing.md Capitalize Issue Co-Authored-By: jaredkerim --- contributing.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contributing.md b/contributing.md index f1117df521..84601cf57b 100644 --- a/contributing.md +++ b/contributing.md @@ -7,7 +7,7 @@ email, or any other method with the owners of this repository before making a ch Please note we have a [https://www.mozilla.org/en-US/about/governance/policies/participation/](Code of Conduct), please follow it in all your interactions with the project. -## Filing an issue +## Filing an Issue 1. Look for a similar issue that may already exist.