Contributing

eRegulations is an open source project with contributions from individuals and federal agencies. We invite contributions to any part of the application, from people inside and outside government.

We aspire to create a welcoming environment for collaboration on this project. To that end, we follow our Code of Conduct and ask that all contributors do the same.

Public domain

This project is in the public domain within the United States, and copyright and related rights in the work worldwide are waived through the CC0 1.0 Universal public domain dedication.

All contributions to this project will be released under the CC0 dedication. By submitting a pull request, you are agreeing to comply with this waiver of copyright interest.

Governance

The eRegulations project began as a work of the Consumer Financial Protection Bureau, but has been adopted by several federal agencies with significant contributions from 18F. Along the way, literally dozens of people have contributed code, designs, ideas, and management across multiple teams. Combine this with the fact that the work is all in the public domain and it becomes clear that the project has no single owner. Defining direction in this environment is inherently challenging, so we take a pragmatic approach.

Day-to-day changes (largely backwards-compatible changes) should be reviewed by a second set of eyes before merging, but can be merged by anyone in the eregs organization. However, to keep the project moving forward, we allow the original submitter to merge their own submissions after one week if there is no dissent.

Larger policy changes and major code shifts warrant additional input from affected parties. Therefore, such changes should be open for discussion (as an issue in the eregs.github.io repository) for a minimum of two weeks. During this time, anyone in the eregs organization can veto these changes; this is a bit of a nuclear option, so we try to avoid it in favor of constructive dialog. We defer defining exactly what “major” and “day-to-day” changes are and how to avoid deadlock in veto scenarios until the need arises. We use our best judgement.

In summary:

• Day-to-day changes can be merged by anyone in the org
• Day-to-day changes should not be merged by the submitter unless 1 week has passed
• Policy changes should be open for discussion for at least 2 weeks
• Policy changes can be vetoed by any org member

Release policy

We follow semantic versioning and will cut releases once a quarter (if code has changed) or more frequently if downstream projects need them.