Policy Simulation Library Project Criteria
- Models must be transparant.
- Interface recommendations fascilitate interoperability.
- Organizational recommendations fascilitate community.
Open-source modeling ensures that model results are reproducible, that experts around the world can collaborate to make models better, and that users can explore the parameter space for themselves. These outcomes systematically improve public policy decisionmaking.
We have developed the criteria in this document to fascilitate the growth of an open source public policy modeling ecosystem.
PSL establishes three kinds of project Criteria. A project are required to (
MUST) conform to
Acceptance Criteria to be accepted in PSL. Projects are recommended to (
SHOULD) or optionally (
MAY) conform to various
Community Criteria and
Acceptance Criteria for Transparancy and Quality
- Models MUST be released under an OSI-approved open source license or the Creative Commons Public Domain Dedication (CC0).
- Data MUST be publicly available, unless release is restricted by a third party.
- For any data that SHOULD not be disclosed, provided MUST be:
- A complete descriptive list of all data variables;
- Descriptive statistics for all data variables for such data (including averages, standard deviations, number of observations, and correlations to other variables), to the extent that the descriptive statistics do not violate the rule against disclosure;
- Contact information for the individual or entity who has unrestricted access to the data.
- At least one test MUST generate key outputs from source materials, the test MUST be run with every new version, and the outputs of the test MUST be checked into the repository.
- Projects MUST have unit tests and SHOULD report code coverage.
- Projects MUST report names and contact information for at least one maintainer.
- Projects MUST have a suggested citation.
- Projects MUST have a project overview.
- Projects MUST have installation directions.
- Project MUST be mirrored in the same GitHub organization as PSL, and therefore they MUST be under version control.
- Projects MUST use a consistent versioning scheme, which SHOULD be semantic versioning. If projects want to use the PSL Package-Builder tool to distribute packages via the Anaconda Cloud PSLmodels channel, there are additional MUST criteria.
- Projects SHOULD have a public roadmap.
- Projects SHOULD have contributor documentation and guidelines.
- Projects SHOULD have regular office hours, webinars, or standing meetings.
- Projects SHOULD list technical contributors.
- Projects SHOULD list funders.
- Projects SHOULD list user citations and case studies.
- Projects SHOULD include subject matter tags, chosing from ...
- Projects SHOULD include a disclaimer.
- Projects SHOULD have a public issues tracker.
- Projects SHOULD have a changelog.
- Projects MAY have a Stack Overflow channel.
- Projects MAY include a "News" translation of the changelog for users.
- Projects MAY include criteria for participating in cross-model PSL initiatives.
- Projects MAY include a link to a webapp verison.
- Projects MAY include a list of consultants.
- The source code SHOULD be written in an open source language.
- All input and output variables SHOULD be documented like...
- All policy parameters and assumptions SHOULD be documented like...
- Meta information about your project SHOULD be documented like...
PSL_catalog.jsonconfiguration file to be used for cataloging these criteria MUST be included in the project's repository. Specifc instructions for creating this file can be found in the Catalog-Builder Documentation.