CiviCRM for BackdropCMS.org Planning Meeting Notes, 2021 04 13

Who: Jen, Jack, Morgan, Justin, Tim, Laryn
Github issue: https://github.com/backdrop-ops/backdropcms.org/issues/782

• Jen: limited civi, from 2010. Interested in leveraging for other projects. Interested in figuring out what we can do with it how it will benefit our org. Missing right now. Many options, curious about it.
• Tim: he/him interest has been in volunteer management; feel like tracking who’s expressed an interest in working on different things, if something comes up who should we contact, following up with volunteers we haven’t heard from for a while. We need a tool, we always talk about using Civi for it, have tried downloading and installing it into a copy of backdropcms.org locally. Event management is another use for it if we get it working, but for me priority is volunteer management. Working on my first Civi client project right now, beating my head against Civi problems at this very moment.
• Laryn: he/him, use Civi for clients and own organization, would love to see Backdrop use it for all the functional reasons but also for the bond between the projects; none of the other CMSes that Civi supports actually use Civi, there’s a certain level of goodwill that could be generated by Backdrop actually using it as an org, could be a big benefit to the Backdrop project to show we’re using it ourselves when D7 sites who are looking to update are looking for alternatives
• Morgan: she/her, been a Civi developer, client support, custom builds at Palante, been working with Civi for 4 years, CRMs my entire career. Excited for the opportunity to see if we can get this official usage of Civi with the Backdrop community; hopefully that will be a way to push Civi forward with its Backdrop integration. Palante probably quietly, behind the scenes have some of the most intense Backdrop and CiviCRM integrations going on, pretty cool stuff, we see lots of opportunities about it. Hoping to get a good team together to take it seriously as a project for Backdrop and see where we can go with it. There’s a Civi Mattermost that has a Backdrop-specific channel, you can ping that channel if there are Backdrop-specific-things, I get pings from there and can help with other sites.
• Jack: they/them, working with Civi for a long time. First in Drupal now in Backdrop. Some Civi documentation back in the day. Know a bit of implementation and user support, user end stuff. Think it’s a good fit for lots of stuff Backdrop wants to do. Similarly to Laryn excited about interaction between our projects, two open source spaces I’ve been in.
• Justin: Civi experience, installed and configured it from 2012-2020 and did a lot of data imports and some custom module development for events and mail systems. I was never really an end user, more bug fixes and development. Could potentially be a good fit. Saw strengths of it handling events, contacts, donations. Really helpful for the nonprofit org with a considerable budget. Volunteer wrangling was one of its strengths too. Hands-on experience with those things not too much.
• [Eric couldn’t make it but is also into working on this.]

