Update readme, contributing, issue and PR templates PR.

CONTRIBUTING.md

@@ -1,70 +1,15 @@
-## Welcome!
+Thanks for your interest in contributing to the 18F Methods! We appreciate all constructive contributions, and we welcome your ideas about how to keep the Methods up-to-date, friendly, and accessible. You can contribute by emailing us, filing an issue, or submitting a pull request.
 
-We’re so glad you’re thinking about contributing to an 18F open source project! If you’re unsure about something, feel free to submit your issue or pull request anyway. The worst that can happen is you’ll be politely asked to change something. We love all friendly contributions and questions.
+- **Emailing us.** Whether you've got a general question about the Methods, or you'd just like to have a conversation outside of GitHub — whatever the reason, feel free to [email us](mailto:[email protected]).
+- **Filing an issue.** See something amiss? Please glance through the [existing issues](https://github.com/18f/methods/issues) to see if someone has already alerted us to your question or concern *before* [filing a new issue](https://github.com/18F/methods/issues/new)! (Please note that we tag and manage issues using [a specific set of labels](https://github.com/18F/methods/wiki/labels).)
+- **Submitting a pull request.** Got a better solution in mind? Please glance through [our existing pull requests](https://github.com/18f/methods/pulls) to see if we're already working on a similar idea *before* submitting a pull request.
 
-We want to ensure a welcoming environment for all of our projects. Our staff follow the [18F Code of Conduct](https://github.com/18F/code-of-conduct/blob/master/code-of-conduct.md) and all contributors should do the same.
+## Code of conduct
+To ensure a welcoming environment for our projects, our staff follows the [18F Code of Conduct](https://github.com/18F/code-of-conduct/blob/master/code-of-conduct.md); contributors should do the same.
 
-We encourage you to read this project’s CONTRIBUTING policy (you are here), its [LICENSE](LICENSE.md), and its [README](README.md).
-
-If you have any questions or want to read more, check out the [18F Open Source Policy GitHub repository]( https://github.com/18f/open-source-policy), or just [shoot us an email](mailto:[email protected]).
-
-## How to contribute
-
-### Where to submit a pull request
-
-Submit pull requests to the `18f-pages-staging` branch. This is the main branch of Methods. If you’re not sure how to submit a pull request, feel free to submit an issue and we will try to address it ourselves.
-
-### What to include in a pull request
-
-Including these will help us be faster and better at responding.
-
-- **Changes:** a list, preferably bulleted, of what you’re changing
-- **Notes:** anything that might help us understand the change, like why you’re doing it or alternative approaches you tried
-- **Screenshots:** if your pull request will affect layout or interaction, to show us what you’re fixing or changing
-
-### Issues and labels
-
-If there’s anything you’d like to understand about Methods, submit an issue about it. If you see something that should be fixed but don’t want to do so yourself, submit an issue. If you have an idea for an improvement... well, you get the idea.
-
-This is the list of labels we currently use for different types of issues. It should give you some idea of the sorts of issues we expect. (You can also apply these labels to pull requests.) But if you want to raise something else, go for it.
-
-- `bug` tells us that Methods is doing something it probably should not. Try to keep this to interactive, layout, or visual design issues for the digital version. Print design issues should go under `print cards`.
-- `copy edit` denotes changes to language, which tells us we need to make the change twice: in the digital version and on the printable method cards. Even if the issue only exists in one place, we want to check it in both.
-- `duplicate` suggests that this issue might be the same as another issue. If you tell us what issue that is, we will look into it and decide whether to combine them.
-- `enhancement` means you’re suggesting a way to make Methods better. This is different from `bug` because it’s not suggesting there’s something wrong with the current state.
-- `help wanted` is a request for assistance, usually by 18F to the world, but if you just can’t figure something out about something you’re trying to do with Methods, feel free to use this label.
-- `invalid` comes after the fact to say the issue is either inaccurate or misplaced.
-- `new method` tells us you are submitting a design research method that we don’t currently describe.
-- `print cards` is for design changes to the printable cards that may require a bit more time from an 18F visual designer to address.
-- `question` raises any kind of question at all you have about Methods.
-- `wontfix` should come from 18F staffers. It acknowledges the issue — usually a bug or enhancement — but says we are not going to do something with it. You should expect an explanation if we apply this label.
-- `work in progress` means we are in the process of addressing this issue.
-
-### What to include in an issue
-
-Not all of these will apply to all issues. But when they do, it’s very helpful to see them (special thanks to @ondrae for [the suggestion of this list](https://github.com/18F/open-source-guide/issues/15#issuecomment-129552978)).
-
-- **Description:** okay, this one does apply to all issues. :)
-- **How to reproduce:** if your issue is a bug, any information about how we can see it ourselves
-- **Screenshots:** similarly, so we can see what you’re seeing
-- **Files:** anything with helpful information about the issue
-- **To dos:** if your issue is an enhancement, a list of improvements or steps to help us meet the goal of the enhancement
-
-
-### Before you submit content edits
-
-Please review the Methods [content editing checklist](https://github.com/18F/methods/wiki/content-editing-checklist). We’re trying to keep the style and structure consistent, so we’ll check contributions against this guide anyway. Might as well check beforehand! If you’d rather just call our attention to something that seems off, go ahead and file an issue and we’ll review the checklist as part of our edits.
-
-## What we do with contributions
-
-We regularly review all pull requests and issues.  We merge pull requests into `18f-pages-staging` as soon as we can.
-
-Once a week, we incorporate any staged copy edits into the files for the printed cards, also on `18f-pages-staging`. We then merge all changes from `18f-pages-staging` into `master` — code and copy, digital and print. You’ll see your change reflected on [methods.18f.gov](https://methods.18f.gov/) after that pull into `master`.
-
-We leave issues and pull requests open until we have decided what to do and then actually done it. Any time we close an issue, you’ll see something that explains why we’re closing it (such as a comment, a merged pull request, or a reference to another issue).
+## Open source
+This project is maintained in accordance with [18F’s Open Source Policy GitHub repository]( https://github.com/18f/open-source-policy).
 
 ## Public domain
-
 This project is in the public domain within the United States, and copyright and related rights in the work worldwide are waived through the [CC0 1.0 Universal public domain dedication](https://creativecommons.org/publicdomain/zero/1.0/).
-
 All contributions to this project will be released under the CC0 dedication. By submitting a pull request, you are agreeing to comply with this waiver of copyright interest.

ISSUE_TEMPLATE.md

@@ -0,0 +1,9 @@
+REMINDERS (Delete this before submitting your issue)
+
+Labels: Please label your issue in accordance with our label descriptions. See our wiki for more information: https://github.com/18F/methods/wiki/labels
+
+Reproduction steps: If your issue is a bug, please apply the `bug` label and provide step-by-step information so that we can reproduce it ourselves.
+
+To dos: If your issue describes an enhancement, please apply the `enhancement` label and provide a list of steps we can take to meet the goal of your proposed enhancement.
+
+Files: If possible, please upload any files (such as wireframes, screenshots, or error logs) that might help us better understand this issue.

PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,7 @@
+REMINDERS (Delete this before submitting your pull request)
+
+Before submitting your pull request, please preview your changes at  https://federalist-proxy.app.cloud.gov/preview/18f/methods/[BRANCHNAME] (where [BRANCHNAME] is the name of your branch) This is the main URL we will reference as we review and comment on your pull request.
+
+Please submit pull requests against the `staging` branch.
+
+Finally, please note that all pull requests must receive at least one review in addition to whomever merges the request. When you believe your code is ready to merge, please tag at least one member of the current Methods team (see README.md).

README.md

@@ -1,45 +1,36 @@
-Method Cards
-===============
+The 18F Method Cards (“18F Methods”) describe how 18F puts human-centered design into practice. While this is primarily maintained as an internal resource, we hope it can help *everyone* adopt the methods of human-centered design.
 
-## Why method cards?
+### Why methods?
 
-- To add rigor and structure to agile development.
-- To build a shared vocabulary for each method among 18F staff and our partner agencies.
-- To give less experienced or new researchers a gateway into well-documented and proven research methods, supported by other 18F team members.
+In order to function well within cross-functional teams, designers need to know a few things: which methods they might choose from, why one particular method makes more sense than another at any given moment, and, once they’ve picked a method, how to actually execute it. 18F Methods collects this essential information as a series of cards. In practice, we’ve found the Methods can provide folks with a gateway into our work and build internal alignment around a shared vocabulary.
 
-## We’ve grouped these methods into four phases
+### Specific to 18F, specific to the federal government
 
-- **Discover**: Learn as much as you can about the project and people involved.
-- **Decide**: Use what you’ve learned to start focusing your research on specific areas and groups of people.
-- **Make**: Move toward a final product that’s ready to be released and tested.
-- **Validate**: Test your research, design, and product.
+It’s important to note that the 18F Methods are designed to account for two things that may not otherwise concern a more generic collection of design methods. First, these methods directly reflect and support 18F’s human-centered work. (They are also continuously updated in a human-centered way — how meta!). Second, 18F Methods are designed to keep federal employees on the happy side of the law. This collection specifically includes helpful information on topics for which designers working in the federal government may need clarification, such as privacy and the Paperwork Reduction Act.
 
-## We’ve called out specifics about doing this work in government.
+## Getting started
 
-For the most part, the processes are the same as anywhere. However, to stay on the happy side of the law, take a look at [Recruiting](pages/recruiting/), [Incentives](pages/incentives/), [Informed consent](pages/informed-consent/), [Privacy](pages/privacy/), and the [Paperwork Reduction Act](pages/paperwork-reduction-act/). No matter which methods we work with, these are the [fundamentals](pages/fundamentals/) of our design research.
+### Reading the Methods online
 
-## Generating the Methods site/hosting locally
+You’re presently looking at the Method’s GitHub (code) repository. Please [visit our homepage](https://methods.18f.gov) to read the Methods online.
 
-### Cloning and running 18F/methods
+### Printing the Methods
 
-You will need [Ruby](https://www.ruby-lang.org) ( > version 2.1.5 ). You may
-consider using a Ruby version manager such as
-[rbenv](https://github.com/sstephenson/rbenv) or [rvm](https://rvm.io/) to
-help ensure that Ruby version upgrades don’t mean all your
-[gems](https://rubygems.org/) will need to be rebuilt.
+To print a copy of the Methods for offline use, simply visit the [Methods homepage](https://methods.18f.gov) and select `file → print…` from your web browser.
 
-On OS X, you can use [Homebrew](http://brew.sh/) to install Ruby in
-`/usr/local/bin`, which may require you to update your `$PATH` environment
-variable:
+### Running the Methods website on your local machine
 
-```shell
+You will need [Ruby](https://www.ruby-lang.org) ( > version 2.1.5 ). You may consider using a Ruby version manager such as [rbenv](https://github.com/sstephenson/rbenv) or [rvm](https://rvm.io/) to help ensure that Ruby version upgrades don’t mean all your [gems](https://rubygems.org/) will need to be rebuilt.
+
+On OS X, you can use [Homebrew](http://brew.sh/) to install Ruby in `/usr/local/bin`, which may require you to update your `$PATH` environment variable:
+
+```
+shell
 $ brew update
 $ brew install ruby
 ```
 
-To serve 18F Design Methods locally, using `METHODS` as the name of your new repository:
-
-Run each of the following steps to get the site up and running.
+To serve 18F Methods locally, using `methods` as the name of your new repository, run each of the following steps:
 
 ```
 git clone [email protected]:18F/methods
@@ -48,36 +39,34 @@ bundle install
 jekyll serve
 ```
 
-You should be able to see the site at: http://localhost:4000/
-
-### Forking into your own repository
+You should be able to see the site at: `http://localhost:4000/`
 
-If you haven’t already followed the cloning instructions above, the easiest way to do this is simply to go to https://github.com/18F/methods and click `Fork`, then set up the repository under your own username. Then follow the instructions above to clone locally, subbing in MY-USER-NAME for 18F’s in the URL that follows `git clone`.
 
-If you _have_ already cloned locally from 18F and want to maintain your own Methods repository, do the following.
+## We follow the 18F style guide
 
-You’ll need to create a new repository on Github. To do this, go to github.com/MY-USER-NAME and click the "New Repository" button. Enter the title and description for your new guide and then click `Create Repository`. It’s easiest if you use `methods` as the name, as it will match back to the 18F Methods you’re building from.
+The site uses a custom set of styles that inherit from the [U.S. Web Design Standards](https://standards.usa.gov/) and [18F brand](https://brand.18f.gov/) guidelines.
 
-After the repository is created, you’ll see the repository URL at the top. Copy this url by hitting the handy `Copy to Clipboard` button next to the text box.
+## Current team
 
-Go back to the directory where you cloned the repository. We’re going to change this repo to point to the one you just created (which is empty), instead of back to 18F’s, and push to it.
-```
-git remote set-url origin https://github.com/MY-USER-NAME/METHODS.git
-git push origin 18f-pages-staging
-```
-
-Now you can edit your own fork of Methods freely, and push up changes as you need.
+- Product owner: Eric Ronne
+- Designer (researcher): Andrew Maier
+- Designer (front-end developer): Scott Weber
 
-## We follow the 18F style guide 
+## Past contributors
 
-The site uses a custom set of styles that inherit from the [U.S. Web Design Standards](https://standards.usa.gov/) and [18F brand](https://brand.18f.gov/) guidelines. 
+- Jeremy Canfield
+- Erica Deahl
+- Carolyn Dew
+- James Hupp
+- Colin MacArthur
+- Brad Nunnally
+- Jennifer Thibault
+- Russ Unger
+- Victor Zapanta
 
 ## Public domain
-
 This project is in the worldwide [public domain](LICENSE.md). As stated in [CONTRIBUTING](CONTRIBUTING.md):
-
 > This project is in the public domain within the United States, and copyright and related rights in the work worldwide are waived through the [CC0 1.0 Universal public domain dedication](https://creativecommons.org/publicdomain/zero/1.0/).
 >
-> All contributions to this project will be released under the CC0
->dedication. By submitting a pull request, you are agreeing to comply
+> All contributions to this project will be released under the CC0 dedication. By submitting a pull request, you are agreeing to comply
 >with this waiver of copyright interest.