From 8919dc6d310cda7f288af8ff32d3faaf1d873b0c Mon Sep 17 00:00:00 2001 From: Chris Mayo Date: Sat, 15 Aug 2020 17:00:34 +0100 Subject: [PATCH] Include CONTRIBUTING and CODE_OF_CONDUCT in Sphinx documentation Convert to reST to integrate without adding another dependency. --- CODE_OF_CONDUCT.md | 102 ------------------------ CODE_OF_CONDUCT.rst | 109 ++++++++++++++++++++++++++ CONTRIBUTING.md | 142 ---------------------------------- CONTRIBUTING.rst | 149 ++++++++++++++++++++++++++++++++++++ doc/src/code_of_conduct.rst | 1 + doc/src/contributing.rst | 1 + doc/src/index.rst | 2 + 7 files changed, 262 insertions(+), 244 deletions(-) delete mode 100644 CODE_OF_CONDUCT.md create mode 100644 CODE_OF_CONDUCT.rst delete mode 100644 CONTRIBUTING.md create mode 100644 CONTRIBUTING.rst create mode 100644 doc/src/code_of_conduct.rst create mode 100644 doc/src/contributing.rst diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md deleted file mode 100644 index ddd58a0a..00000000 --- a/CODE_OF_CONDUCT.md +++ /dev/null @@ -1,102 +0,0 @@ -# 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 one of the persons listed below. All -complaints will be reviewed and investigated and will result in a response that -is deemed necessary and appropriate to the circumstances. The project maintainers 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. - -Project maintainers are encouraged to follow the spirit of the -[Django Code of Conduct Enforcement Manual][enforcement] when -receiving reports. - - [enforcement]: https://www.djangoproject.com/conduct/enforcement-manual/ - -## Contacts - -The following people have volunteered to be available to respond to -Code of Conduct reports. They have reviewed existing literature and -agree to follow the aforementioned process in good faith. They also -accept OpenPGP-encrypted email: - - * Antoine Beaupré - -## 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/ - -Changes -------- - -The Code of Conduct was modified to refer to *project maintainers* -instead of *project team* and small paragraph was added to refer to -the Django enforcement manual. - -> Note: We have so far determined that writing an explicit enforcement -> policy is not necessary, considering the available literature -> already available online and the relatively small size of the -> community. This may change in the future if the community grows -> larger. diff --git a/CODE_OF_CONDUCT.rst b/CODE_OF_CONDUCT.rst new file mode 100644 index 00000000..37ec54a2 --- /dev/null +++ b/CODE_OF_CONDUCT.rst @@ -0,0 +1,109 @@ +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 one of the persons listed below. All +complaints will be reviewed and investigated and will result in a +response that is deemed necessary and appropriate to the circumstances. +The project maintainers 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. + +Project maintainers are encouraged to follow the spirit of the `Django +Code of Conduct Enforcement +Manual `__ +when receiving reports. + +Contacts +-------- + +The following people have volunteered to be available to respond to Code +of Conduct reports. They have reviewed existing literature and agree to +follow the aforementioned process in good faith. They also accept +OpenPGP-encrypted email: + +- Antoine Beaupré anarcat@debian.org + +Attribution +----------- + +This Code of Conduct is adapted from the `Contributor +Covenant `__, version 1.4, available at +`http://contributor-covenant.org/version/1/4 `__ + +Changes +------- + +The Code of Conduct was modified to refer to *project maintainers* +instead of *project team* and small paragraph was added to refer to the +Django enforcement manual. + + Note: We have so far determined that writing an explicit enforcement + policy is not necessary, considering the available literature already + available online and the relatively small size of the community. This + may change in the future if the community grows larger. diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md deleted file mode 100644 index 1d30795a..00000000 --- a/CONTRIBUTING.md +++ /dev/null @@ -1,142 +0,0 @@ -# Contribution guide - -This document outlines how to contribute to this project. It details -instructions on how to submit issues, bug reports and patches. - -Before you participate in the community, you should also agree to -respect the code of conduct, shipped in [CODE_OF_CONDUCT.md](CODE_OF_CONDUCT.md) in the -source code. - -[project]: https://github.com/linkchecker/linkchecker/ -[issues]: https://github.com/linkchecker/linkchecker/issues -[pull requests]: https://github.com/linkchecker/linkchecker/pulls - -# Positive feedback - -Even if you have no changes, suggestions, documentation or bug reports -to submit, even just positive feedback like "it works" goes a long -way. It shows the project is being used and gives instant -gratification to contributors. So we welcome emails that tell us of -your positive experiences with the project or just thank you -notes. Contact maintainers directly or submit a closed issue with your -story. You can also send your "thanks" through . - -# Issues and bug reports - -We want you to report issues you find in the software. It is a -recognized and important part of contributing to this project. All -issues will be read and replied to politely and -professionally. Issues and bug reports should be filed on the -[issue tracker][issues]. - -## Issue triage - -Issue triage is a useful contribution as well. You can review the -[issues][] in the [project page][project] and, for each issue: - -- try to reproduce the issue, if it is not reproducible, label it with - `help-wanted` and explain the steps taken to reproduce -- if information is missing, label it with `invalid` and request - specific information -- if the feature request is not within the scope of the project or - should be refused for other reasons, use the `wontfix` label and - close the issue -- mark feature requests with the `enhancement` label, bugs with - `bug`, duplicates with `duplicate` and so on... - -Note that some of those operations are available only to project -maintainers, see below for the different statuses. - -## Security issues - -Security issues should first be disclosed privately to the project -maintainers, which support receiving encrypted emails through the -usual OpenPGP key discovery mechanisms. - -This project cannot currently afford bounties for security issues. We -would still ask that you coordinate disclosure, giving the project a -reasonable delay to produce a fix and prepare a release before public -disclosure. - -Public recognition will be given to reporters security issues if -desired. We otherwise agree with the [Disclosure Guidelines][] of the -[HackerOne project][], at the time of writing. - - [Disclosure Guidelines]: https://www.hackerone.com/disclosure-guidelines - [HackerOne project]: https://www.hackerone.com/ - -# Patches - -Patches can be submitted through [pull requests][] on the -[project page][project]. - -Some guidelines for patches: - -* A patch should be a minimal and accurate answer to exactly one - identified and agreed problem. -* A patch must compile cleanly and pass project self-tests on all - target platforms. -* A patch commit message must consist of a single short (less than 50 - characters) line stating a summary of the change, followed by a - blank line and then a description of the problem being solved and - its solution, or a reason for the change. Write more information, - not less, in the commit log. -* Patches should be reviewed by at least one maintainer before being merged. - -Project maintainers should merge their own patches only when they have been -approved by other maintainers, unless there is no response within a -reasonable timeframe (roughly one week) or there is an urgent change -to be done (e.g. security or data loss issue). - -As an exception to this rule, this specific document cannot be changed -without the consensus of all administrators of the project. - -> Note: Those guidelines were inspired by the -> [Collective Code Construct Contract][C4]. The document was found to -> be a little too complex and hard to read and wasn't adopted in its -> entirety. See this [discussion][] for more information. - - [C4]: https://rfc.zeromq.org/spec:42/C4/ - [discussion]: https://github.com/zeromq/rfc/issues?utf8=%E2%9C%93&q=author%3Aanarcat%20 - -## Patch triage - -You can also review existing pull requests, by cloning the -contributor's repository and testing it. If the tests do not pass -(either locally or in Travis), if the patch is incomplete or otherwise -does not respect the above guidelines, submit a review with "changes -requested" with reasoning. - -# Membership - -There are three levels of membership in the project, Administrator -(also known as "Owner" in GitHub), Maintainer (also known as -"Member"), or regular users (everyone with or without a GitHub -account). Anyone is welcome to contribute to the project within the -guidelines outlined in this document, regardless of their status, and -that includes regular users. - -Maintainers can: - -* do everything regular users can -* review, push and merge pull requests -* edit and close issues - -Administrators can: - -* do everything maintainers can -* add new maintainers -* promote maintainers to administrators - -Regular users can be promoted to maintainers if they contribute to the -project, either by participating in issues, documentation or pull -requests. - -Maintainers can be promoted to administrators when they have given significant -contributions for a sustained timeframe, by consensus of the current -administrators. This process should be open and decided as any other issue. - -Maintainers can be demoted by administrators and administrators can be -demoted by the other administrators' consensus. Unresponsive maintainers -or administrators can be removed after a month unless they specifically -announced a leave. diff --git a/CONTRIBUTING.rst b/CONTRIBUTING.rst new file mode 100644 index 00000000..f3804df1 --- /dev/null +++ b/CONTRIBUTING.rst @@ -0,0 +1,149 @@ +Contribution Guide +================== + +This document outlines how to contribute to this project. It details +instructions on how to submit issues, bug reports and patches. + +Before you participate in the community, you should also agree to +respect the code of conduct, shipped in +:doc:`CODE_OF_CONDUCT.rst ` in the source code. + +Positive feedback +----------------- + +Even if you have no changes, suggestions, documentation or bug reports +to submit, even just positive feedback like “it works” goes a long way. +It shows the project is being used and gives instant gratification to +contributors. So we welcome emails that tell us of your positive +experiences with the project or just thank you notes. Contact +maintainers directly or submit a closed issue with your story. You can +also send your “thanks” through https://saythanks.io/. + +Issues and bug reports +---------------------- + +We want you to report issues you find in the software. It is a +recognized and important part of contributing to this project. All +issues will be read and replied to politely and professionally. Issues +and bug reports should be filed on the `issue +tracker `__. + +Issue triage +^^^^^^^^^^^^ + +Issue triage is a useful contribution as well. You can review the +`issues `__ in the +`project page `__ and, for +each issue: + +- try to reproduce the issue, if it is not reproducible, label it with + ``help-wanted`` and explain the steps taken to reproduce +- if information is missing, label it with ``invalid`` and request + specific information +- if the feature request is not within the scope of the project or + should be refused for other reasons, use the ``wontfix`` label and + close the issue +- mark feature requests with the ``enhancement`` label, bugs with + ``bug``, duplicates with ``duplicate`` and so on… + +Note that some of those operations are available only to project +maintainers, see below for the different statuses. + +Security issues +^^^^^^^^^^^^^^^ + +Security issues should first be disclosed privately to the project +maintainers, which support receiving encrypted emails through the usual +OpenPGP key discovery mechanisms. + +This project cannot currently afford bounties for security issues. We +would still ask that you coordinate disclosure, giving the project a +reasonable delay to produce a fix and prepare a release before public +disclosure. + +Public recognition will be given to reporters security issues if +desired. We otherwise agree with the `Disclosure +Guidelines `__ of the +`HackerOne project `__, at the time of +writing. + +Patches +------- + +Patches can be submitted through `pull +requests `__ on the +`project page `__. + +Some guidelines for patches: + +- A patch should be a minimal and accurate answer to exactly one + identified and agreed problem. +- A patch must compile cleanly and pass project self-tests on all + target platforms. +- A patch commit message must consist of a single short (less than 50 + characters) line stating a summary of the change, followed by a blank + line and then a description of the problem being solved and its + solution, or a reason for the change. Write more information, not + less, in the commit log. +- Patches should be reviewed by at least one maintainer before being + merged. + +Project maintainers should merge their own patches only when they have +been approved by other maintainers, unless there is no response within a +reasonable timeframe (roughly one week) or there is an urgent change to +be done (e.g. security or data loss issue). + +As an exception to this rule, this specific document cannot be changed +without the consensus of all administrators of the project. + + Note: Those guidelines were inspired by the `Collective Code + Construct Contract `__. The + document was found to be a little too complex and hard to read and + wasn’t adopted in its entirety. See this + `discussion `__ + for more information. + +Patch triage +^^^^^^^^^^^^ + +You can also review existing pull requests, by cloning the contributor’s +repository and testing it. If the tests do not pass (either locally or +in Travis), if the patch is incomplete or otherwise does not respect the +above guidelines, submit a review with “changes requested” with +reasoning. + +Membership +---------- + +There are three levels of membership in the project, Administrator (also +known as “Owner” in GitHub), Maintainer (also known as “Member”), or +regular users (everyone with or without a GitHub account). Anyone is +welcome to contribute to the project within the guidelines outlined in +this document, regardless of their status, and that includes regular +users. + +Maintainers can: + +- do everything regular users can +- review, push and merge pull requests +- edit and close issues + +Administrators can: + +- do everything maintainers can +- add new maintainers +- promote maintainers to administrators + +Regular users can be promoted to maintainers if they contribute to the +project, either by participating in issues, documentation or pull +requests. + +Maintainers can be promoted to administrators when they have given +significant contributions for a sustained timeframe, by consensus of the +current administrators. This process should be open and decided as any +other issue. + +Maintainers can be demoted by administrators and administrators can be +demoted by the other administrators’ consensus. Unresponsive maintainers +or administrators can be removed after a month unless they specifically +announced a leave. diff --git a/doc/src/code_of_conduct.rst b/doc/src/code_of_conduct.rst new file mode 100644 index 00000000..2d70708d --- /dev/null +++ b/doc/src/code_of_conduct.rst @@ -0,0 +1 @@ +.. include:: ../../CODE_OF_CONDUCT.rst diff --git a/doc/src/contributing.rst b/doc/src/contributing.rst new file mode 100644 index 00000000..ac7b6bcf --- /dev/null +++ b/doc/src/contributing.rst @@ -0,0 +1 @@ +.. include:: ../../CONTRIBUTING.rst diff --git a/doc/src/index.rst b/doc/src/index.rst index f4844849..8a693dcd 100644 --- a/doc/src/index.rst +++ b/doc/src/index.rst @@ -89,4 +89,6 @@ and test integration. upgrading man/linkchecker man/linkcheckerrc + contributing + code_of_conduct code/index