diff --git a/doc/contributing.mdwn b/CODE_OF_CONDUCT.md similarity index 50% rename from doc/contributing.mdwn rename to CODE_OF_CONDUCT.md index e6b83f84..ddd58a0a 100644 --- a/doc/contributing.mdwn +++ b/CODE_OF_CONDUCT.md @@ -1,6 +1,3 @@ -This document outlines how to contribute to this project. It details a -code of conduct, how to submit issues, bug reports and patches. - # Contributor Covenant Code of Conduct ## Our Pledge @@ -103,105 +100,3 @@ the Django enforcement manual. > already available online and the relatively small size of the > community. This may change in the future if the community grows > larger. - -# Patches - -Patches can be submitted through [pull requests][] on the -[GitHub project][]. - -[pull requests]: https://github.com/linkcheck/linkchecker/pulls -[GitHub project]: https://github.com/linkcheck/linkchecker - -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. - -# Issues and bug reports - -We want you to report issuess 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 -professionnally. Issues and bug reports should be filed on the -[GitHub issue tracker][issues]. - -## Issue triage - -Issue triage is a useful contribution as well. You can review the -[issues][] in the GitHub 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... - -[issues]: https://github.com/linkcheck/linkchecker/issues - -Note that some of those operations are available only to project -maintainers, see below for the different statuses. - -# 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. diff --git a/CONTRIBUTING.mdwn b/CONTRIBUTING.mdwn new file mode 100644 index 00000000..443e922a --- /dev/null +++ b/CONTRIBUTING.mdwn @@ -0,0 +1,104 @@ +This document outlines how to contribute to this project. It details a +code of conduct, how to submit issues, bug reports and patches. + +# Patches + +Patches can be submitted through [pull requests][] on the +[GitHub project][]. + +[pull requests]: https://github.com/linkcheck/linkchecker/pulls +[GitHub project]: https://github.com/linkcheck/linkchecker + +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. + +# Issues and bug reports + +We want you to report issuess 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 +professionnally. Issues and bug reports should be filed on the +[GitHub issue tracker][issues]. + +## Issue triage + +Issue triage is a useful contribution as well. You can review the +[issues][] in the GitHub 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... + +[issues]: https://github.com/linkcheck/linkchecker/issues + +Note that some of those operations are available only to project +maintainers, see below for the different statuses. + +# 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.