From a2a6954b42e439fda6dfc7cfd90af821f13b7dd8 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Antoine=20Beaupr=C3=A9?= Date: Mon, 26 Mar 2018 09:34:55 -0400 Subject: [PATCH 1/6] split code of conduct and contributing guidelines in two This ensure the files are in standard locations so that GitHub finds them. This will hopefully help people provide more detailed bug reports in the future as well. --- doc/contributing.mdwn => CODE_OF_CONDUCT.md | 105 -------------------- CONTRIBUTING.mdwn | 104 +++++++++++++++++++ 2 files changed, 104 insertions(+), 105 deletions(-) rename doc/contributing.mdwn => CODE_OF_CONDUCT.md (50%) create mode 100644 CONTRIBUTING.mdwn 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. From 47987c5e00cfe45a6677b3940ee433f67d2db462 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Antoine=20Beaupr=C3=A9?= Date: Mon, 26 Mar 2018 09:35:43 -0400 Subject: [PATCH 2/6] add github issue template This will help people provide the right details to reproduce issues in the future, hopefully --- .github/ISSUE_TEMPLATE.md | 41 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 41 insertions(+) create mode 100644 .github/ISSUE_TEMPLATE.md diff --git a/.github/ISSUE_TEMPLATE.md b/.github/ISSUE_TEMPLATE.md new file mode 100644 index 00000000..e6fbd792 --- /dev/null +++ b/.github/ISSUE_TEMPLATE.md @@ -0,0 +1,41 @@ + + + +## Summary + + + +## Steps to reproduce + + 1. + 2. + 3. + +## Actual result + +## Expected result + +## Environment + + + + * Operating system: + * Linkchecker version: + * Python version: + * Install method: + * Site URL: + +## Configuration file + + + +## Logs + + + + + +## Other notes + + From ca698de29d10b83e1fdf1eedd0fb642dbb2d99a4 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Antoine=20Beaupr=C3=A9?= Date: Mon, 26 Mar 2018 09:41:32 -0400 Subject: [PATCH 3/6] refer to code of conduct externally --- CONTRIBUTING.mdwn | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/CONTRIBUTING.mdwn b/CONTRIBUTING.mdwn index 443e922a..603fcbb1 100644 --- a/CONTRIBUTING.mdwn +++ b/CONTRIBUTING.mdwn @@ -1,5 +1,11 @@ -This document outlines how to contribute to this project. It details a -code of conduct, how to submit issues, bug reports and patches. +# 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` in the +source code. # Patches From 688a34f2cd21d0f213fbbc1aaaa36c44e4b8679f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Antoine=20Beaupr=C3=A9?= Date: Mon, 26 Mar 2018 09:50:45 -0400 Subject: [PATCH 4/6] add positive feedback and security issues to guidelines Positive feedback allows the community and passers-by to contribute in a positive way without requiring any technical capabilities: just a little thank you helps! Security issues might be handled differently. Explicitely state we follow responsible disclosure guidelines. This comes from the ecdysis project. --- CONTRIBUTING.mdwn | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+) diff --git a/CONTRIBUTING.mdwn b/CONTRIBUTING.mdwn index 603fcbb1..fbd2d734 100644 --- a/CONTRIBUTING.mdwn +++ b/CONTRIBUTING.mdwn @@ -7,6 +7,16 @@ Before you participate in the community, you should also agree to respect the code of conduct, shipped in `CODE_OF_CONDUCT.md` 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 . + # Patches Patches can be submitted through [pull requests][] on the @@ -80,6 +90,24 @@ Issue triage is a useful contribution as well. You can review the 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/ + # Membership There are three levels of membership in the project, Administrator From 9086a93f83f4e8862d59d118c8cf17e0cd2887e4 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Antoine=20Beaupr=C3=A9?= Date: Mon, 26 Mar 2018 09:55:59 -0400 Subject: [PATCH 5/6] more sync with ecdysis: do not assume we are on github The idea here is that this guide can be reused by other projects, which might not be on GitHub. By making the URL pointers more generic, it makes it easier to change them in one central location. --- CONTRIBUTING.mdwn | 15 +++++++-------- 1 file changed, 7 insertions(+), 8 deletions(-) diff --git a/CONTRIBUTING.mdwn b/CONTRIBUTING.mdwn index fbd2d734..260ad92c 100644 --- a/CONTRIBUTING.mdwn +++ b/CONTRIBUTING.mdwn @@ -7,6 +7,10 @@ Before you participate in the community, you should also agree to respect the code of conduct, shipped in `CODE_OF_CONDUCT.md` in the source code. +[project]: https://github.com/linkcheck/linkchecker/ +[issues]: https://github.com/linkcheck/linkchecker/issues +[pull requests]: https://github.com/linkcheck/linkchecker/pulls + # Positive feedback Even if you have no changes, suggestions, documentation or bug reports @@ -20,10 +24,7 @@ story. You can also send your "thanks" through . # 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 +[project page][project]. Some guidelines for patches: @@ -68,12 +69,12 @@ 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 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: +[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 @@ -85,8 +86,6 @@ Issue triage is a useful contribution as well. You can review the - 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. From bd3fd74fdc318dbc2a1c11415a6435dff0f13f7a Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Antoine=20Beaupr=C3=A9?= Date: Mon, 26 Mar 2018 09:56:50 -0400 Subject: [PATCH 6/6] move patch section lower Users are less likely to file patches than issues, so it should have lower priority. No other change --- CONTRIBUTING.mdwn | 84 +++++++++++++++++++++++------------------------ 1 file changed, 42 insertions(+), 42 deletions(-) diff --git a/CONTRIBUTING.mdwn b/CONTRIBUTING.mdwn index 260ad92c..32421a91 100644 --- a/CONTRIBUTING.mdwn +++ b/CONTRIBUTING.mdwn @@ -21,48 +21,6 @@ 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 . -# 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. - # Issues and bug reports We want you to report issuess you find in the software. It is a @@ -107,6 +65,48 @@ desired. We otherwise agree with the [Disclosure Guidelines][] of the [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