From 1d9a64551ff565580eeb203dbafffb9b614ee257 Mon Sep 17 00:00:00 2001 From: Kirstie Whitaker Date: Sun, 28 Apr 2019 18:12:23 +0100 Subject: [PATCH 01/16] Add html comments to bug report --- .github/ISSUE_TEMPLATE/bug_report.md | 29 +++++++++++++++++++--------- 1 file changed, 20 insertions(+), 9 deletions(-) diff --git a/.github/ISSUE_TEMPLATE/bug_report.md b/.github/ISSUE_TEMPLATE/bug_report.md index 2bac7b96..0dd20516 100644 --- a/.github/ISSUE_TEMPLATE/bug_report.md +++ b/.github/ISSUE_TEMPLATE/bug_report.md @@ -6,21 +6,32 @@ labels: '' assignees: '' --- + -**Describe the bug** -A clear and concise description of what the bug is. +### Bug description + + +#### Expected behaviour + + +#### Actual behaviour + + +### How to reproduce + -**To Reproduce** -Steps to reproduce the behaviour: 1. Go to '...' 2. Click on '....' 3. Scroll down to '....' 4. See error -**Expected behaviour** -A clear and concise description of what you expected to happen. +### Your personal set up + -**Versions (please complete the following information):** - OS: [e.g. linux, OSX] - - Docker version: `docker version` - - repo2docker version `repo2docker --version` + - Docker version: `docker version` + - repo2docker version `repo2docker --version` + From 6ff13e91623e1903d09397226f59b071e125a6b7 Mon Sep 17 00:00:00 2001 From: Kirstie Whitaker Date: Sun, 28 Apr 2019 18:25:25 +0100 Subject: [PATCH 02/16] Add comments and additional structure to feature request --- .github/ISSUE_TEMPLATE/feature_request.md | 27 +++++++++++++++++------ 1 file changed, 20 insertions(+), 7 deletions(-) diff --git a/.github/ISSUE_TEMPLATE/feature_request.md b/.github/ISSUE_TEMPLATE/feature_request.md index cb41a717..e2554408 100644 --- a/.github/ISSUE_TEMPLATE/feature_request.md +++ b/.github/ISSUE_TEMPLATE/feature_request.md @@ -6,15 +6,28 @@ labels: 'needs: discussion' assignees: '' --- + -Those who maintain this project do so as volunteers and we have no control over their schedule or priorities. +### Proposed change + -This means if the feature you are proposing is something you'd like to see added the best way to achieve that is for you to organise the effort required to build it. This could be evangelising for the feature, paying someone, doing it yourself, etc. -Even so it might never get merged because the trade off between additional happy users and maintenance burden is not favourable. +### Alternative options + -**Describe the solution you'd like** -A clear and concise description of what you want to happen. -**Describe alternatives you've considered** -A clear and concise description of any alternative solutions or features you've considered. +### Who would use this feature? + + + +### How much time will adding it take? + + + +### Who can do this work? + + + +### Thank you maintainers! + + From 1e0eb726cebf06ae16ce1a57c65349696a2ae675 Mon Sep 17 00:00:00 2001 From: Kirstie Whitaker Date: Sun, 28 Apr 2019 18:25:57 +0100 Subject: [PATCH 03/16] Make html comments all on one long line --- .github/ISSUE_TEMPLATE/bug_report.md | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/.github/ISSUE_TEMPLATE/bug_report.md b/.github/ISSUE_TEMPLATE/bug_report.md index 0dd20516..2171bd67 100644 --- a/.github/ISSUE_TEMPLATE/bug_report.md +++ b/.github/ISSUE_TEMPLATE/bug_report.md @@ -6,8 +6,7 @@ labels: '' assignees: '' --- - + ### Bug description @@ -27,9 +26,7 @@ issue, but you can delete them once you've read them if you prefer! --> 4. See error ### Your personal set up - + - OS: [e.g. linux, OSX] - Docker version: `docker version` From a27420e29fa548fe7832569fd663d9e0e3c69948 Mon Sep 17 00:00:00 2001 From: Kirstie Whitaker Date: Sun, 28 Apr 2019 19:11:32 +0100 Subject: [PATCH 04/16] Add types of contributions section --- docs/source/contributing/contributing.md | 30 ++++++++++++++++++++++++ 1 file changed, 30 insertions(+) diff --git a/docs/source/contributing/contributing.md b/docs/source/contributing/contributing.md index b6616075..f6b84bf3 100644 --- a/docs/source/contributing/contributing.md +++ b/docs/source/contributing/contributing.md @@ -1,5 +1,35 @@ # Contributing to repo2docker development +Thank you for thinking about contributing to repo2docker! +This is an open source project that is developed and maintained entirely by volunteers. +*Your contribution* is integral to the future of the project. +THANK YOU! + +## Types of contribution + +There are many ways to contribute to repo2docker: + +* **Update the documentation.** + If you're reading a page or docstring and it doesn't make sense (or doesn't exist!), please let us know by opening a bug report. + It's even more amazing if you can give us a suggested change. +* **Fix bugs or add requested features.** + Have a look through the [issue tracker](https://github.com/jupyter/repo2docker/issues) and see if there are any tagged as ["help wanted"](https://github.com/jupyter/repo2docker/issues?q=is%3Aissue+is%3Aopen+label%3A%22help+wanted%22). + As the label suggests, we'd love your help! +* **Report a bug.** + If repo2docker isn't doing what you thought it would do then open a [bug report](https://github.com/jupyter/repo2docker/issues/new?template=bug_report.md). + That issue template will ask you a few questions described in more detail below. +* **Suggest a new feature.** + We know that there are lots of ways to extend repo2docker! + If you're interested in adding a feature then please open a [feature request](https://github.com/jupyter/repo2docker/issues/new?template=feature_request.md). + That issue template will ask you a few questions described in detail below. +* **Tell people about repo2docker.** + As we said above, repo2docker is built by and for its community. + If you know anyone who would like to use repo2docker, please tell them about the project! + You could give a talk about it, or run a demonstration. + The sky is the limit :rocket::star2:. + +If you're not sure where to get started, then please come and say hello in our [Gitter channel](https://gitter.im/jupyterhub/binder), or open an discussion thread at the [Jupyter discourse forum](https://discourse.jupyter.org/). + ## Process for making a contribution This outlines the process for getting changes to the repo2docker project merged. From 5a7add79291829a5166da0bb08631720f0aa3dfe Mon Sep 17 00:00:00 2001 From: Kirstie Whitaker Date: Sun, 28 Apr 2019 19:41:33 +0100 Subject: [PATCH 05/16] Update process and guidelines for making contribution --- docs/source/contributing/contributing.md | 67 +++++++++++++----------- 1 file changed, 37 insertions(+), 30 deletions(-) diff --git a/docs/source/contributing/contributing.md b/docs/source/contributing/contributing.md index f6b84bf3..71677c79 100644 --- a/docs/source/contributing/contributing.md +++ b/docs/source/contributing/contributing.md @@ -34,41 +34,48 @@ If you're not sure where to get started, then please come and say hello in our [ This outlines the process for getting changes to the repo2docker project merged. -* If your change is a big change, **open an issue to discuss** - before spending a lot of time writing. Getting consensus with the - community is a great way to save time later. -* Make edits in your fork of the repo2docker repository -* All changes are made by submitting a pull request. Read the next section for - the guidelines for both reviewers and contributors on merging a PR. -* Edit [the changelog](./../../changelog) - by appending your feature / bug fix to the development version. -* Wait for a community member to merge your changes. -* (optional) Deploy a new version of repo2docker to mybinder.org by [following these steps](http://mybinder-sre.readthedocs.io/en/latest/deployment/how.html) +1. Identify the correct issue template: [bug report](https://github.com/jupyter/repo2docker/issues/new?template=bug_report.md) or [feature request](https://github.com/jupyter/repo2docker/issues/new?template=feature_request.md). + **Bug reports** ([examples](https://github.com/jupyter/repo2docker/issues?q=is%3Aissue+is%3Aopen+label%3Abug), [new issue](https://github.com/jupyter/repo2docker/issues/new?template=bug_report.md)) will ask you for a description of the problem, the expected behaviour, the actual behaviour, how to reproduce the problem, and your personal set up. + Bugs can include problems with the documentation, or code not running as expected. + + **Feature requests** ([examples](https://github.com/jupyter/repo2docker/labels/needs%3A%20discussion), [new issue](https://github.com/jupyter/repo2docker/issues/new?template=feature_request.md)) will ask you for the proposed change, any alternatives that you have considered, a description of who would use this feature, and a best-guess of how much work it will take and what skills are required to accomplish. + + Very easy feature requests might be updates to the documentation to clarify steps for new users. + Harder feature requests may be to add new functionality to the project and will need more in depth discussion about who can complete and maintain the work. + +2. Open an issue. + Getting consensus with the community is a great way to save time later. +3. Make edits in [your fork](https://help.github.com/en/articles/fork-a-repo) of the [repo2docker repository](https://github.com/jupyter/repo2docker). +4. Make a [pull request](https://help.github.com/en/articles/about-pull-requests). +Read the [next section](#guidelines-to-getting-a-pull-request-merged) for guidelines for both reviewers and contributors on merging a PR. +5. Edit [the changelog](./../../changelog) by appending your feature / bug fix to the development version. +6. Wait for a community member to merge your changes. +7. (optional) Deploy a new version of repo2docker to mybinder.org by [following these steps](http://mybinder-sre.readthedocs.io/en/latest/deployment/how.html) ## Guidelines to getting a Pull Request merged -These are not hard rules to be enforced by 🚓 but instead guidelines -to help you make a contribution. +These are not hard rules to be enforced by 🚓 but they are suggestions written by the repo2docker maintainers to make getting your contribution completed a smooth process for you and for them. + +* **Create a PR as early as possible**, marking it with `[WIP]` while you work on it. + This avoids duplicated work, lets you get high level feedback on functionality or API changes, and/or helps find collaborators to work with you. +* **Keep your PR focused.** + The best PRs solve one problem. + If you end up changing multiple things, please open separate PRs for the different conceptual changes. +* **Add tests your code.** + PRs will not be merged if Travis is failing. +* **Apply [PEP8](https://www.python.org/dev/peps/pep-0008/)** as much as possible, but not too much. + If in doubt, ask. +* **Use merge commits** instead of merge-by-squashing/-rebasing. + This makes it easier to find all changes since the last deployment `git log --merges --pretty=format:"%h %<(10,trunc)%an %<(15)%ar %s" ..` and your PR easier to review. +* **Make it clear when your PR is ready for review.** + Prefix the title of your pull request (PR) with `[MRG]` if the contribution is complete and should be subjected to a detailed review. +* **Enter your changes into the [changelog](./../../changelog)** in `docs/source/changelog.rst`. +* **Use commit messages to describe _why_ you are proposing the changes you are proposing.** +* **Try to not rush changes** (the definition of rush depends on how big your changes are). + Remember that everyone in the repo2docker team is a volunteer and we can not (nor would we want to) control their time or interests. + Wait patiently for a reviewer to merge the PR. -* prefix the title of your pull request with `[MRG]` if the contribution - is complete and should be subjected to a detailed review; -* create a PR as early as possible, marking it with `[WIP]` while you work on - it (good to avoid duplicated work, get broad review of functionality or API, - or seek collaborators); -* a PR solves one problem (do not mix problems together in one PR) with the - minimal set of changes; -* describe why you are proposing the changes you are proposing; -* try to not rush changes (the definition of rush depends on how big your - changes are); -* Enter your changes into the [changelog](./../../changelog) in `docs/source/changelog.rst`; -* someone else has to merge your PR; -* new code needs to come with a test; -* apply [PEP8](https://www.python.org/dev/peps/pep-0008/) as much - as possible, but not too much; -* no merging if travis is red; -* do use merge commits instead of merge-by-squashing/-rebasing. This makes it - easier to find all changes since the last deployment `git log --merges --pretty=format:"%h %<(10,trunc)%an %<(15)%ar %s" ..` ## Setting up for Local Development From 6c43fb927ac594577b883c47bca0c617e8528eb0 Mon Sep 17 00:00:00 2001 From: Kirstie Whitaker Date: Sun, 28 Apr 2019 19:58:55 +0100 Subject: [PATCH 06/16] Extend the points about feature requests & bug reports --- docs/source/contributing/contributing.md | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/docs/source/contributing/contributing.md b/docs/source/contributing/contributing.md index 71677c79..a8066534 100644 --- a/docs/source/contributing/contributing.md +++ b/docs/source/contributing/contributing.md @@ -39,11 +39,17 @@ This outlines the process for getting changes to the repo2docker project merged. **Bug reports** ([examples](https://github.com/jupyter/repo2docker/issues?q=is%3Aissue+is%3Aopen+label%3Abug), [new issue](https://github.com/jupyter/repo2docker/issues/new?template=bug_report.md)) will ask you for a description of the problem, the expected behaviour, the actual behaviour, how to reproduce the problem, and your personal set up. Bugs can include problems with the documentation, or code not running as expected. + It is really important that you make it easy for the maintainers to reproduce the problem you're having. + This guide on creating a [minimal, complete and verifiable example](https://stackoverflow.com/help/mcve) is a great place to start. + **Feature requests** ([examples](https://github.com/jupyter/repo2docker/labels/needs%3A%20discussion), [new issue](https://github.com/jupyter/repo2docker/issues/new?template=feature_request.md)) will ask you for the proposed change, any alternatives that you have considered, a description of who would use this feature, and a best-guess of how much work it will take and what skills are required to accomplish. Very easy feature requests might be updates to the documentation to clarify steps for new users. Harder feature requests may be to add new functionality to the project and will need more in depth discussion about who can complete and maintain the work. + Feature requests are a great opportunity for you to advocate for the use case you're suggesting. + They help others understand how much effort it would be to integrate the work,and - if you're successful at convincing them that this effort is worth it - make it more likely that they to choose to work on it with you. + 2. Open an issue. Getting consensus with the community is a great way to save time later. 3. Make edits in [your fork](https://help.github.com/en/articles/fork-a-repo) of the [repo2docker repository](https://github.com/jupyter/repo2docker). @@ -76,8 +82,6 @@ These are not hard rules to be enforced by 🚓 but they are suggestions written Remember that everyone in the repo2docker team is a volunteer and we can not (nor would we want to) control their time or interests. Wait patiently for a reviewer to merge the PR. - - ## Setting up for Local Development To develop & test repo2docker locally, you need: From 13922ee24929b154db71b9135db833afa1442a2e Mon Sep 17 00:00:00 2001 From: Kirstie Whitaker Date: Sun, 28 Apr 2019 20:09:34 +0100 Subject: [PATCH 07/16] Embelish the links in contributing.md --- CONTRIBUTING.md | 23 +++++++++++++++++++++-- 1 file changed, 21 insertions(+), 2 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 762e84b2..499e7da9 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,7 +1,26 @@ # Contributing to repo2docker development -The repo2docker developer documentation can be found on these pages: +:sparkles: Thank you for thinking about contributing to repo2docker! :sparkles: + +(And thank you particularly for coming to read the guidelines! :heart_eyes:) + +The repo2docker developer documentation is all rendered on our documentation website: [https://repo2docker.readthedocs.io](https://repo2docker.readthedocs.io). +If you're here, you're probably looking for the [Contributing to repo2docker development](https://repo2docker.readthedocs.io/en/latest/contributing/contributing.html) page. + +Please make sure you've read the following sections before opening an issue/pull request: +* [Process for making a contribution](https://repo2docker.readthedocs.io/en/latest/contributing/contributing.html#process-for-making-a-contribution). + * These steps talk you through choosing the right issue template (bug report or feature request) and making a change. +* [Guidelines to getting a Pull Request merged](https://repo2docker.readthedocs.io/en/latest/contributing/contributing.html#guidelines-to-getting-a-pull-request-merged). + * These are tips and tricks to help make your contribution as smooth as possible for you and for the repo2docker maintenance team. + +There are a few other pages to highlight: -* [Contributing to repo2docker](https://repo2docker.readthedocs.io/en/latest/contributing/contributing.html) * [Our roadmap](https://repo2docker.readthedocs.io/en/latest/contributing/roadmap.html) + * We use the roadmap to develop a shared understanding of the project's vision and direction amongst the community of users, contributors, and maintainers. + This is a great place to get a feel for what the maintainers are thinking about for the short, medium and long term future of the project. +* [Design of repo2docker](https://repo2docker.readthedocs.io/en/latest/design.html) + * This page explains some of the design principles behind repo2docker. + Its a really good place to understand _why_ the team have made the decisions that they have along the way! + * We absolutely encourage discussion around refactoring, updating or extending repo2docker, but please make sure that you've understood this page before opening an issue to discuss the change you'd like to propose. * [Common developer tasks and how-tos](https://repo2docker.readthedocs.io/en/latest/contributing/tasks.html) + * Some notes on running tests, buildpack dependencies, creating a release, updating the changelog and keeping the pip files up to date. \ No newline at end of file From 6cd3d1d895a77e2acf28861d27d41e2b1ccc011b Mon Sep 17 00:00:00 2001 From: Kirstie Whitaker Date: Mon, 29 Apr 2019 15:09:42 +0100 Subject: [PATCH 08/16] Update .github/ISSUE_TEMPLATE/feature_request.md --- .github/ISSUE_TEMPLATE/feature_request.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/ISSUE_TEMPLATE/feature_request.md b/.github/ISSUE_TEMPLATE/feature_request.md index e2554408..cfe1ab5d 100644 --- a/.github/ISSUE_TEMPLATE/feature_request.md +++ b/.github/ISSUE_TEMPLATE/feature_request.md @@ -20,7 +20,7 @@ assignees: '' -### How much time will adding it take? +### How much effort will adding it take? From f3e004dd19e3c6ddc74c0e4e89c3b1ccef556817 Mon Sep 17 00:00:00 2001 From: Chris Holdgraf Date: Mon, 29 Apr 2019 16:39:49 +0100 Subject: [PATCH 09/16] Update CONTRIBUTING.md Co-Authored-By: KirstieJane --- CONTRIBUTING.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 499e7da9..d750b20f 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -20,7 +20,7 @@ There are a few other pages to highlight: This is a great place to get a feel for what the maintainers are thinking about for the short, medium and long term future of the project. * [Design of repo2docker](https://repo2docker.readthedocs.io/en/latest/design.html) * This page explains some of the design principles behind repo2docker. - Its a really good place to understand _why_ the team have made the decisions that they have along the way! + Its a good place to understand _why_ the team have made the decisions that they have along the way! * We absolutely encourage discussion around refactoring, updating or extending repo2docker, but please make sure that you've understood this page before opening an issue to discuss the change you'd like to propose. * [Common developer tasks and how-tos](https://repo2docker.readthedocs.io/en/latest/contributing/tasks.html) - * Some notes on running tests, buildpack dependencies, creating a release, updating the changelog and keeping the pip files up to date. \ No newline at end of file + * Some notes on running tests, buildpack dependencies, creating a release, updating the changelog and keeping the pip files up to date. From c9a161746de4df5600801de42adc60abc583bafe Mon Sep 17 00:00:00 2001 From: Chris Holdgraf Date: Mon, 29 Apr 2019 16:40:02 +0100 Subject: [PATCH 10/16] Update CONTRIBUTING.md Co-Authored-By: KirstieJane --- CONTRIBUTING.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index d750b20f..1a02fa1a 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -17,7 +17,7 @@ There are a few other pages to highlight: * [Our roadmap](https://repo2docker.readthedocs.io/en/latest/contributing/roadmap.html) * We use the roadmap to develop a shared understanding of the project's vision and direction amongst the community of users, contributors, and maintainers. - This is a great place to get a feel for what the maintainers are thinking about for the short, medium and long term future of the project. + This is a great place to get a feel for what the maintainers are thinking about for the short, medium, and long term future of the project. * [Design of repo2docker](https://repo2docker.readthedocs.io/en/latest/design.html) * This page explains some of the design principles behind repo2docker. Its a good place to understand _why_ the team have made the decisions that they have along the way! From f9afea1f29322f29050aa0433f4d20b5cc1adee2 Mon Sep 17 00:00:00 2001 From: Kirstie Whitaker Date: Mon, 29 Apr 2019 17:58:22 +0100 Subject: [PATCH 11/16] Reword comment and remove thank you prompt --- .github/ISSUE_TEMPLATE/feature_request.md | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/.github/ISSUE_TEMPLATE/feature_request.md b/.github/ISSUE_TEMPLATE/feature_request.md index cfe1ab5d..25182fc4 100644 --- a/.github/ISSUE_TEMPLATE/feature_request.md +++ b/.github/ISSUE_TEMPLATE/feature_request.md @@ -17,17 +17,13 @@ assignees: '' ### Who would use this feature? - + ### How much effort will adding it take? - + ### Who can do this work? - -### Thank you maintainers! - - From c25e6bc2ae506d2e4dec5fb4babecb37d1a239f2 Mon Sep 17 00:00:00 2001 From: Chris Holdgraf Date: Tue, 30 Apr 2019 09:13:32 +0100 Subject: [PATCH 12/16] Update docs/source/contributing/contributing.md Co-Authored-By: KirstieJane --- docs/source/contributing/contributing.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/docs/source/contributing/contributing.md b/docs/source/contributing/contributing.md index a8066534..83603428 100644 --- a/docs/source/contributing/contributing.md +++ b/docs/source/contributing/contributing.md @@ -22,6 +22,12 @@ There are many ways to contribute to repo2docker: We know that there are lots of ways to extend repo2docker! If you're interested in adding a feature then please open a [feature request](https://github.com/jupyter/repo2docker/issues/new?template=feature_request.md). That issue template will ask you a few questions described in detail below. +* **Review someone's Pull Request.** + Whenever somebody proposes changes to the repo2docker codebase, the community reviews + the changes, and provides feedback, edits, and suggestions. Check out the + [open pull requests](https://github.com/jupyter/repo2docker/pulls?q=is%3Apr+is%3Aopen+sort%3Aupdated-desc) + and provide feedback that helps improve the PR and get it merged. Please keep your + feedback positive and constructive! * **Tell people about repo2docker.** As we said above, repo2docker is built by and for its community. If you know anyone who would like to use repo2docker, please tell them about the project! From 288c3fe811ae9b13bc645d1ba3e65f6f069f844f Mon Sep 17 00:00:00 2001 From: Kirstie Whitaker Date: Tue, 30 Apr 2019 09:18:01 +0100 Subject: [PATCH 13/16] Update .github/ISSUE_TEMPLATE/feature_request.md --- .github/ISSUE_TEMPLATE/feature_request.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/ISSUE_TEMPLATE/feature_request.md b/.github/ISSUE_TEMPLATE/feature_request.md index 25182fc4..833ba6e5 100644 --- a/.github/ISSUE_TEMPLATE/feature_request.md +++ b/.github/ISSUE_TEMPLATE/feature_request.md @@ -25,5 +25,5 @@ assignees: '' ### Who can do this work? - + From 34cff4d5d3f57000164c93d667cd5cdcb6d50377 Mon Sep 17 00:00:00 2001 From: Tim Head Date: Tue, 30 Apr 2019 09:20:47 +0100 Subject: [PATCH 14/16] Update docs/source/contributing/contributing.md Co-Authored-By: KirstieJane --- docs/source/contributing/contributing.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/source/contributing/contributing.md b/docs/source/contributing/contributing.md index 83603428..0b50ea81 100644 --- a/docs/source/contributing/contributing.md +++ b/docs/source/contributing/contributing.md @@ -74,7 +74,7 @@ These are not hard rules to be enforced by 🚓 but they are suggestions written * **Keep your PR focused.** The best PRs solve one problem. If you end up changing multiple things, please open separate PRs for the different conceptual changes. -* **Add tests your code.** +* **Add tests to your code.** PRs will not be merged if Travis is failing. * **Apply [PEP8](https://www.python.org/dev/peps/pep-0008/)** as much as possible, but not too much. If in doubt, ask. From 6344f39d255c81352027a5d59c25edd32f59ca4c Mon Sep 17 00:00:00 2001 From: Kirstie Whitaker Date: Tue, 30 Apr 2019 09:23:34 +0100 Subject: [PATCH 15/16] Update contributing.md --- docs/source/contributing/contributing.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/docs/source/contributing/contributing.md b/docs/source/contributing/contributing.md index 0b50ea81..a317e053 100644 --- a/docs/source/contributing/contributing.md +++ b/docs/source/contributing/contributing.md @@ -63,6 +63,8 @@ This outlines the process for getting changes to the repo2docker project merged. Read the [next section](#guidelines-to-getting-a-pull-request-merged) for guidelines for both reviewers and contributors on merging a PR. 5. Edit [the changelog](./../../changelog) by appending your feature / bug fix to the development version. 6. Wait for a community member to merge your changes. + Remember that **someone else must merge your pull request**. + That goes for new contributors and long term maintainers alike. 7. (optional) Deploy a new version of repo2docker to mybinder.org by [following these steps](http://mybinder-sre.readthedocs.io/en/latest/deployment/how.html) ## Guidelines to getting a Pull Request merged @@ -87,6 +89,7 @@ These are not hard rules to be enforced by 🚓 but they are suggestions written * **Try to not rush changes** (the definition of rush depends on how big your changes are). Remember that everyone in the repo2docker team is a volunteer and we can not (nor would we want to) control their time or interests. Wait patiently for a reviewer to merge the PR. + (Remember that **someone else** must merge your PR, even if you have the admin rights to do so.) ## Setting up for Local Development From a6911a10a0eeafa2e9d133361b26ff81d9f47bc8 Mon Sep 17 00:00:00 2001 From: Kirstie Whitaker Date: Tue, 30 Apr 2019 20:11:17 +0100 Subject: [PATCH 16/16] Update docs/source/contributing/contributing.md --- docs/source/contributing/contributing.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/source/contributing/contributing.md b/docs/source/contributing/contributing.md index a317e053..995f8fda 100644 --- a/docs/source/contributing/contributing.md +++ b/docs/source/contributing/contributing.md @@ -69,7 +69,7 @@ Read the [next section](#guidelines-to-getting-a-pull-request-merged) for guidel ## Guidelines to getting a Pull Request merged -These are not hard rules to be enforced by 🚓 but they are suggestions written by the repo2docker maintainers to make getting your contribution completed a smooth process for you and for them. +These are not hard rules to be enforced by 🚓 but they are suggestions written by the repo2docker maintainers to help complete your contribution as smoothly as possible for both you and for them. * **Create a PR as early as possible**, marking it with `[WIP]` while you work on it. This avoids duplicated work, lets you get high level feedback on functionality or API changes, and/or helps find collaborators to work with you.