Code of Conduct

Executive Summary
At Tuesday’s Technical Committee meeting, one of the topics is consideration of a Code of Conduct for OpenLMIS. Many open source projects adopt a Code of Conduct to make sure all collaborators pro-actively work towards a diverse and welcoming environment, and to make sure there is a clear channel to address any harassment or unacceptable behavior. After reviewing different options, I’m suggesting we consider adoption of the “Contributor Covenant” ( version 1.4 which many Open Source projects have adopted. Please respond or join Tuesday’s meeting with any ideas or input.


Please review the Contributor Covenant version 1.4 that we are considering: . This has become a popular Code of Conduct that many projects have adopted, including large Open Source projects that OpenLMIS uses including Spring, Jenkins and AngularJS. Adopting a Code of Conduct will help make sure our community remains diverse and inclusive. It will also help as OpenLMIS works with more outside contributors, such as Summer of Code participants.

The Technical Committee is the first group to discuss this and give input. After this, other committees, especially Governance Committee, will likely be part of the process of reviewing and approving.

Many open source projects have different codes of conduct. I did a cursory review of others, and I believe the Contributor Covenant is a good fit. It is widely adopted, we can use it “off the shelf” without lots of work. It covers all the kinds of diversity and inclusion that I believe we want to address and it does so in a succinct and clear way.

If you want to read other examples of Codes of Conduct and similar open source guidelines, this blog post has an “Open Code of Conduct” that has some good language and ideas along with links to many more open source examples: Mozilla also has well-written participation guidelines: .

One open question is what email address or channel to contact to report any inappropriate behavior. We would need to discuss that with other stakeholders too, but I suggest that might be a good place. That routes to the Community Manager, who would be responsible for getting the issue to the right people and maintaining confidentiality of parties as appropriate. Josh had also suggested using GitHub issues or using JIRA issues; however I believe both of those would be public and it appears the standard practice is to allow people to report a problem without sharing that publicly. We can discuss that more at this meeting and with all the people who would be involved.

Do you have any other questions or input? Feel free to reply via this email group or attend the Technical Committee Tuesday to discuss further.

Technical Committee — Meeting Info