Motivations
The “why” of open source has been covered pretty well by now (see below), this document aims to tackle the “how” by highlighting the areas in which we need written policy to succeed in open-sourcing our projects.
This document is divided into numbered sections and questions to facilitate easy discussion and resolution.
https://www.gov.uk/service-manual/technology/making-source-code-open-and-reusable
https://www.england.nhs.uk/digitaltechnology/open-source/
[why-open-source-v1.2.pdf]
Objectives
Build a Strategy
Implement a Licence
Contribution Guidelines
Code of conduct
Update READMEs
1. Build a Strategy
1.1 Objectives
(1.1.1) What does success look like for HEE and how does open source help achieve that?
(1.1.2) What would a successful open source implementation look like for HEE?
1.2 Engagement
(1.2.1) Do we want an open policy (accept any and all contributions), a “look but don’t touch” policy or something in between?
o Little point embracing open source if we’re not going to accept contributions, but could present a significant additional workload if not managed carefully (“working on open source is reading 800 issues over the course of a weekend”).
o (1.2.1.1) What kind of contributions do we want? (need to define with policy document/published contribution guidelines
o Are we looking to supplement our dev team (any and all welcome)
o Do we want healthcare focussed input (which aspects?)
o Do we only want application quality/security input?
o Etc
o (1.2.1.2) Do we want to actively grow our community of contributors? E.g. join groups like Code4Health, promote contribution via social media etc etc.?
1.3 Governance
(1.3.1) What structure do we want for our open source projects?
o “Benevolent dictator” – one person (or TIS Dev team as a unit) has final say
o Community vote (which community members? Individuals only or corporations?)
(1.3.2) Who handles contributions? How are they handled? (policy document & process)
o (1.3.2.1) Who assesses the contribution? (i.e. does this fit with our vision)
o (1.3.2.2) Do we need a separate board to track PRs? (policy: open an issue before raising a PR?)
o https://steveklabnik.com/writing/how-to-be-an-open-source-gardener
(1.3.3) What kind of community do we want to foster?
o Fully open?
o Healthcare groups e.g. https://code4health.org/
(1.3.4) How do we handle conflict/bad actors? Who’s responsibility is it?
2. Implement a Licence
(TLDR – no one will contribute to our codebase without a license)
Why we need a license:
By default, our code is under “exclusive copyright” which typically means nobody can use, copy, modify or distribute our without risk of litigation – obviously this is the opposite of what we expect with open source. (This also means that individual contributors hold exclusive rights over the contributions they submit!)
A license is required to explicitly state the permissions we wish to grant. There are a number of licenses available for different use cases.
(2.1) Choosing a license
Permissive (e.g.MIT) – People can do pretty much anything under this licence including making and distributing closed-source versions?
Copyleft (e.g. GNU GPLv3) - Just as permissive does not allow users to distribute closed-source versions of the code?
Permissive licences appear to increasingly be the norm. If more granular options are needed: https://choosealicense.com/
3. Contribution Guidelines
(3.1) Contribution Processes
How to contributors:
(3.1.1) Report bugs? https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/about-issue-and-pull-request-templates
(3.1.2) Suggest features?
(3.1.3)Set up environments and run tests?
(3.2) Contribution Objectives
What do contributors need to understand about the project in terms of:
(3.2.1) What contributions do we want?
(3.2.2) What is our roadmap for the given project? (VISION) file
(3.2.3) How should (or shouldn’t) contributors get in touch?
(3.3) Proposed Sections to Contribution Document
Welcome Statement
Table of Contents
Short Links to Important Resources:
docs (Handbook? Roadmap?)
bugs (issue tracker? Reporting tool?
comms
Style Guide / Coding conventions
Code of Conduct (direct or linked)
Testing
Environment details
First “things we want you to look at” for Contributors
How to submit changes
How to report a bug
Templates (links to)
How to suggest features
Recognition (pre-emptive “thankyou”)
Who is involved?
Where can I ask for help?
4. Code of Conduct
(4.1) Code of conduct document
(4.1.1) DIY or adopt existing like licence (e.g. https://www.contributor-covenant.org/ )
If DIY, some considerations:
Statement of vision for community
Examples of acceptable and unacceptable behaviours
Responsible individuals and roles
Enforcement policies (consequences, bands etc)
5. Update READMEs
(5.1) Ensure all READMEs are up to date
(5.1.1) Who needs to do this?
(5.1.2) Who has final say?
(5.1.3) Do we need/have a README Template and “required sections”
0 Comments