3 Community building
While scoping your project, it is well advised to think about the different people who may engage with your OSH (see Section 4.7). Different OSH projects have included different partners at varying stages of their development. On top of user and contributor roles that OSH have in common with open source software, local or global hardware manufacturers may become important partners of your project. You may also think early about the people who will eventually have to maintain and repair the hardware. To make it easier for them, it also helps to make your hardware designs modular (splitting your hardware in modules which may have alternative designs). Another specificity of hardware may be the importance of the creation of replication tutorials, workshops, seminars, or training materials (Section 2.6), which can impact the adoption of hardware designs. This is particularly relevant if the OSH is meant to be produced in Do-It-Yourself environments or as a teaching opportunity.
It is important to decide whether, when and where you want to engage with, or build a community. Most OSH communities are local in comparison to open source software project. You may not have the time or skills to build a community, and your project may not need a community to flourish. Always be honest with your collaborators and yourself about what support they can expect.
Documentation which may help build a community can range from a simple note on the work culture in the readme, toward a full, implemented code of conduct and community guidelines on ways to interact in the community and with the project documentation.
Community - work culture
Communicate the work culture that you want to promote and policies that ensures the safety and security of both your data and people.
Sources
Community - Guidelines
Describe what opportunities for collaboration different members will have. When possible, such as in an open source project, provide these details for those outside the current group, especially when you want to encourage people outside the project to be involved.
Provide resources on ways of working to ensure fair participation of contributors who collaborate on short- and long-term milestones within the project. It reduces or addresses concerns about the project’s progress towards meeting goals and prevents potential fallout between project contributors.
Considering the variety of different backgrounds and skills your members bring, describe how they can participate and start contributing. You should also think about your audience. Your project might be reused by people with different skills, roles, objectives, and socio-economic and cultural environments.
Provide clear opportunities for contributions, review, management, mentoring, and support. Provide an overview of how different contributions or resources are connected and how new contributions will fit into existing materials.
Describe how your research objects are available or will be published and how different contributors will be recognised. It helps when everyone feel appreciated and acknowledged for their contribution to the overall vision.
A thoughtful guideline helps people decide which pathway they can choose to contribute to your project, or if they want to be in your community at all.
Make sure that your community interactions and different pathways to contribute are open, inclusive, and clearly stated.
- If people can’t figure out how to contribute they will drop off without helping.
Value different types of contributions - coding projects are not only about code, therefore list documentation and other management skills as well.
Sources
Community – Code of conduct
Add an Open Source Project Codes of Conduct to your project, see https://opensourceconduct.com/ for examples
This document should not be used as a token, it is very important to put intentional effort into it.
List the expected and unacceptable behaviors, describe the reporting and enforcement process, explicitly define the scope, and use an inclusive tone.
Whenever you update your code of conduct, invite comments from your members to ensure that their concerns are addressed.
Sources
Section 9.4, https://book.the-turing-way.org/collaboration/new-community/new-community-guide
Community - Governance
Provide a decision-making framework to facilitate discussions and reaching a shared conclusion. In the context of software and hardware, open source projects are often as much about communication as they are about coding or building (if not more). Allow informed discussions when a particular project design has reached the end or when it is useful to update it for efficiency and sustainability.
A leadership structure in an open project should aim to empower others and develop agency and accountability in your community. You can start by listing different tasks within your project and inviting your members to lead those tasks. Provide appropriate incentives and acknowledgment for the contributions made by your community members. Create opportunities for members to share some leadership responsibilities with you in the project. When inviting suggestions and ideas from the community, provide the first set of plans where your community can develop from.
More information:
- https://opensource.guide/leadership-and-governance/
- https://book.the-turing-way.org/ethical-research/ethics-open-source-governance
Sources