OpenSAFELY is an open source project; all our code is available for inspection and reuse, and we can accept contributions in the following ways:
Typos and other small improvements are always very welcome. Raise an issue, or even better a Pull Request, in the documentation repo. We will incorporate these contributions after we've checked them for consistency with our house style.
We welcome proposals for longer topic-based guides. Suggest them as an issue in the documentation repo, and we'll work with you to define an overall structure and format, before you write and submit the draft.
These are units of software that solve a problem for several studies without the need to copy-and-paste between them, described in more detail here. They can be shared between researchers, even between groups that use different programming languages, and are one of the best ways you can make contributions that benefit the community. If you've written a reusable action you'd like to contribute to the actions library, please get in touch at [email protected].
Study definition patterns🔗
Study definitions are intended to be shared under open source licences, and they can be found in the OpenSAFELY Github organisation. We welcome all ideas that may be able to help other members of the community, which we can incorporate in our documentation (for example on this page about study definition tips); we're also happy to help publicise blog posts, or host them as guest blog posts on our website. Just submit a ticket to the documentation repository with your suggestion.
We encourage researchers to post questions in the Q&A Forum. We would love more people to chip in and attempt to answer questions!
We would like to accept ad hoc contributions to the core code, but this is relatively hard for us to do. New features and bugfixes need a lot work from our side to integrate and maintain, because a lot of the design and prioritisation decisions are made with lots of different parts of the framework in mind. Most code changes have an associated administrative and legal burden: we need to secure contributor agreements from individuals or their employers. We plan to seek funding to help resource this kind of work, as we believe it can really strengthen and build our community, but for the time being, we suggest filing bug reports or feature requests rather than contributing code.
An exception is where external contributors are in a position to dedicate significant resource (e.g. more than one full-time person equivalent) for a prolonged period of time. In these cases, we will be happy to consider allocating resource from our side to help with the planning and integration work; just get in touch with your proposed features at [email protected].