jtniehof
commented
1 week ago 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 #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 (#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 #16--it would also be good to have some best practices for email vs. other means of communication, anonymity/privacy, etc.)
(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:
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.