• Morgan: want to talk about roles and timeline for getting Civi implemented, or not! A valid decision to not if it’s not a good fit, it’s a big responsibility. Want to get a sense of how people here see themselves participating; what you can bring to the table in terms of getting things set up, user training, establishing goals, everything like that. Where do you see yourself coming in when it comes to integrating CiviCRM into BackdropCMS.org?
• Jen: hold a lot of institutional knowledge about how Backdrop has done stuff in the past, our 18 different mailing lists, etc; can help figure out, of what Civi can do, what we should be moving into Civi. I could help with development and specific coding tasks. Want to do both of those things when needed.
• Tim: happy to let others deal with installation; I want to use it for Backdrop, have ideas about how I want to use it, here to talk about use cases, maybe help configure and set them up. Have my fingers in a few pies; it was brought up, we could use it on the events site, and that’s great we could, we have multiple places, but my priority is for volunteer stuff; we have short-term solutions for the event stuff.
• Tim: Another big issue is a lack of single-sign-on; potentially want to connect Civi to different sites, already struggling with people having different accounts on our different sites; we have to be aware of that need, not that we need to solve it now.
• Justin: I have no idea!
• Jen: I can volunteer Justin for server set up, beta site, initial roll-out of Civi; Justin is very good at helping with that.
• Justin: OK yeah! Server part, providing updates to it as new versions come out, help maintain it, do data imports if we need that, even some system integrations if we really need that, sending lists to MailChimp and things like that.
• Morgan: there’s multiple types of Civi tech folks who have made ourselves available, but community stuff like this always falls to the mid-bottom of the list; before COVID, I was 2 months behind on everything and it was manageable, and after COVID it’s never recovered, my list is a nightmare. I feel like there’s an excitement that I have about getting a team together, we’ll install it, have more hands on deck to help these other tech savvy folks use it; there’s also part of me that’s worried about the super-complication, having a ton of techies and developers on it. I’m available to help with install; I have a couple questions that I want to get into about what your maintenance schedule looks like now, because adding Civi—and also your dev workflow on your main site as well—because adding Civi into the mix will break shit, so I want to get out in front of that. So helping with install, but also some conversations about what’s the best data model to use for all your existing data; getting a good amount of buy-in to that from everyone who is going to use it. Doing a scan for who all at Backdrop is going to be using it, making sure that we’re having the right level of buy-in and clarity of how it’s going to be used. Situation where it could be a free-for-all, anyone with an account can do anything, but it’s probably best if within Backdrop you establish very clear delineation: who is in charge of what gets changed here software wise, workflow-wise, data-wise. That’s where my head is most of the time working with a variety of clients who use
• Jack: See self mostly in end user role. Able to do project management for this. As PMC member, keep issue assigned to myself for PM. Besides that, as an end user could help with brainstorming of how to set stuff up and help with use of it depending on how we set Civi up. Donations, mailings, event stuff. Fair amount of experience working with software. Maintenance-wise, want to be part of sticking around and making sure it’s maintained but don’t want to do updates.
• Jen: I do most of the Backdrop updates on BackdropCMS.org, I’ll usually roll out releases to the site in the same afternoon. The Civi release schedule won’t be built into my workflow already, but I think we could manage it, maybe not the day it comes out but within a reasonable amount of time.
• Morgan: update schedule — there are security updates, they aren’t very frequent; there’s also some benefits to automating a little. A bunch of different ways that updates could go; that’s something that the Civi implementation people can figure out after getting good feedback from y’all on where and how and who is running software
• Laryn: happy to do whatever’s helpful: installation, configuration of one or more components; also Eric is available to do updates, would work it into his workflow when he does updates for his clients.
• Morgan: Seems like we have some figuring out to do in terms of technical strategy as well as end-user strategy, so to speak. There’s the organizational side where we want full buy-in, contact people identified to make sure data gets into CiviCRM and isn’t broken, and then ramping up your use of it by configuring it in a way that makes sense, hiding things that no one needs to see; myself, Eric or Laryn could take a couple hours and set up all the settings as we would for any organization as a starting point. Then there’s the end-user process, which can be incredibly open-ended and a lot of work; it’ is never-ending. In my work with CRMs, I try to empower someone to take a hold if it, really own the decisions and the roadmap for how you’re using it. Starting with your volunteer base as Tim has mentioned is a good place to start; those data are contained somewhere, you have a discrete number of potential, current and ex-volunteers, can start with that as your contact base, feed in all the other data streams, get your heads around it.
• Morgan: a couple things we could talk about, then it would go back to a Zulip conversation, or a Github issue or a separate meeting to sort out the technical stuff, though we might be able to get to some of that today too.
• Morgan: Do you have a sense of who all at Backdrop would have admin privileges in Civi? Who would have the reins to make major decisions, as far as deleting data, adding data; we don’t know.
• Jen: Tim and myself. BWPanda – Peter – does mailing list. Gregory tends to ve an advocate for people in time zones not in the US. Don’t have any designated roles that would automatically match. Would be if someone volunteered to do a task requiring access.
• Morgan: that’s how CiviCRM.org the organization does it: rope in people who want to get something done, giving them privileges if trusted.
• Jack: I think it will take a bit of adjustment from how BackdropCMS.org. Anyone who has admin can go in and publish something. We can go in and make config changes without checking in. One thing in Backdrop but a whole other level in Civi. Tech feels complicated, harder to undo. Implications for data.
• Jen: personal info, more risk.
• Jack: Will take some different thinking re: roles. What do you do, not do, ask first. New for us.
• Tim: I want to endorse that. We aught to be thinking about that in other places too, but Civi is a place where having A Coordinator who is the point person who makes those decisions, would be good.
• Tim: I hope we can come up with a strategy, first step. In the past: hey, volunteer management! First step would have been a new installation of Backdrop just for CiviCRM and start adding data, but the blocker—some of you involved in earlier discussions—decided we have a lot of data in BackdropCMS.org, we want to work with that data or integrate with our existing site and our existing data. Takes it to another level of skill and time commitment to get it going. Hope we talk about that—is our goal to integrate with BackdropCMS.org, or to have a separate site?
• Morgan: that’s a good place to go next. What sort of data is on BackdropCMS.org? Webform submissions, users?
• Jen: users is the most important thing. Not sure how many users are real people, had a big influx of spam recently, but for real users, there’s a lot of data about each person: whether they are a contractor, available to be hired, different levels of involvement in the project; all those things could be leveraged in the CRM system. Don’t know if it needs to be tied to the main website, seemed like a good decision at the time, but if it creates an unnecessary level of risk, I’m open to other options. Our main website is our richest source of data.
• Morgan: if the data are already in your websites, adding Civi isn’t adding
• Jack: Would be a strong proponent for having it in the main site. That’s the hub, where most people create a backdrop-related account or form. Also in my experience organizations who had a website and separate civi site. it’s been a pain for them and they end up migrating it. Starting out with separate and then wishing it was integrated later.
• Jen: Another blocker before: once we do set up a new site, what do we do with it? Do we need to set it up correctly from the beginning, etc? Just that base level of understanding threw up a lot of hesitation, lack of confidence in how to start with Civi from the ground up. Was also worried we’d make a mess of things by setting things incorrectly from the beginning.
• Morgan: All very valid! Usually with clients, we tell them to set aside several weeks, a big chunk of time to figure all this out. But it’s not the end of the world; everyone’s CRM is a little bit mess up. There are ways to get the right people together, really grow a sense of understanding and empowerment with it; not to call you out Justin but I know a lot of people who have a bit of an antagonistic relationship to their CRM, it’s a pain in the ass and a lot of work! But also an equal number of people, working with the same software, where it’s a PITA but it’s also invaluable to have the info in this format
• Justin: I thought it was a good software package, so did the folks who were administrating it; it was key to the organization, in terms of having everythign centralized. Having just one admin isn’t the way forward, probably a technical admin or two, then different folks will be in charge by volunteerism of what section they take, e.g. volunteers, donations, events; broken down by how it will be used.
• Morgan: seems like we’ve got a pretty good team of Jen & Tim being the decision-makers as the end-users, the end-user stakeholders, Jack thrown in there too; keep it limited as far as who’s making decisions, so Jen & Tim = end-user stakeholders. Would like to get a better sense of technically who is calling the shots, who is doing udpates, who has routine access to the server, are you comfortable giving other folks access to the server to work with databases, who can make file permission changes and move stuff around on the live server. Being able to ID who the folks are who are available on the Backdrop technical side and for making technical decisions about the structure of the software.
• Jen: Jack, Tim and I all have access; we also have a devops group that has all people who have access to the server, we’d be happy to add Morgan onto that to be able to grab DBs. Wouldn’t want to open that up to too many people, but if we needed to add more people to get this done, that would be reasonable, we could also remove access later. As far as making decisions, it’s been kind of a group effort; in terms of how Civi should be set up, I don’t have any technical decisions, would defer to people who use it. For the server, Justin knows all that’s been done for our other sites, would have the most experience and expertise. If we’re all in the convo we can defer to Justin to make a technical call.
• Morgan: How does that usually work? Do you have a GitHub issue, do you do it in a Zulip chat?
• Jen: almost always a GitHub issue, we have a dedicated queue, don’t know if we need one for Civi separately but could use the backdropcms.org one; Justin’s good about creating tickets there for server updates; most of the major things we do on the website go through that channel anyway.
• Morgan: so that’s your main way of coordinating maintenance of the website? Sounds like a fine way to do it, anyone can jump on it or it can go to a designated Civi person who can tag folks in.
• Morgan: as far as timeline goes: I know I’ve been sitting on this for quite some time because 2020, but my sense is if we figure out the tech stuff in a way so that by installing it we’re not breaking the website, that we can do this without going through configuring a trial site and THEN trying to install into live; we can just go from dev site to live site. I had it set up on a test server at Palante, got it working pretty well; have gotten a setup that I’ll definitely run past Laryn and Eric as well as Jen as far as maintenance schedule, making sure that anyone copying a dev copy of the site down gets all the Civi assets you need, because if you don’t have them you get a broken website. There’s not a huge amount of technical work there, just a little bit of tech coordination. And then the fun planning stuff beings with the user role designation, data migration from Backdrop content into Civi, all sorts of fun stuff that is a bit of a TBD for timeline for me; we’re crunched at Palante for the rest of the year, but with other folks involved, we can get a end-user process establisehd early on, get a lot of brains into it, then pick tasks off until y’all feel like you’re rolling with it. A little loosey-goosey, many-hands-in-the-pot, but I feel like it’s workable because Backdrop folks are both motivated and technically skilled.
• Tim: One decision is dev enviornment wise. We don’t have dev versions of backdrop sites. We work locally and in our own space and create pull requests. That has been one thing making it hard to get civicrm going. Each of us working in our own space. It sounds like in this case you might just put it in Palante space, which is fine if that works for the process we have planned.
• Morgan: I was suggesting getting together and working on one PR that doesn’t break the live site; once it’s installed, you can just limit most people’s permissions to Civi so they don’t even notice it; the big hurdle is putting in the software and making sure the updates are run so that anyone else working can just pull that in and not have Civi be massively interfering with other website maintenance. Usually in our workflows we’ll set it up with the assumption that only one or two devs will be working on that with their own copies; it’s a different set of technical considerations here. It can totally be solved, just needs some coordination; will probably be a moment where there are different instructions for folks. Many different ways to accomplish it. That model of how we’d maintain a canonical dev site for a client, then running updates, that’s how I’d do it to stage the pull request to install for the first time, but once it’s merged in, we’d want to just make that PR so that everything is there, anyone can pull that and have a functional site with a database from the sample data you have.
• Jen: Goal is to decrease amount of time working on PR. Once that is merged and deployed by having one production.
• Morgan: not even that! Your workflow right now is really straightforward: you make PRs, they get merged in. I’m going to start—assuming that I’m the one who does this first — will start a separate branch with Civi in it, all the instructions for updating your local settings file etc when you’re trying to install a dev copy of the site. Will probably road test that, copy it back and forth btwn a couple of folks to make sure that branch is functional. Once all loose ends are tied, get that merged in, and then your current workflow will work.
• Jen: happy to dev-test that branch once it’s merged in.
• Jack: For the client, civi is installed. For drupal and backdrop updates there are a variety of ways to approach it. Easy for folks to get civi and set up locally if they need it, or just disable civi and not worry about it.
• Tim: I’m raising the concern about prior, during development: because we don’t have infra to set up a dev site, my impulse has been to just set it up on my infrastructure and work on it there until someone needs help, not easy to get it to him. It’s in the dev part that I’m concerned about workflow issues or where we keep it. If there’s a risk that we’re going to need to get started, then bring someone else into help, then that becomes a blocker. If you really have the time to work on this then you should work as you are comfortable.
• Morgan: my approach…there are ways, thinking through it, there’s a lot of questions about how to merge Civi, which is funky and weird, into a workflow that’s very collaborative and open. Starting a branch with some starter files, then passing it around to figure out the best way to have this software installed, available, have all the assets & extensions available and committed, and have a DB load in whatever environment so it’s not broken: it’s not that complicated, but I want to be mindful of futureproofing it, rather than just installing it the one time, walking away, and having it break something the next time anyone wants to touch it. Don’t think there’s an effective different btwn installing.
• Tim: really want to walk away: sounds like do want this as part of the official backdropcms.org installation. Then my concern — people right away said, let’s use this for events — what that means is we have to either move events here OR integrate with both. Would like to have some sense of that as quickly as possible. One option: focus on donations and volunteer management through Civi, that’s an option, but don’t want the events work to freeze because we’re not sure if it will be coordinated with Civi.
• Jack: Like not duplicating data, if we have events.backdrop with contact info we’ll have info there and separately info on the main site in Civi. Would want to avoid that. Seems that events was set up because we needed events-specific stuff and would have been a lot to make main site do all that. Didn’t want to worry abou thow it fits. This feels like an opporutnity to get it fitting. What decisions do we have to make about the separate site, encourage keeping separate site how it is for now until we make headway in civi. With the probable goal of moving stuff into civi.
• Jen: my only experience with Civi is around events, used it for DrupalCon 2010. Thought the way we handled it then—events stuff happened on events website, user registration was the only thing that happened in the main website. You created sessions, bofs, all of that was unrelated to Civi. Back then we used the Bakery module to share cookies across sites, etc, but that also solves the single-sign-on problem. If we can leverage whatever Civi does now, that would be great, keep content separate, keep user data shared. Might take some custom integration stuff for Backdrop. In terms of concern about…wouldn’t want work to stop on events, docs, etc just because we haven’t figured out our user data source.
• Morgan: that’s workable. If it’s a question of moving data into Civi that’s somewhere else, we’ll need to tackle that anyway; leaving that live on the dev site for now as is, using the event site for conference-type stuff that wouldn’t naturally be shoved into Civi; one client stores most of their conference-related data in their Civi and it’s irrelevant to 90% of their day to day. Let’s figure out what you want the integration to look like; it does seem like, with all the different web properties, getting shared user/single-sign-on and the site with Civi in it is the main point for that, updating Civi whenver that user does something of note on the other side of things. Sounds like a good end goal in mind — consolidate, push updates out to people’s user accounts, etc.

