[MRG] Update contributing guidelines and issue templates (#655)

[MRG] Update contributing guidelines and issue templates

Author: betatim

.github/ISSUE_TEMPLATE/bug_report.md

@@ -6,21 +6,29 @@ labels: ''
 assignees: ''
 
 ---
+<!-- Thank you for contributing. These HTML commments will not render in the issue, but you can delete them once you've read them if you prefer! -->
 
-**Describe the bug**
-A clear and concise description of what the bug is.
+### Bug description
+<!-- Use this section to clearly and concisely describe the bug. -->
+
+#### Expected behaviour
+<!-- Tell us what you thought would happen. -->
+
+#### Actual behaviour
+<!-- Tell us what you actually happens. -->
+
+### How to reproduce
+<!-- Use this section to describe the steps that a user would take to experience this bug. -->
 
-**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
+<!-- Tell us a little about the system you're using. You can see the guidelines for setting up and reporting this information at https://repo2docker.readthedocs.io/en/latest/contributing/contributing.html#setting-up-for-local-development. -->
 
-**Versions (please complete the following information):**
  - OS: [e.g. linux, OSX]
- - Docker version: `docker version`
- - repo2docker version `repo2docker --version`
+ - Docker version: `docker version` <!-- Run this command to get your version. -->
+ - repo2docker version `repo2docker --version` <!-- Run this command to get your version. -->
+

.github/ISSUE_TEMPLATE/feature_request.md

@@ -6,15 +6,24 @@ labels: 'needs: discussion'
 assignees: ''
 
 ---
+<!-- Thank you for contributing. These HTML commments will not render in the issue, but you can delete them once you've read them if you prefer! -->
 
-Those who maintain this project do so as volunteers and we have no control over their schedule or priorities.
+### Proposed change
+<!-- Use this section to describe the feature you'd like to be added. -->
 
-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
+<!-- Use this section to describe alternative options and why you've decided on the proposed feature above. -->
 
-**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?
+<!-- Describe the audience for this feature. This information will affect who chooses to work on the feature with you. -->
+
+
+### How much effort will adding it take?
+<!-- Try to estimate how much work adding this feature will require. This information will affect who chooses to work on the feature with you. -->
+
+
+### Who can do this work?
+<!-- What skills are needed? Who can be recruited to add this feature? This information will affect who chooses to work on the feature with you. -->
+

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

docs/source/contributing/contributing.md

@@ -1,45 +1,95 @@
 # 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.
+* **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!
+  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.
 
-* 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.
 
-## Guidelines to getting a Pull Request merged
+    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.
 
-These are not hard rules to be enforced by 🚓 but instead guidelines
-to help you make a contribution.
-
-* 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" <deployed-revision>..`
+    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).
+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.
+  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
 
+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.
+* **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 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.
+* **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" <deployed-revision>..` 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.
+  (Remember that **someone else** must merge your PR, even if you have the admin rights to do so.)
 
 ## Setting up for Local Development