Notes from 2019 Summit

The following are notes taken in real time during the 2019 Community Summit in Barcelona. Several people participated in taking these, however Josh Gowans acted as secretary for day 1 and Erik Hommel did likewise on day 2. Original notes were taken via a Google Doc.

Day 1

1. Logistics overview by Alejandro and Luciano.
2. Opening remarks by Joe Murray celebrating our history, our diversity and our growth through the years.
3. Group introductions.

During the agenda review and summary, the group discussed the difference between the New Jersey summit and this summit. In many respects, this is a “reset” in order to identify who we are and where we want to go before prescribing a specific outcome to get there. This is in contrast to the New Jersey summit where there was an underlying agenda to establish a control process over the project.

The 2019 community summit will use ‘Planning For Real’ strategy to identify what we can do in the near, medium and long term to ‘make CiviCRM better’. This strategy consists of identifying issues and opportunities, organizing them into specific themes, and then applying a timeline as to when they could be done (near, medium and long term).

Erik Hommel led off the morning session with an effort to identify who we are (and are not) and what our principles are (or should be). Defining who we are is more than a mission statement or vision statement. It’s defining our identity, our principles, and clarifying who we want to be today and in the future.

Who We Are Not

The group broke into smaller groups to focus specifically on who we are not. Results include (not in specific order, several items were repeated across groups):

• We are not centrally controlled
• We are not homogenous or mono-cultural
• We’re not lacking in principles
• We’re not an exclusive community
• We’re not just a product
• We are not definable
• We’re not always good communicators
• We’re not Salesforce
• We’re not just in it for the money
• We’re not in control of the resources
• We’re not a Saas
• We’re not based on planning and control
• We are not well known because we don’t do marketing
• We’re not just takers
• We’re not a company
• We’re not monetizing user data
• We’re not fast
• We’re not a closed community
• We’re not proprietary
• We’re not greedy
• We’re not broken
• We’re not stagnant
• We’re not negative
• We’re not as diverse as we could be
• We’re not conventional
• We’re not in a fixed state, we can go where we want
• We’re not here to get filthy rich
• We’re not an organization
• We’re not apolitical
• We’re not good at marketing
• We’re not enterprise, but not “dollar hosting”
• We’re not a charity giving away something for free
• We’re not all the same
• We’re not efficient
• We’re not one specific software purpose
• We’re not nimble
• We’re not easy

Who We Are (personal stories)

Attendees voluntarily presented stories about CiviCRM and their involvement in the project. Stories mostly focused on what has driven people to be a part of and support the community, as well as why they believe in CiviCRM and its purpose to do social good. Some also presented challenges and provided feedback on difficulties in the market and the community. The net result was a heightened sense of appreciation for why we do what we do as a community and a deeper sense of camaraderie.

Our guiding principles

Attendees broke into several groups and were tasked with considering CiviCRM’s guiding principles. As a basis point, groups were asked to start with the core principles documented by the establishment committee. In addition to the specific points below, nearly all groups indicated that the defined principles were mostly good, albeit long-winded and in need of simplification. In particular, the final principle, that being “CiviCRM is targeted at non-profits and social good.”, should be simplified to “CiviCRM exists to do good” and should be stated first.

Individual group principles:

Orange Team

• Should be concise / clear / simple
• Open and transparent
• Inviting, welcoming, accessible
• Actively inclusive and diverse
• Focused on social collective good
  • Eco-sustainability
  • Peace? Social justice?
  • Where / do we draw the line
• Definition of community is unlimited
• Movement not based on CiviCRM
• Data security and data autonomy

Blue Team

• Mission orientated vs profit orientated
• Could be more concise
• Not explicitly ordered but social good item should be at top
• “Every non-profit should have affordable access to a world-class CRM”
• Friendly welcoming community
• As much a community as a software
• Free software, democracy, control
• Inclusive community, address barriers to participation
• Promote community ethos

Green Team

• Long sentences are good with Germans and Ukranians, but these could be shorter
• Some terms are missing
  • Community - include clients: Most successful projects are those where client becomes active community member
  • Privacy
  • Choice
    • lots of choices in CiviCRM - whether to use this or competing, service provider to use, extension selection
    • Should preserve freedom to choose
• Diversity
  • Identify lack of diversity in community
• Participatory
• Democratic decision-making

Brown Team

• Some principle around community engagement re sustainability
• CiviCRM is open source product & project and free and is owned by a community. Members of the community contribute and fund the project and are responsible for its sustainability.
• CiviCRM community is focused on doing good.
• Principles should instill security.

White Team

