Add Github community standard files

CODE_OF_CONDUCT.md

@@ -0,0 +1,52 @@
+# 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, 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 Phusion Passenger:
+
+[FloorD](https://github.com/floord) (she/her), [email protected], English / Dutch / German
+
+[scarhand](https://github.com/scarhand) (he/his), [email protected], English / Dutch
+
+The project team will review and investigate all complaints, and will respond in a way that it deems 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 [http://contributor-covenant.org/version/1/4][version]
+
+[homepage]: http://contributor-covenant.org
+[version]: http://contributor-covenant.org/version/1/4/

CONTRIBUTING.md

@@ -0,0 +1,72 @@
+# Contributors Guide
+
+**Table of contents**
+
+ * [Filing bug reports](#file_bugs)
+ * [Contributing documentation](#contrib_docs)
+ * [Contributing by bug triaging](#contrib_triag)
+ * [Contributing community support](#contrib_support)
+ * [Contributing code](#contrib_code)
+ * [Pull requests](#pull_requests)
+
+Thank you for your interest in Passenger Status Service - a [Phusion Passenger](https://www.phusionpassenger.com/) supported project. Passenger Status Service is open source and welcomes contributions. This guide gives you an overview of the ways with which you can contribute, as well as contribution guidelines.
+
+You can contribute in one of the following areas:
+
+ * Filing bugs.
+ * Bug triage.
+ * Documentation (user documentation, developer documentation, contributor documentation).
+ * Community support.
+ * Code.
+
+Please submit patches in the form of a GitHub pull request.
+
+<a name="file_bugs"></a>
+## Filing bug reports
+
+When filing a bug report, please ensure that you include the following information:
+
+ * What steps will reproduce the problem?
+ * What is the expected output? What do you see instead?
+ * What does your environment looks like (operating system, language, configuration, infrastructure)
+
+ For a more detailed guide, please refer to our [issue template](https://github.com/phusion/passenger_status_service/blob/master/issue_template.md).
+
+<a name="contrib_docs"></a>
+## Contributing documentation
+
+Documentation and tutorials can be found in the README for this project.
+
+<a name="contrib_tiag"></a>
+## Contributing by bug triaging
+
+Users [file bug reports](https://github.com/phusion/passenger_status_service/issues) on a regular basis, but not all bug reports contain sufficient information, persist with new releases, are equally important, etc. By helping with bug triaging you make the lives of the core developers a lot easier.
+
+To start contributing, please submit a comment on any bug report that needs triaging. This comment should contain triaging instructions, e.g. whether a report should be considered duplicate. If you contribute regularly we'll give you moderator access to the bug tracker so that you can apply triaging labels directly.
+
+Here are some of the things that you should look for:
+
+ * Some reports are duplicates of each other, i.e. they report the same issue. You should mark them as duplicate and note the ID of the original report.
+ * Some reported problems are caused by the reporter's machine or the reporter's application. You should explain to them what the problem actually is, that it's not caused by Passenger Status Service, and then close the report.
+ * Some reports need more information. At the very least, we need specific instructions on how to reproduce the problem. You should ask the reporter to provide more information. Some reporters reply slowly or not at all. If some time has passed, you should remind the reporter about the request for more information. But if too much time has passed and the issue cannot be reproduced, you should close the report and mark it as "Stale".
+ * Some bug reports seem to be limited to one reporter, and it does not seem that other people suffer from the same problem. These are reports that need _confirmation_. You can help by trying to reproduce the problem.
+ * Some reports are important, but have been neglected for too long. Although the core developers try to minimize the number of times this happens, sometimes it happens anyway because they're so busy. You should actively ping the core developers and remind them about it. Or better: try to actively find contributors who can help solving the issue.
+
+**Always be polite to bug reporters.** Not all reporters are fluent in English, and not everybody may be tech-savvy. But we ask you for your patience and tolerance. We want to stimulate a positive and enjoyable environment.
+
+<a name="contrib_support"></a>
+## Contributing community support
+
+You can contribute by answering support questions on [Stack Overflow](https://stackoverflow.com/search?tab=newest&q=passenger%20status%20service).
+
+<a name="contrib_code"></a>
+##Contributing code
+
+Passenger Status Service is mostly written in Shell, but makes use of Ruby gems and environment files and includes Ruby build scripts. The source code is filled with inline comments, so look there if you want to understand how things work.
+
+<a name="pull_requests"></a>
+## Pull Requests
+
+Pull requests should normally be submitted against the latest stable branch (e.g. master), because once tested & accepted, we want users to benefit from the work as soon as possible.
+
+For more information, please refer to our [template for Pull Requests](https://github.com/phusion/passenger_status_service/blob/master/pull_request_template.md).

issue_template.md

@@ -0,0 +1,16 @@
+# Issue Template
+
+When filing a bug report, please ensure that you include the following information:
+- What steps will reproduce the problem?
+- What is the expected output? What do you see instead?
+- What does your environment looks like (operating system, language, configuration, infrastructure)
+
+__BONUS POINTS__
+- Include files that provide context to the issue you're experiencing, like screenshots. For logs however, please create a GIST which is a paste of your full logs, and link that. Do NOT paste your full logs in issues, as that will make them very long and hard to read.
+- If your project is public, link to the repo so we can investigate directly.
+
+### Checklist
+Before submitting your issue, please consider the following:
+- Avoid using GitHub issues for questions or help. Submitting issues to this repository are reserved for bugs, feature requests, or changes to the source code.
+- Check if the issue is not already reported. If you're experiencing an issue someone else has already reported, please add a comment to the existing issue so we can properly assess the gravity of the problem.
+- Use labels appropriately (no more than 2 per issue).

pull_request_template.md

@@ -0,0 +1,23 @@
+#Pull Request template
+
+Please consider the following when creating a Pull Request (yay!):
+
+### Reference an issue or milestone
+Describe the big picture of your changes here to communicate to the maintainers why we should accept this pull request. If it fixes a bug or resolves a feature request, be sure to link to that issue.
+
+You can bring up a list of suggested issues and pull requests within the repository by typing #. Type the issue or pull request number or title to filter the list, and then press either tab or enter to complete the highlighted result.
+
+### Write a description of changes made
+Provide a description of the changes proposed. Make sure to answer what types of changes your code introduces:
+- Bugfix (non-breaking change which fixes an issue)
+- New feature (non-breaking change which adds functionality)
+- Breaking change (fix or feature that would cause existing functionality to not work as expected)
+
+__BONUS POINTS__
+- Check if the commit's or even all commits' message styles matches ours.
+- Extend the repo's README / documentation, if applicable.
+
+### Avoid breakage
+- Pull requests should normally be submitted against the latest stable branch (e.g. master).
+- Elaborate how you've tested your code.
+- If this is a relatively large or complex change, kick off the discussion by explaining why you chose the solution you did and what alternatives you considered, etc...