From b83a5abe85b57111d144c42ee0f72883f73ae7bc Mon Sep 17 00:00:00 2001 From: oupala Date: Thu, 29 Nov 2018 14:24:44 +0100 Subject: [PATCH 1/2] chore: add a code of conduct The code of conduct has been generated using the `covgen` package. --- CODE_OF_CONDUCT.md | 77 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 77 insertions(+) create mode 100644 CODE_OF_CONDUCT.md diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md new file mode 100644 index 0000000..1266193 --- /dev/null +++ b/CODE_OF_CONDUCT.md @@ -0,0 +1,77 @@ +# 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 . 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 + From 654b27f7540aad8580048ae998e0dcedc3042f7e Mon Sep 17 00:00:00 2001 From: oupala Date: Fri, 14 Dec 2018 19:04:48 +0100 Subject: [PATCH 2/2] chore: add a contributing guide The contributing guide has been generated using the `generate-contributing` package. --- CONTRIBUTING.md | 161 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 161 insertions(+) create mode 100644 CONTRIBUTING.md diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md new file mode 100644 index 0000000..57db9ca --- /dev/null +++ b/CONTRIBUTING.md @@ -0,0 +1,161 @@ +# Contributing to apaxy + +First and foremost, thank you! We appreciate that you want to contribute +to apaxy, your time is valuable, and your contributions mean a lot to us. + +## Important! + +By contributing to this project, you: + +- Agree that you have authored 100% of the content +- Agree that you have the necessary rights to the content +- Agree that you have received the necessary permissions from your +employer to make the contributions (if applicable) +- Agree that the content you contribute may be provided under the +Project license(s) + +## Getting started + +**What does "contributing" mean?** + +Creating an issue is the simplest form of contributing to a project. Creating a +merge reques is more efficient form of contributing. But there are many ways to +contribute, including the following: + +- Updating or correcting documentation +- Feature requests +- Bug reports + +If you'd like to learn more about contributing in general, the [Guide to +Idiomatic +Contributing](https://github.com/jonschlinkert/idiomatic-contributing) +has a lot of useful information. + +**Showing support for apaxy** + +Please keep in mind that open source software is built by people like +you, who spend their free time creating things the rest the community +can use. + +Don't have time to contribute? No worries, here are some other ways to +show your support for apaxy: + +- star the [project](https://github.com/oupala/apaxy) +- tweet your support for apaxy + +## Issues + +### Before creating an issue + +Please try to determine if the issue is caused by an underlying library, +and if so, create the issue there. Sometimes this is difficult to know. +We only ask that you attempt to give a reasonable attempt to find out. +Oftentimes the readme will have advice about where to go to create issues. + +Try to follow these guidelines + +- **Investigate the issue**: +- **Check the readme** - oftentimes you will find notes about creating +issues, and where to go depending on the type of issue +- Create the issue in the appropriate repository + +### Creating an issue + +Please be as descriptive as possible when creating an issue. Give us the +information we need to successfully answer your question or address your +issue by answering the following in your issue: + +- **version**: please note the version of apaxy are you using +- **extensions, plugins, helpers, etc** (if applicable): please list any +extensions you're using +- **error messages**: please paste any error messages into the issue, or +a [gist](https://gist.github.com/) + +### Closing issues + +The original poster or the maintainer's of apaxy may close an issue at +any time. Typically, but not exclusively, issues are closed when: + +- The issue is resolved +- The project's maintainers have determined the issue is out of scope +- An issue is clearly a duplicate of another issue, in which case the +duplicate issue will be linked +- A discussion has clearly run its course + + +## Pull requests + +### Before creating a merge request + +Please try to determine if the issue is caused by an underlying library, +and if so, create the merge request there. Sometimes this is difficult to know. +We only ask that you attempt to give a reasonable attempt to find out. +Oftentimes the readme will have advice about where to go to create merge +requests. + +Try to follow these guidelines + +- **Investigate the issue**: +- **Check the readme** - oftentimes you will find notes about creating +issues, and where to go depending on the type of issue +- Create the merge request in the appropriate repository + +### Creating a merge request + +Please be as descriptive as possible when creating a merge request. Give us the +information we need to successfully understand what you want to change or to add +to apaxy. Create the merge request as soon as possible so that the discussion +around your changes can start at the beginning of your work, not when it's over +and you don't time anymore to discuss it. + +### Closing merge requests + +The original poster or the maintainer's of apaxy may close a merge request at +any time. Typically, but not exclusively, issues are closed when: + +- The merge request has conflict with the develop branch that makes it difficult +to merge without a hard work +- The commit message of each commit of the merge request does not follow the +[conventional commits](https://www.conventionalcommits.org/) standard +- The project's maintainers have determined the merge request is out of scope +- A merge request is clearly a duplicate of another merge request, in which case +the duplicate merge request will be linked +- A discussion has clearly run its course + + +## Next steps + +**Tips for creating idiomatic issues** + +Spending just a little extra time to review best practices and brush up +on your contributing skills will, at minimum, make your issue easier to +read, easier to resolve, and more likely to be found by others who have +the same or similar issue in the future. At best, it will open up doors +and potential career opportunities by helping you be at your best. + +The following resources were hand-picked to help you be the most +effective contributor you can be: + +- The [Guide to Idiomatic +Contributing](https://github.com/jonschlinkert/idiomatic-contributing) +is a great place for newcomers to start, but there is also information +for experienced contributors there +- Take some time to learn basic markdown. We can't stress this enough. +Don't start pasting code into GitHub issues before you've taken a moment +to review this [markdown +cheatsheet](https://gist.github.com/jonschlinkert/5854601) +- The GitHub guide to [basic +markdown](https://help.github.com/articles/markdown-basics/) is another +great markdown resource +- Learn about [GitHub Flavored +Markdown](https://help.github.com/articles/github-flavored-markdown/). +And if you want to really go above and beyond, read [mastering +markdown](https://guides.github.com/features/mastering-markdown/) + +At the very least, please try to: + +- Use backticks to wrap code. This ensures that it retains its +formatting and isn't modified when it's rendered by GitHub, and makes +the code more readable to others +- When applicable, use syntax highlighting by adding the correct +language name after the first "code fence"