mirror of
https://github.com/oupala/apaxy.git
synced 2026-01-30 11:09:22 +01:00
Merge pull request #121 from oupala/feature/code-of-conduct
chore: add a code of conduct and a contributing guide
This commit is contained in:
77
CODE_OF_CONDUCT.md
Normal file
77
CODE_OF_CONDUCT.md
Normal file
@@ -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 <contact@apaxy.33mail.com>. 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
|
||||
|
||||
161
CONTRIBUTING.md
Normal file
161
CONTRIBUTING.md
Normal file
@@ -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"
|
||||
Reference in New Issue
Block a user