• Open source should be a principle.
• We are producing software that enables organisations. (Versus “not a product” responses in “What is CiviCRM Not” questions earlier.
• “Expect” is not the right word to get people involved in the community.
• Don’t care about org structure / legal entity of orgs, remove “non-profit” from final point.
• Question democracy as a core principle & background / reasons for including that point.
• Add do-ocracy as a principle, permit meritocratic / technocratic decisions. Not just voting.

Erik wrapped up the exercise and, after lunch, presented a summary of “Reinventing Organizations”, a book dedicated to introducing new ways to operate and collaborate within a company and/or community.

Core Team Report

Josh presented the financial status of the Core Team as can be seen on http://stats.civicrm.org/?tab=financials. Bottom line is that the Core Team financials are OK and as long as everyone is happy with the way things are running we are fine. But if significant changes are required they will have financial consequences. The Core Team is now on full pay again.

Establishment Committee Report

Alice and Erik provided an update and led a discussion on the work, challenges and results of the establishment committee. The purpose of this session was not to report on the specific details of the document, but rather to talk about the process and the expectations going forward. Points include:

• There’s a feeling that the summit in New Jersey wasn’t representative of the community and that its mandate was very challenging to achieve, especially within a 6 week time frame. In general, the term ‘governance’ has lost some of its meaning and, in Alice Aguilar’s words, is not the right word to use to reflect the work of the establishment committee or that of the recommended elected body.
• There was no universal agreement on the committee on all points, however the debate and discussions were good. The committee wanted to put something out there, even though they didn’t come to a lot of agreements.
• The committee focused heavily on what it perceived as CiviCRM’s guiding principles, and ultimately arrived at having home sort of elected body that adequately represents the community. What it specifically does remained up for debate, however there was a shift away from thinking of it as a “governing body”.

Guy Iaccarino provided a recent history of CiviCRM, his efforts around promoting governance as well as why the governance summit came about. His main point about the objective of the summit was asked as “how do we get more people to the table to do more of the work in order to grow and have more impact?”

One result of the establishment committee’s work is this summit, i.e. we needed to revisit ‘who we are’ and ‘who we want to be’ prior to implementing a ‘governance’ structure. Joe spoke about some of the community conflict around core team decision making and influencing project-wide decisions.

Jamie McClelland highlighted how tensions in the community go up and down based on the health of the project, not because the tensions are resolved. Since the summit in 2018, tensions have gone down but, by and large, the health of the project has continued to improve.

There was a lot of discussion on what the role of the elected body. As a community, we’d like an elected body to work with the community to determine how to grow our impact without compromising our culture of do-acracy. Attendees repeated several times that a primary role of the body is conflict management. In addition to helping coordinate and communicate the community’s priorities and needs, and the body should be tasked with managing the community’s responses/reactions (toxicity).

A final discussion point revolved around why the body needed to be elected. Mikey O’Toole spoke about the success of the documentation effort and how its continued to move forward without governance and guidance. “It’s a matter of allowing people to do what they are passionate about.”

In lieu of an elected body, should there be a community consultation working group? Does it need to be elected? Points favoring an elected body include:

• The idea of elections is to help foster accountability.
• The role of the elected committee is not to control or manage the core team.
• Elections are a way to invest power into people that may not otherwise naturally assume power.
• Elections provide legitimacy in the eyes of the community.

Planning For Real

Olly Gibson led a process called “Planning for Real”, the intended result of which is to develop short term actions that we can do today (or over the very short term), medium term actions that we can document for future sprints, initiatives, etc., and long term objectives that help guide us.

The process started with documenting items that individuals felt would “make CiviCRM better” on to post it notes, and then grouping them based on themes. Individuals then volunteered to work on each theme and to prioritize the various items therein.

Short term action items are documented here and have been added as tasks in Gitlab. Medium and longer term items are listed here.

Day 2

Planning For Real

1. Discussing the grouping of the issues in Dev Process, Community, Extensions, Marketing + Communications, Core Development, User Interface + Experience, Architecture.
2. Each team of 6 coming up with solutions for the post-its in 60 minutes. Solutions should be practical, detailed and and split in short-term, medium-term and long-term. Groups can note that they think a post-it is not feasible, then document why and put it to the side.
3. Hopefully we can do all the short-terms during the sprint, we will discuss what to do with medium and long turn

Discussion in groups took place.

In document:

• Names, emails, @handles below section
• Continue discussion & write up as needed

Next steps:

• At start of sprint we review short term actions & allocate if appropriate
• A sprint task is to review medium & long term tasks
• Will look at turning this into a roadmap

In between: Michael McAndrew talks about sprint planning. Joe Murray suggests on first morning if people have clear ideas of what they want to work on they present so others can potentially join. Throughout the sprint there will be lightning talks and workshops/presentations. We will be balancing between getting things done and sharing knowledge/workshops/learning how to do stuff. Jaap suggest there is a group for newbies to have a somewhat longer workshop on development, training etc.

Report back from the groups:

Joe on Architecture:

Hard topic into something that can be done in a sprint. One short term action: add 1 unit test as you add them 1 by 1.

Mikey on Dev Process:

Quite a wide topic. Lots of discussion of how we deal with PR’s, we need to come up with guidance and guidelines. Short term actions: There is a developer training wiki, will be turned into a docs book during the sprint

Nic on UI/UX:

Lots of post-its, what can we do with the front-end - back-end, lots of things we can do in the sprint.

Marco on Community:

We dropped a lot of tickets to marketing, thanks for taking them! Short term actions: mostly documentation stuff or make people aware of where to find stuff. We put a lot of stuff into long-term where we were not clear on what was meant.

Patrick on Core Development:

Common theme was LEXIM. Lot of tickets about getting rid of stuff and moving them to extensions. For example get rid of Flash stuff. A few improvements to guide people into doing more documentation like add mkdocs automatically with civix. Also some tickets we did not understand.

Björn on Extensions:

Some stuff was really easy. Like Shoreditch should be approved, is done. Lots of tickets about process and documentation. Some of us are going to do some prototyping during the sprint. Also lots feature requests, all in there but will not happen tomorrow.

Detlev on Marketing:

Main thing was core website which has a number of issues. We have no SEO -> short term action. We need to add the privacy/secure/autonomy stuff to our website, this can be added. Detlev will do this. We did not complete the list, as a group we will meet again today to go through the list and see if we can complete it for short term actions.

Establishment Committee - next steps

• Alice spoke about what governance means and how the term is loaded and perhaps not should be used with respect to the establishment community. What we’re trying to do is develop a way to manage ourselves as a community and how we move forward.
• A challenge within our community is that most of our communication is digital, which de-emphasizes the non-verbal aspects of communication.
• The remit from the NJ summit stemmed from conflict. Our remit from this year’s summit is more positive and more focus on what we can do to grow and to improve.
• The remit of the elected body is to study and recommend a few methods of how to move the community forward and to address conflict management.
• A large part of the reason why we’re here is to address conflict management both on a person to person level as well as at the larger community level.
• Aidan provided an update on how the election process will take place.
• Guy raised the point about defining what the community council is trying to solve and how that will affect who runs and is elective. Part of the role of the community council is to help define these priorities.
• The group discussed the role of and reasons behind the elected committee and what its mandate should be.

Sustainability

• Financially the core team is stable, however its small and under resourced. If we’re ok with this, then we can continue. If, however, we want to change and try things, then we as a community need to figure out how that impacts sustainability both financially as well as from a resource perspective.
• The CT is now again being paid for the hours they work. Could we squeeze more out of them? A little bit but not a lot. We could potentially get 25% more out of Tim, Coleman is full time. If we want to increase the speed of delivering Form Builder we will need more money.
• Sergey: we should invest more in advertising and resources. Olly: can we fund someone “less senior” to take stuff over from Tim which would free him up more. Josh: we need more money then. Olly: increase partner fees by 10% (hear hear from Joe, Detlev and Erik) Roshani: we have to make sure that we make it prettier but we also need to make sure that partners are actually available to help new customers otherwise it makes no sense
• Detlev: at the moment we are not ugly enough but we need to do stuff now to make sure we are not too ugly in a few years. We need to invest in a bigger community because we need the additional hands to do all of the work if we do get 1000 more customers.
• Björn/William: marketing should be done by partners. Mikey: split responsibility, we have to make sure that regionally our stuff is under control
• Erik/Joe/Parvez: we do a lot of marketing according to the pull mechanism
• Roshani: should we then not do more marketing to developers
• Tim: I am trying to understand the tension between we want more marketing but we can not handle more work
• Joe: I want the community to do better at removing technical debt etc. so I want to grow the community. If we have more developers we can move quicker.
• Jaap: Mikey said we should be in markets: we assume we are one, we are not. We are a random community. So where does the ‘we’ fit in? Mikey: the we is the brand, the CiviCRM logo. Our common mission is to ensure that everyone hears about CiviCRM.
• Eileen: WMF has a mission statement that says that the sum of all human knowledge should be available to everyone in the world. Should we have a statement like that?
• Bruce: so we want to create more competitors? That sounds weird. But we need to have this standard branding.
• Sergiy: it is about branding, for example: how are we going to introduce the brand into Africa?
• Joe: I have tried Africa but I felt really bad about my rate. We need to find local people who can help them locally.
• Francesco: I am new but it is very difficult to imagine brand marketing around CiviCRM globally. The countries are different. Real marketing like advertising et. needs to be done in the countries and by the partners. Also it would have to focus on market areas like fundraising for example. Also all around the world what we could imagine is something like comparative marketing. Perhaps we can spend money/time//resources to set up free prototypes in new countries.
• Alejandro: some time ago we had a marketing team and we hired an agency. We did a booth kit and we had some central stuff. My lessons learned: this has to be done regionally. Make concrete small actions. Is there someone who wants to take the lead in this marketing group?
• Nic: would it be an idea to say this is our budget and ask folks for suggestions what do we want to do with it.
• Alejandro: I like the concrete actions and a group that can start doing things.
• Guy: good ideas. If you follow the thread about the logo…...someone does something and then gets lots of feedback. We should learn to just let someone do something and then accept that they take a decision.

Paid extension ecosystem

• Matt: we do not want it like Worpress. Some of the extensions just need to work and we need to come up with support so that they do work. Some of the extensions need to work but do not immediately stop the process so the customers might not want to pay for that immediately. So where does that money come from? So could there be a generic way in which customers know they can get support?
• Seamus: so how do we declare that an extension is still maintainable?
• Mikey: we need a mechanism to say that an extension is a security risk and we are not going to fix it.
• Parvez: being able to contribute to maintaining an extension. Mosaico as an example: it has the capability to make a lot of money. We are not exploring this revenue stream. This could all go to core. But also us: we do not want to manage our extension, we want it maintained by the community. I think it should be one rule for all.
• Joe: did you figure out some of the hows of the finance? I do not like the idea of everything going to core because it takes the responsibility/moral obligation away from the developer. I do not want the effect of people giving up on their extensions.
• Sergiy: I like the idea, I would like to pay to know that it works and is certified.
• Jamie: PTP has a different motivation. Our ambition is to support orgs in the states. So if you ask us to maintain an extension it is not where our aim is. Nor do we want money, we would rather not have money but just do it as our contribution to the community.
• Bgm: as a service provider sometimes doing support we sometimes fix extensions Are you Matt trying to find a better system for non-profits to pay for bug fixes?
• Parvez: the conversation is moving towards paid support, I think I was thinking about donating to support
• Mikey: I hate the word paid extension, I get the Wordpress experience. It is the worst kind of messaging. What we are discussing here is different and feels OK. But we do not do code reviews or security reviews. So we first need to solve some fundamental problems with our extension system. We can not yet think of paid extensions if we do not first improve our extension system.
• Parvez: can we make this an opportunity to make some of that happen?
• Rebecca: if we make it payable you increase the expectation.
• Guy: we need to be clear about the problem we are trying to fix. We want people to put quality software into the system whilst knowing they can get some money to maintain it. The idea then was to have different levels of publishing extensions: if on the UI there has to be a review and if just on Gitlab: use at your own risk.
• Olly: request of paid support, I have no idea what that means. It implies that people can pay now and then someone leaves the community?
• Tim: we are trying to lower the bar for a user to get support. So perhaps we can just communicate better what the support is. This could be that a single developer is willing to accept payment to support, some which are social things where groups are happy to support and some just want to share what they have done.
• Mikey: I like the idea of telling the user what the support is
• Björn: what do we actually mean with support? Is it just security patches or is it bug fixing, is it making sure it works with the new version? That to me is confusing in combination with 4 different support levels. I quite like the just send me an email because I know what is going on. Instead of creating this elaborate process just explain what the model is and who can I contact to get it fixed?
• Michael: a minimal stability level, so if a person willingly chooses the wild wild west it is fine.
• Eileen: it is a high overhead to ask the core team to do this - ie charging money for small but often vague pieces of work is likely going to incur a lot of admin. At the moment key extensions are not controlled by the core. Shoreditch is an example where Compucorp wants to remain control. If core / the product maintenance team has ultimate responsibility for maintaining an extension it must have the control to do so and that responsibility is implied if support is offered / administered via core.
• Jaap: Civirules as an example: we want to share it. We want to take on some responsibility but not all of that. At the same time we feel proud enough to keep maintaining it but we accept PR’s a lot. We as CiviCooP fund a week each year to fix stuff in CiviRules. We are happy to share but we do not want to take the responsibility.
• Joe: I’d like to come back on a future day and continue to conversation. First: it is unclear what kind of support they are agreeing to. I like the idea of the CT making some money out of this somehow but I want to figure out where the responsibility lies. I’d like to continue the conversation.
• Olly: could a couple of people write up what has been discussed and what should happen? Guy, Matt to discuss further tomorrow.

And, it's a wrap!

Thanks to everyone for coming, to our sponsors, and to everyone that makes CiviCRM possible. The feeling from this summit is positive and forward looking, and the atmosphere has been very good. Olly put out a request for feedback about what worked for this summit and responses were very positive.