As the OpenMRS community grows, it is important to offer opportunities for contributors & customers to connect with people in their part of the world. We also need a more coordinated effort to build local representation and expertise. One approach for achieving these goals is to develop local communities. The purpose of this document is to introduce the OpenMRS local community building effort and describe its merits.
Develop stronger relationships with community members
Encourage leadership in members of local communities
Build stronger local representation and identity
Attract new volunteers to local and global communities
Build and share local knowledge
Build stronger connections from local communities to the OpenMRS central leadership
We will support any type of community, which may consist of contributors or customers, developers, implementers, clinicians, or other types of people interested in OpenMRS. All we ask is that the group(s) demonstrate their collective desire for OpenMRS-related collaboration at a local level. A local community could be established in (but is not limited to) the following situations:
A group of geographically co-located individuals want to support the implementation of OpenMRS in their region. These individuals could be implementers, developers or clinicians. The type of individuals involved would determine the type of local community created.
A group of individuals (geographically co-located or not) want to support a specific set of feature or content development tasks. These individuals could be implementers, developers or clinicians. The type of individuals involved would determine the type of local community created. This type of community is similar to a special interest group (SIG).
Geographically co-located groups that are interested in non implementation specific tasks such as using, building and growing OpenMRS want to meet regularly to discuss concerns.
Local groups that already exist will be encouraged to apply for formal recognition. Following an evaluation process by the community management team, they will be approved and recognized as an official local community.
The baseline requirement for a local community is that they must regularly meet in person to make progress on the stated goals of their group.
The official/canonical name of each local community will be "OpenMRS ____ Community", e.g., "OpenMRS Kenya Community", which will exist both in English and in the local language(s) of the geographic place(s) for the community. Additionally, a local community may choose a short name "prefix" in their local language, e.g., "eSaude: OpenMRS Mozambique Community". Selecting a name should be a collaborative process between local community members and the global community management team.
Each community can choose from among dedicated resources such as:
Baseline for each community: OpenMRS Talk Category and custom URL, e.g., http://kenya.openmrs.org/
Dedicated OpenMRS.org wiki pages or wiki space
Dedicated OpenMRS.org JIRA issue tracking project(s)
IRC channel, e.g., #openmrs-kenya
Dedicated GitHub organization or set of repositories
Customized Local Community logo
Each OpenMRS Local Community will be responsible for the following:
Scheduling regular in person or virtual meetings. The local community should meet reasonably regularly to discuss the issues that affect their communities. The meeting schedule and the minutes of these meetings should be made available to the broader OpenMRS community in the interest of knowledge sharing.
Self-government and appointment of leadership. Each OpenMRS local community should have some guide of defined community goals and/or documented process. There should also be at least one community leader that will serve as an interface between the local community and global OpenMRS community.
Developing their own formal agenda and/or focus areas. Depending on the type of community (developer / implementer / clinician / etc), the objectives of the local communities may differ, but these objectives should nevertheless be definite and made publicly available.
Reporting to the global community. The activities of local communities should be communicated back to the global community regularly (once per quarter) via the community leader.
Formal recognition for events/efforts launched by the group. This could be in the form of announcement make on the various global OpenMRS communication channels (social media / lists / forums / IRC / blog) or by special mention during in-person meetings.
Community specific logos. Communities can request a group-specific logo that includes a custom variation of the OpenMRS logo and trademark as part of the local community identity.
Goodies for any public events. A small budget will be available for items such as stickers, swag, or similar to be produced and made available for the community to distribute at official local events.
Official representation to the global leadership team. Community leaders will have regular communication with regional community managers, who will help to ensure the community's success.
Technical expertise for OpenMRS-related efforts,
Increased priority for travel grants/awards for team members to represent OpenMRS at worldwide events, and
Additional resources as needed, such as local community-specific communication channels, JIRA projects.
The OpenMRS global community management team will be responsible for the governance model for local communities. The initial team members are Michael Downey, Suranga Kasthurirathne, and Pascal Brandt. This team is responsible for setting up the process and will is responsible for maintaining the process as well considering applications for new local communities.
Local Community leaders will engage with other local communities regularly help the communities be successful, grow and perform their responsibilities. Once per quarter, each leader will provide a progress report back to the global community management team about their community's activities during the preceding quarter.
The community management team will set up and maintain information here that outlines some ideas for local communities. These could include recommendations such as urging all local community members to create and OpenMRS ID, etc.
Each local community, in coordination with the community management team, should develop documentation such as a wiki page with details about their local community.
The following might be useful for local community coordinators:
Blog post about organising a Mozilla community.