NEXT STEPS:

• Morgan: make an issue, or keep going on the ongoing one, that will go along with this PR to get it installed; make sure that folks have the branch to test out; have convo about strategy on the technical side. In parallel to that, get some very basic user stories strategy lined up, figure out who wants to lead different convos about that so when it’s installed, people know how to configure it, what different components are needed. Two convo streams — technical side, I can start down that road, push what I was working on before into a branch. I can do that by the end of the month. Could push a crappier version sooner! Jack can start the other thread moving, make sure we have everyone who needs to be involved. Let’s keep it tight, especially with some ambiguity about who can make major decisions, though my sense is that we got pretty much everyone.
• Tim: biggest concern I have - one of the first steps is configuring what fields we’re using, etc. Part of what I don’t understand-I’d be comfortable setting up a fresh Civi installation and making decisions about that, but we have this component about bringing in existing data. I have no idea what it’s going to look like when we do it. Can we wait until that’s installed on the live site, or do we need to test out that config first? From heads shaking, I’m reassured that we don’t need to make a bunch of decisions before the development process.
• Morgan: if there’s data in the CMS, it’s there, it would be easy to get it in. Mapping data in Backdrop over to the CRM, that can come…convo about “how are we going to use this” are going to dictate a lot of it. It’s a fair point, I’ll make sure to be aware of that; wasn’t on the look out for a whole amount of user data in the Backdrop site, I’ll give a scan about what fields are there, if any of that informs our convos.
• Tim: may well be less usable info there than what we think. Might not be integrating that much data
• Jack: Imagine that will be on the convo stream about how are we going to use this. If I’m taking on a PM i’ll start a new issue for the technical side and a separate issue for coordinating a brainstorm session to figure out how we want to use civi, what components we want, etc. This crowd plus eric and maybe a couple others are interested in Civi, outreach, that kind of thing. The conversations could be open, if we have Tim+Jen as end user plus Civi-heads who know db stucture we’ll be able to sort it out. As far as data ew have now I cna see a process for evaluating that.
• Morgan: we have pretty clear next steps! We can wrap, follow up on everything in the issue queue.
• Tim: restate and clarify the events part—understanding is that, for now, we keep a separate site for functionality around events, but we try to keep the data flowing into CiviCRM on the main
• Morgan: seems like there is some deeper stuff there that’s not Civi functionality, a total Backdrop decision whether or not that content belongs on the main site or needs to be sequested. If you have a conference site that’s providing functionality that Civi cannot easily provide…it sounded like the task is making sure that data isn’t lost, there isn’t data about your people that’s sitting by itself, that’s the problem to solve. The question of merging the two sites is a question beyond Civi. If it’s a data capture question, we can solve that. The other content stuff is a different choice.
• Tim: Luke is also interested! More as an end user
• Jack: Let’s loop him in for the end user convos!

JACK DONE: get notes into a gist/doc on github, link to notes from the issue

JACK DONE: start new issues for the tech and end-user convos discussed above