Add GitHub community files (#73)

* Create LICENSE.md
* Update license reference in README.md
* Create CODE_OF_CONDUCT.md
* Create CONTRIBUTING.md
* Add code of conduct and contributing reference in README.md
* Reorganize README.md
* add github dir and PR template

fixes #52 

Co-authored-by: Jeffrey Paul <[email protected]>

.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,52 @@
+<!--
+### Requirements
+
+Filling out the template is required. Any pull request that does not include enough information to be reviewed in a timely manner may be closed at the maintainers' discretion.  All new code requires documentation and tests to ensure against regressions.
+-->
+
+### Description of the Change
+
+<!--
+We must be able to understand the design of your change from this description. If we can't get a good idea of what the code will be doing from the description here, the pull request may be closed at the maintainers' discretion. Keep in mind that the maintainer reviewing this PR may not be familiar with or have worked with the code here recently, so please walk us through the concepts.  Please include screenshots (if appropriate).
+-->
+
+### Alternate Designs
+
+<!-- Explain what other alternates were considered and why the proposed version was selected. -->
+
+### Benefits
+
+<!-- What benefits will be realized by the code change? -->
+
+### Possible Drawbacks
+
+<!-- What are the possible side-effects or negative impacts of the code change? -->
+
+### Verification Process
+
+<!--
+What process did you follow to verify that your change has the desired effects?
+
+- How did you verify that all new functionality works as expected?
+- How did you verify that all changed functionality works as expected?
+- How did you verify that the change has not introduced any regressions?
+
+Describe the actions you performed (e.g., commands you ran, text you typed, buttons you clicked) and describe the results you observed.
+-->
+
+### Checklist:
+
+<!--- Go over all the following points, and put an `x` in all the boxes that apply. -->
+<!--- If you're unsure about any of these, don't hesitate to ask. We're here to help! -->
+- [ ] I have read the [**CONTRIBUTING**](https://github.com/10up/restricted-site-access/blob/develop/CONTRIBUTING.md) document.
+- [ ] My code follows the code style of this project.
+- [ ] My change requires a change to the documentation.
+- [ ] I have updated the documentation accordingly.
+- [ ] I have added tests to cover my change.
+- [ ] All new and existing tests passed.
+
+<!-- _NOTE: these things are not required to open a PR and can be done afterwards / while the PR is open._ -->
+
+### Applicable Issues
+
+<!-- Enter any applicable Issues here -->

CODE_OF_CONDUCT.md

@@ -0,0 +1,76 @@
+# Contributor Covenant 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, sex characteristics, gender identity and expression,
+level of experience, education, socio-economic status, 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 [email protected]. 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 Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
+available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
+
+[homepage]: https://www.contributor-covenant.org
+
+For answers to common questions about this code of conduct, see
+https://www.contributor-covenant.org/faq

CONTRIBUTING.md

@@ -0,0 +1,38 @@
+# Contributing and Maintaining
+
+First, thank you for taking the time to contribute!
+
+The following is a set of guidelines for contributors as well as information and instructions around our maintenance process. The two are closely tied together in terms of how we all work together and set expectations, so while you may not need to know everything in here to submit an issue or pull request, it's best to keep them in the same document.
+
+## Ways to contribute
+
+Contributing isn't just writing code - it's anything that improves the project. All contributions for Restricted Site Access are managed right here on GitHub. Here are some ways you can help:
+
+### Reporting bugs
+
+If you're running into an issue with the plugin, please take a look through [existing issues](https://github.com/10up/restricted-site-access/issues) and [open a new one](https://github.com/10up/restricted-site-access/issues/new) if needed. If you're able, include steps to reproduce, environment information, and screenshots/screencasts as relevant.
+
+### Suggesting enhancements
+
+New features and enhancements are also managed via [issues](https://github.com/10up/restricted-site-access/issues).
+
+### Pull requests
+
+Pull requests represent a proposed solution to a specified problem. They should always reference an issue that describes the problem and contains discussion about the problem itself. Discussion on pull requests should be limited to the pull request itself, i.e. code review.
+
+For more on how 10up writes and manages code, check out our [10up Engineering Best Practices](https://10up.github.io/Engineering-Best-Practices/).
+
+## Workflow
+
+The `develop` branch is the development branch which means it contains the next version to be released. `stable` contains the current latest release and `master` contains the corresponding stable development version. Always work on the `develop` branch and open up PRs against `develop`.
+
+## Release instructions
+
+1. Version bump: Bump the version number in `restricted_site_access.php`.
+2. Changelog: Add/update the changelog in both `readme.txt` and `CHANGELOG.md`
+3. Readme updates: Make any other readme changes as necessary. `CHANGELOG.md` is geared toward GitHub and `readme.txt` contains WordPress.org-specific content. The two are slightly different.
+4. Merge: Make a non-fast-forward merge from `develop` to `master`.
+5. SVN update: Copy files over to the `trunk` folder of an SVN checkout of the plugin. If the plugin banner, icon, or screenshots have changed, copy those to the top-level `assets` folder. Commit those changes.
+6. SVN tag: Make a folder inside `tags` with the current version number, copy the contents of `trunk` into it, and commit with the message `Tagging X.Y.Z`. There is also an SVN command for tagging; however, note that it runs on the remote and requires care because the entire WordPress.org plugins repo is actually single SVN repo.
+7. Check WordPress.org: Ensure that the changes are live on https://wordpress.org/plugins/restricted-site-access/. This may take a few minutes.
+8. Git tag: Tag the release in Git and push the tag to GitHub. It should now appear under [releases](https://github.com/10up/restricted-site-access/releases) there as well.