eRegulations is an open source project with contributions from both individuals and agencies of the United States government. As such, general inquires and curiosities can be directed to the whole group by opening an issue in our GitHub repository. GSA’s 18F also hosts a Slack channel that’s open to the public; join by filling out the requested information and selecting “eRegulations” as your topic.

If you are interested in working with 18F for hosting and customization of an eRegs instance, contact Will Sullivan at or


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 individuals have contributed code, designs, ideas, and management across multiple teams. Combine this with the fact that the work product 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 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