Open source with a dash of organizational structure
How things get done
CiviCRM, as a project, is a do-acracy. We state it in our community guidelines. We cite it often when we debate. We celebrate it. The beauty of a do-acracy is that those contributors that “do” get stuff done. The weakness is that it’s often unclear what the process is for “doing”, why something was “done”, or whether or not what’s getting “done” is in alignment with the rest of the project. Without clear rules and guidelines, it’s difficult to answer these. However, with too many rules and guidelines we risk detracting from our do-acratic culture.
Nonetheless, we’ll attempt here to outline the process of how things get done and how decisions are made within the CiviCRM project. Our primary objective in outlining how things get done is to better enable and empower volunteer contributors. We encourage community members to take responsibility and to participate in directing CiviCRM in collaboration with the CiviCRM Core Team.
WORKING GROUPS | IN PRACTICE | COLLABORATION | COMMUNITY COUNCIL | CORE TEAM | INSPIRATION
Working Group-based Structure
CiviCRM, as a project, is organized into various groups that address distinct processes, operations or functions. Groups vary in size, scope and significance, and correspond to “Groups” in Gitlab, CiviCRM’s primary project management tool. They are ongoing in nature and form an umbrella over related projects. Groups are responsible for establishing and overseeing projects.
Groups self organize and define the parameters under which they will operate. Groups may or may not have defined leaders, election processes, roles, responsibilities, etc. In cases where there is a defined group leader, their role is to help facilitate initiatives as well as engagement within their respective groups. They are volunteers that either volunteered to lead the group, or were otherwise appointed or elected. Like groups themselves, group leaders make a commitment to manage the group for an ongoing basis.
Projects are smaller initiatives that exist within groups, that are narrower in scope, often have beginning and end times, and typically involve fewer community members. Most initiatives in CiviCRM are projects… smaller, one time efforts that achieve a specific result under the context of a larger ongoing effort. They are normally managed by one or two individuals that, generally speaking, not only do the work, but engage with the community to ensure that their efforts meet standards and have the broadest impact. Most project leaders are self appointed (as volunteers scratching an itch) or tagged by group leaders to head up an initiative.
Most projects adhere to group practices to the extent possible. For example, new developments should follow CiviCRM’s development standards, and new events should adhere to the guidelines set by the events group. Project leaders should coordinate with group leaders as needed.
In Practice
First and foremost, it’s important to state again that there are very few hard and fast rules. As defined in CiviCRM’s community guidelines, participation is open and available to any member of the CiviCRM community. All fixes and improvements and contributions are done openly through community consultation, pull requests to the code, peer review, etc..
In the beginning, there was an itch…
Generally speaking, most improvements to CiviCRM, be they a bug fix, a new feature, a local event, etc., arise out of a defined need, or an itch (as in, ‘scratch your own itch’). At this point, the scope of the need defines the process through which it is initiated, managed and ultimately realized.
For example, a single user may have one small need that is unique to them. They modify the code they need, patch their installation, and their need is met. They need not engage any other member of the community to determine the best way to meet the need or to receive any sort of approval.
At the other end of the spectrum are changes to the project that have broad scale impact and stand to affect all or nearly all of CiviCRM’s user base. Unlike the simple itch from one organization, these sorts of changes require careful consideration, community consultation and, ultimately, time to weigh the impact of change as well as the best manner to adopt it.
Naturally, there’s an entire range of possibilities between these two examples. CiviCRM’s group-based structure affords community members a practical way to organize, collaborate around and ultimately manage an idea that could have broad impact. As the size of their effort grows, so too can their reach into the community. Likewise, as more and more community members get involved it becomes increasingly important to solicit and document feedback, to present results that are most compatible with the broader community, and to subsequently communicate outcomes.
Collaboration & Decision Making
As stated, the larger the initiative, the more important it is to collaborate within the community to ensure broad acceptance. The way this is done, however, can vary depending on the initiative and its target audience.
- Online Discussion - the most common way the community collaborates is through consistent communication and discussion. This happens in several channels, such as on Mattermost or on issues, readme and wiki pages in Gitlab, or even on Stack Exchange, Github and random documents. This is a great way to get ideas quickly, but it presents challenges in that it can be difficult to quantify and aggregate discussions.
- In-person Discussion - similar to online discussions, however these use an older technology called “face to face”. Hey, sometimes old technologies are the best! And, often, the in-person discussions at events, sprints, meetups, etc. produce the best results. These can be done one on one or in a group setting.
- Polls - polls can vary in size, medium and outcome, but the jist is basically the same: create a mechanism whereby community members can best provide structured feedback.
- Make It Happen campaigns - this is like voting with your dollars, and is often used to help crowd fund initiatives that may not otherwise be realized by any one user or organization.
- Formal Voting - establishing a process through which specific individuals may participate in a decision.
Again, there are few hard and fast rules that define the exact process that must be followed in order to facilitate participation in CiviCRM. Suffice it to say that if you want general acceptance of your idea, you should make a best effort to engage the community, to build consensus and to communicate results. Whether you do it strictly through discussion or via a combination of channels is up to you.
Let’s face it, in reality, managing CiviCRM is never that simple or that perfect, regardless of the structure put in place. Open source is messy and constantly moving! It is always a challenge to ensure that everyone that should weigh in with an opinion does so in a timely manner. And, of course, there are those that weigh in that shouldn’t. How does the community distill the feedback properly to ensure that the best rises to the top and helps ultimately shape the direction of the initiative? And what happens when there’s a dispute or conflict? And, of course, there are always unforeseen consequences. How are these managed?
By no means are the groups and projects perfect, but they do allow for a way to communicate an initiative and to solicit feedback. How that’s done depends on the needs of the initiative.
Decisions, Discussions, Debates and Disputes
At times, decisions may not be clearly evident and may result in lengthy discussions, difficult debates and, unfortunately, disputes. Again, the foundation for managing such engagements rests in the CiviCRM community guidelines and CiviCRM code of conduct.
Generally speaking, decisions may be made through formal vote or general consensus building, depending on the circumstance and the processes adopted by the group and/or project. The nature of the CiviCRM project allows for flexibility in resolving decisions where there is an impasse. Decisions may be debated at the project level and escalated to the group level in order to reach consensus. Likewise, groups may refer discussions to either the Community Council (tbd) or CiviCRM Core Team (info@civicrm.org), depending on which provides oversight.
In such cases where agreement cannot be reached at the level of the Community Council, the CiviCRM Core Team maintains the necessary decision making authority.
Finally, in very rare instances and in those specifically related to financial and legal matters, CiviCRM LLC is ultimately responsible.
The Community Council
The Community Council is currently under development. More information soon!
The CiviCRM Core Team
The CiviCRM Core Team coordinates contributions from community users and developers, ensures that people have access to the infrastructure they need to work and communicate effectively, and provides leadership for the overall project. It is comprised of group leaders of the infrastructure, development, security and maintenance groups combined with members of CiviCRM LLC. They are tasked with the production and maintenance of CiviCRM the software, stewardship of the CiviCRM community, and management of the project’s financial and legal interests.
Membership & Decision Making
CiviCRM Core Team appointment is based on a form of meritocracy where group members have demonstrated interest, capability and alignment to take on a leadership role within one of the groups over which the Core Team maintains responsibility. Core Team members participate indefinitely until either they lose interest, lack sufficient capacity to fulfill their duties, or are removed by unanimous agreement by the remaining Core Team members.
The CiviCRM Core Team consults extensively with the CiviCRM community regarding initiatives that have broad impact. Core Team members participate in decisions through voting where a majority or unanimous vote are required. Decisions requiring a vote are evaluated and taken on a case by case basis.
Finance & Budget
The CiviCRM Core Team is funded via a mixture of financial contributions and earned income. Unless otherwise designated, financial support is managed via CiviCRM’s general fund. Individual groups may have their own budgets, either independent of or managed by CiviCRM, to which CiviCRM may apply a portion of its general budget. Financial and legal oversight are provided by the entire Core Team, with responsibility and management ultimately falling onto CiviCRM LLC.
Inspiration
Our model for operation was inspired by several examples, most notably Ubuntu and Joomla.
