CiviCRM for BackdropCMS.org Planning Meeting Notes, 2021 08 27

Participants: Jack Aponte, Jen Lampton, Tim Erickson

TECH SIDE:

• Confusion about whether the PR was ready to go live or needed to be tested first; Justin was wondering about a beta or dev site or server; went to a more general workflow question. Answer to the question was probably "yes" but unsure what's happening. Can you start on production first?
• For putting it into production, only care whether it breaks anything else
• JACK DONE: ask Morgan about whether we've got a test site, that we know that it will not break something else when Civi goes live on production. Get logins so folks can kick the Backdrop tires
• Justin could probably take over more of the technical end of things; we don't know things like what Civi add-ons we need to use, what needs to connect. Laryn, Herb, other folks can take that over. Could start with a general call, see if people have experience. Maybe Eric? Tim also gradually learning.
• Probably move forward now with Justin just to get the Civi instance launched on backdropcms.org
• Ultimately do want to have a dev environment that's accessible to Backdrop community. It's the larger question of BackdropCMS.org test site

CAPACITY:

• Jack: Do we have capacity to focus on Civi for Backdrop?
• Even if we just have a basic install, track data we can use later, will still be beneficial. If it's there and some of us can use it, we can build on that.
• Capacity = definitely an issue! But improving.
• Yes, let's continue to get Civi installed on BackdropCMS.org.

TO DOs FROM LAST MEETING;

• DONE: Share these notes with tech team, figure out implementation steps - This is done.
• DONE: Put this on an Outreach meeting agenda (Sept 16)
• DONE: Set up a policy decisions meeting
• JACK DONE: Show and tell of an existing Civi setup, to see what it can do (possibly in same meeting as above) (SCHEDULE THIS!)

OUTREACH MEETING

• Have a focus/agenda item in an upcoming Outreach meeting, September 16
• TIM DONE: get that on the agenda, will tweet it out, mention in Zulip

POLICY DECISIONS WE NEED TO MAKE:

Who is using our CiviCRM? Who can access what?

• We can create a role within the Backdrop community for access to Civi; can create a group and give access.
• Civi will mostly use Backdrop roles and permissions, could also use Civi ACLs
• Want to do more focused volunteer management in the Backdrop community; those folks would need this access, could be a working group or committee handling volunteer management.
• We don't have an outreach committee; we have an outreach meeting. Becomes a meeting of ideas rather than working through action. Capacity limitations have made it hard to move beyond that. Would lean towards a new group, despite challenge of maintaining existing groups.
• Most of Backdrop work is done casually, not organized, whenever free, rather than roles, actions, that kind of structure. That's in a perfect world; right now it's just as people have time and remember.
• Community Management Committee? (includes volunteers plus others who engage in community, e.g. events) given access to CiviCRM?
• Committee = defined group of people who meet on a regular basis; not just anyone showing up. Feels like it could be problematic in an open source community, the word "committee" specifically?
• Non-open meetings? Separately scheduling smaller committee meetings?

Who is changing things in Civi? Making decisions about those changes? Keeping track of what we're doing so we're not working at cross-purposes?

• This is about who is changing how Civi is administered.
• Preference: only one person responsible for making the big changes, someone who is charged with having big picture understanding of the whole thing. As we grow -- one person overloaded, too much to deal -- can transfer that info and responsibility to others.
• Have more than one person have admin-level access; if you're an admin on the site anyway you might get access to Civi just to be able to help people.
• As we figure out what we're doing with Civi and how, document the roles associated. But start with less.
• CMC probably won't be very big; those people have access; one of those people should be responsible for making those config changes. Check with them or have them do it. One person centrally responsible. Do we need a role/title?
• Alternative is to implement a process; rely on process not an individual. The process should provide an opportunity for others to offer input, catch problems, before any config changes are made in CiviCRM.
• Compare that to what we're currently doing for BackdropCMS.org -- we're more in a person than a process configuration. In theory you submit a pull request...but end result is a person-focused approach, Jen primarily implements PRs. Therefore no one else pays attention to the process. How will we shift from that for this process-focused approach?
• TODO: when CMC forms, develop process for reviewing, approving and implementing CiviCRM configuration changes

What is okay to collect in CiviCRM? How do we decide that it's okay?

• Many of these questions need to be answered for backdropcms.org more generally. We might try to start small, answer these questions for Civi, then move out from there.

Jack DONE: Schedule next end-user meeting in September - finish policy conversation (what data do we or do we not collect in our Civi) and a show-and-tell of existing Civi installations to see what's possible.