CiviCRM for BackdropCMS.org Planning Meeting Notes, 2021 12 07

Participants: Jack, Robert, Tim, Jen, Eric

Agenda and Notes:

• Review current status of work, plan next steps (https://github.com/backdrop-ops/backdropcms.org/issues/789#issuecomment-928499011)
  • Submit PR including Civi - Jack is committing to submit PR by Friday 12/10. Probably based upon the release we tested, not necessarily the most recent.
  • Get that onto beta.backdropcms.org (https://github.com/backdrop-ops/backdropcms.org/issues/831), further testing there before merging PR - Jen will follow-up with Justin about getting the beta server working (ASAP). This MIGHT be possible this weekend, but we need to check with Justin. Jen is checking with Justin.
  • Establish strategy for sanitization of CiviCRM data (https://github.com/backdrop-ops/backdropcms.org/issues/828)
    • Jen: right now there's a basic script that replaces email address and password fields for users
    • Would prefer that people who are working on Civi need to request access to the DB unsanitized; so long as we trust the folks working on it
    • Eric: there are basic CiviCRM databases that people can install for their testing work; if we want to take it further, set up a system for one client using MaxDB, a proxy from the MariaDB team; has ability to alter data as it's queried. On dump, all the tables with personal data get altered in different ways. Could demo that to take it a step further.
    • Tim: Will the people who have access to CiviCRM data be the only people who can access other things on backdropcms.org? It seems like we might be fine until a point. Depending upon how we use CiviCRM it could become a problem for users to do local development without full access to the database, but this might not be a problem to start?
    • Discussion of how to manage access to development of BackdropCMS.org if folks outside of the Civi group want to work on it. It's not clear yet if that is a practical problem and we may have to deal with this as we go.
    • Our temporary solution is likely that anyone who works on CiviCRM for BackdropCMS.org will need to special request a dump, because we won't have a santized version available.
    • Who will have access to the database. Will the entire Community Management Committee have access. Not necessarily. We will probably identify a smaller group of people that have access and are available.
    • We can post an issue that lets people working with CiviCRM know who to ask for the database dump; we can also mention it in Zulip.
  • Other items on https://github.com/backdrop-ops/backdropcms.org/projects/3#card-59070173 needed before Civi goes live on b.org?
    • Jen and Robert both seem to think that we can proceed without fully addressing these other issues (#829 and #843). They can be dealt with later. We can delay creating CiviCRM records for now.
    • We will need to sort out the single name issue, but we don't need this working to launch.
• Finishing our policy discussions
• Civi show-and-tell? (If not now, when?)
• Scheduling next meeting

Jen volunteered to schedule a meeting (set up a Doodle) for early January. Our agenda will be shaped a bit by whether or not we have successfully installed. Then our next item will be to better define the composition and process of the committee.

Schedule:

• PR by Friday - Jack
• Update Beta site (hopefully this weekend) - Jen/Justin
• Testing within a few days - Robert/Tim/Others...

Finishing our Policy Discussions

Other policy questions:

• How up-to-date do we want to keep Civi? [TODO to discuss at next meeting!]
• What is our overall plan for updates and maintenance

Who is using our CiviCRM? Who can access what?

• We discussed establishing a Community Management Committee, a specific group of folks who meet on a regular basis to do community management outside of the open Outreach meetings, and that those folks would be granted access to CiviCRM. This plan needs more definition! See https://github.com/backdrop-ops/backdropcms.org/wiki/End-user-planning-for-CiviCRM-on-backdropcms.org,-Aug-27-2021#who-is-using-our-civicrm-who-can-access-what
  • Tim: need a committee like that; need something a bit structured, need a focused group that's going to continue to work on this on a regular basis.
  • Tim: want these to be action-oriented meetings, folks focused on getting specific tasks done, with agendas set by people doing the work.
  • Eric: need more definition on what these folks are going to do; that will inform how we implement access and permissions. Lots of subtle differences on how we can do it; would rather spend too much time planning and thinking than having to implement twice.
  • Tim: Emphasis seems to be on basic donor management and email lists; I'm really excited about volunteer management in the system. That will probably require some planning.
• Initial access policy is that anyone with admin role will have access to all the CiviCRM data, but that only members of the Community Management Committee should be making changes or working with CiviCRM. Once the site is live, we will work to better define membership of the community and their roles. We will eventually create a site role for those with CiviCRM privileges.
• In the future we'll create a new role on BackdropCMS.org to grant CiviCRM access and permissions to people on the CMC

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?

• Discussed two possibilities: an individual or group of individuals designated with deciding on and making big changes, or a process by which the community management committee would propose, review, approve and implement changes in our CiviCRM; settled on the latter.
• We discussed having a point person for decision making, but decided on having a strong process to manage decisions among the group.
• Robert: could we use the b.org Github issue queue for that? A good mechanism that exists, could add a new label to indicate Civi issues.
• The Community Management Committee will discuss issues in the BackdropCMS.org issue queue, but we expect decisions to be made at in person committees. We will leave many process decisions until our first meeting after CiviCRM is installed.

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

• Eric: we should only collect data that there's an explicit need for; our security profile is not very risky. Guide should be that there's an organizational need to have the data
• Jen: what's the difference between what we "need" and what's "nice-to-have" -- there's already info we're collecting for Backdrop users, we might as well have that data in Civi. We could use that data to send emails to the correct groups of people, e.g. based on country. Maybe start with everything we have on the user profile, we move it to Civi? Could also review those fields to make sure we're only requiring the fields we need.
• Eric: as long as there's a scenario where the info is useful, that's a need.