Teams and working groups

Over the past few months we've had a few requests for more clarity in on how the CiviCRM community is structured - how things are organized, lines of accountability, etc.  It's crucial that this stuff is well understood by everyone that uses and contributes to CiviCRM. It helps us stay productive, helps newcomers understand how they can get involved, and helps us to scale.

We realised that although we've done a fair amount of work recently on explaining how the core team works and how you can interact with us, we haven't spent much time bringing clarity to the wider community.  Our structure is often explained as 'the core team with a community of contributions. The lack of further definition of our community is telling, and its time to give it a bit of definition. It's time to say hello to teams and working groups.

There are a few 'interest groups' in our community already - they've sprung up organically over time. Some are large, some are small. Some are formal and others are informal.  Some are very active while others are more dormant. Some are working nicely but others feel a bit dysfunctional.  Formalizing these into Teams and working groups is an attempt to distil the best of what is happening already and apply that globally across our community.  We're not interested in dictating the internal structure of these groups or changing the way they work (if they are working).  We are interested in supporting the creation of structures that help people work effectively, and help us to scale the community, providing a clear way for people to take responsibility for certain parts of the project, and be accountable for them.

Here's a quick explanation of the new vocabulary. We've organized our community it into three broad teams:

• a development team
• a marketing team
• a community team

These three teams provide simple high structure that's easy for anyone to grasp.  They match fairly well to the different interests and skill sets of a lot of people that want to get involved in CiviCRM.  Each team is made up of a number of working groups made up of individuals focused on specific goals.  Many of these working groups that are already in existence (the security working group, the API working group, etc). Each work group should

• define a purpose
• identifying a lead
• listing the main ways it communicates internally
• make periodic updates on their work to the rest of the community

We think that the above requirements are easy to fulfill and provide a decent baseline for a group to be effective.

Of course, conjuring a working group into existence does not in itself result in any work being done. Hence we're going to need to avoid the temptation to create a long list of working groups on the assumption that this will spur others into action.  Instead, we'd like you to think about any ways in which you are currently collaborating with others around CiviCRM and see if it makes sense to create a working group to encapsulate this collaboration. This way, we hope, we'll build on what works, improving and refining this structure as we go.

And how does the core team fit into all of the above? you may we wondering. We envisage that many (though not all) of the working groups above will have core team representation. Some of the groups will have core team leads and some will be lead by others in the community. And as teams and working groups become embedded, we expect that more and more core team - community interaction will happen in the context of working groups.

Check out this early list of teams and working groups. You can expect the list to evolve and expand in the weeks and months to come as working groups come (and maybe go).  If you'd like to add a working group to our structure, make a suggestion in the community channel. It's early days for this new structure. Hence we're inviting you to get involved, and let us know how it works for you. As always, we're up for improving things based on the feedback of people that are involved as we go.

* the semantically disciplined amongst you may note that it is currently referred to as the API team, not the API working group. We're hoping that you'll make the leap with us and start referring to all structures under the three broad teams as working groups. So the API team becomes API working group, the security team becomes security working group, etc. We're sure that you will learn to love the new vocab and hope you will agree that bike-shedding on what we call these structures is not useful.