Revise "community" and "license" standards

[jtniehof]

(Broader context at the end).

This issue is to discuss a potential PHEP to replace the "community" and "license" portions of the existing PyHC standards: to lay out what looks like the current standards, and allow for suggested changes.

I am lumping "license" with "community" because "community" was essentially our open development section, but that's just an open suggestion. Existing standards are:
2. Open Development: All code must be made available and developed publicly.
5. License: Projects must provide a license. Projects should use permissive licenses for open source scientific software (e.g., the BSD 2-clause, BSD 3-clause, or BSD+Patent licenses). Copyleft licenses such as GPL are not recommended and OSI-approved permissive licenses are recommended.
12. Duplication: Duplication of code and functionality is discouraged. Forking projects into new projects is strongly discouraged.
13. Collaboration: Contributions to packages must be encouraged. Packages must provide contribution guidelines and clearly explain when a contribution is not accepted.
15. Code of conduct: Each project must adopt a code of conduct that is compatible with the Contributor Covenant and make it publicly available.

We're having a lot of conversations around 12 so it may be worth particularly thinking about that language.

#16 has suggested updates to standards 13 and 15 (in that issue, standard 15 has become standard 16).

Broader context: I envision a process of "patriating the constitution" where we revisit the existing standards documents and incorporate them into PHEPs, potentially updated, that are explicitly noted as replacing the relevant standards. We probably do not want one PHEP per standard. Our previous grouping in the review guidelines seems a good start.

[jtniehof]

I'm not sure if it's best to describe these as "community" or "open development" standards. Strawman standards, with changes in bold:

• All code must be made available and developed publicly. Development must be in a version controlled repository which is accessible to the public. New projects should use git. (replaces standard 6; version control strongly supports open development. See Revise "Testing" and "Software Maturity" standards #35).
• Projects should have a means of discussing design and other decisions in a way that allows for public visibility and input. (This keeps the development open, not just the code.)
• Projects must have a means of collecting user feedback, bug reports, feature requests, and other inputs.
• Projects must provide an open source license. Projects should use OSI-approved permissive licenses (e.g., the BSD 2-clause, BSD 3-clause, or BSD+Patent licenses). Other open licenses, such as NASA Open Source Agreement and copyleft licenses such as GPL, are acceptable but not recommended.
• Duplication of code and functionality is discouraged. Forking projects into new projects is strongly discouraged.
• Contributions to packages must be encouraged. Packages must provide contribution guidelines and clearly and constructively (Update standards based on Nov 2019 PyHC meeting discussion #16) explain when a contribution is not accepted. External contributors should have access to the same or similar workflow as project developers, e.g. pull requests and reviews. (The intent is to make contribution as smooth as possible).
• Each project must adopt a code of conduct that is compatible with the Contributor Covenant and make it publicly available. Each project should have a reporting procedure for reporting violations of the code of conduct and make it publicly available (for a highly detailed example, refer to the Code of Conduct Response and Enforcement Manual for NumFOCUS). (Update from Update standards based on Nov 2019 PyHC meeting discussion #16--it would also be good to have some best practices for email vs. other means of communication, anonymity/privacy, etc.)

[jtniehof]

"For a More Transparent Governance of Open Source" (10.1145/3570635) might be worth consideration in this context...

[rebeccaringuette]

The license item seems nicely covered in the package tier PHEP #31, but the others seem like a good combination, including the changes you added. Specific comments below.

• All code must be made available and developed publicly. Development must be in a version controlled repository which is accessible to the public. New projects should use git. (replaces standard 6; version control strongly supports open development. See Revise "Testing" and "Software Maturity" standards #35).

Suggest this as a "must" for bronze.

• Projects should have a means of discussing design and other decisions in a way that allows for public visibility and input. (This keeps the development open, not just the code.)

Suggest this as a "must" for bronze since this seems to be just having a way to post issues. Whether those things are actually discussed there may be a more complicated conversation.

• Projects must have a means of collecting user feedback, bug reports, feature requests, and other inputs.

Suggest this as a "must" for bronze since I think it just requires some tagging system in the issues and PRs. Or should a "must" for this be silver?

• Projects must provide an open source license. Projects should use OSI-approved permissive licenses (e.g., the BSD 2-clause, BSD 3-clause, or BSD+Patent licenses). Other open licenses, such as NASA Open Source Agreement and copyleft licenses such as GPL, are acceptable but not recommended.

Suggest moving this to #31.

• Duplication of code and functionality is discouraged. Forking projects into new projects is strongly discouraged.

Make this a "must" for copper? As in forked projects submitted to PyHC will not be accepted without approval from the project it was forked from (if that project was a PyHC project)?

• Contributions to packages must be encouraged. Packages must provide contribution guidelines and clearly and constructively (Update standards based on Nov 2019 PyHC meeting discussion #16) explain when a contribution is not accepted. External contributors should have access to the same or similar workflow as project developers, e.g. pull requests and reviews. (The intent is to make contribution as smooth as possible).

Add "and allowed without additional legal processes" to the end of the first sentence. For contributions, suggest "must" at bronze level since it is just requiring people to have conversations on GitHub. For the workflow item, perhaps that becomes a "must" at silver and is just a "should" at lower levels? There should be some discussion on whether some conversations are not allowed on GitHub due to classified status, and whether that even matters here.

• Each project must adopt a code of conduct that is compatible with the Contributor Covenant and make it publicly available. Each project should have a reporting procedure for reporting violations of the code of conduct and make it publicly available (for a highly detailed example, refer to the Code of Conduct Response and Enforcement Manual for NumFOCUS). (Update from Update standards based on Nov 2019 PyHC meeting discussion #16--it would also be good to have some best practices for email vs. other means of communication, anonymity/privacy, etc.)

Suggest this becomes a "must" at the silver level.
I don't expect many tomatoes on this one since the items here are already common practice for the most used packages and simply the right way to go to have a package that is truly developed in the open.

[jtniehof]

From the fall meeting, consensus is:

• We need to talk more about licenses. In particular, what should be "preferred" licenses and what are reasonable escape hatches for non-"preferred"? See Report of OSI License Proliferation Committee
• Little appetite for further community-related standards, what we've got isn't bad