Member Platform (Slack) Meeting on January 8, 2026 [#3570703]

0️⃣ Who is here today? Please post your Drupal.org username if you have one. We provide issue credit for those contributing to the meeting beyond this thread. Especially if this is your first meeting, please mention a club, association, meetup group, non-profit or other membership organization (MO) you think could benefit from this initiative and/or tell us why you’re joining us.

Scott Wolpow	ScottWolpow
beautifulmind	beautifulmind
paulmckibben	paulmckibben
JBWeb	JBweb
jdleonard	JD Leonard (jdleonard)
James Shields	lostcarpark
bsnodgrass (he/him)	Bob Snodgrass (bsnodgrass) Coming in late today
richgerdes	richgerdes
Eric (sikofitt)	Eric (sikofitt) Coming in very late today. 🙂
svendecabooter	svendecabooter

1️⃣ Do you have any topics to propose for the meeting today? Open your own thread in the next numeric order or reply to this thread and I'll do it. (edited)

JBWeb	Working Groups for Member PlatformAre there any? I am trying to work out where I can contribute but it isn't clear what working groups there are and how to get involved
James Shields	Not really a meeting topic, more of a personal news item.About a decade ago, I started a project called ConReg, which is for member registration of science fiction conventions.When I started it, I knew nothing™, and did a lot of bad stuff like writing to database tables directly.I also created it on GitHub, because I had no idea how to create Drupal projects.Over the last few months I've been working on adding automated testing to it. However, that meant that I either had to build my own pipelines on GitHub, or migrate to d.o where I could use the already existing pipeline and testing infrastructure. The latter seemed the easier approach.Over the holiday I created a d.o project and migrated it in, and have been working on tidying things up.My very rough roadmap is:Version 1.x: keep the existing data structures, tidy things up and correct my worst sins, and build up test coverage.Version 2.x: restructure storage using entities (hopefully starting in a month or so). Prepare data structure forVersion 3.x: (After stable release of Member Platform). Try to replace as much of the module's own storage with CRM/Member Platform entities. If possible, use Entity Registration with customisation.My thinking is ConReg will become a layer over Member Platform, trying to keep as much standard as possible, but handling any convention specific stuff.
James Shields	If anyone is interested, the d.o project is here: https://www.drupal.org/project/conreg
jdleonard	@James Shields That's great James! What's your best case timeline?
James Shields	I'd like to be a good way along with V2 by the time Member Platform has a stable release.
Scott Wolpow	@James Shields Well needed. All the con reg systems really suck. If you want I can assist with feature needs. Then I may be able to convince a few cons to use it.
James Shields	Also, something I find very cool. I've had more contribution to the project from other people in a week of it being on d.o than in a decade on GitHiub (though that's certainly in part due to me not knowing how to set it up in a way that would encourage contribution).

2️⃣ Meeting cadence / CRM vs. Member Platform. CRM is a critical component of Member Platform but is more general purpose. Our meetings sometimes end of focusing on CRM things that aren't especially relevant to Member Platform. Should we have meetings dedicated to CRM and meetings dedicated to Member Platform? What cadence makes the most sense? Current cadence is weekly alternating between Slack and Zoom.

beautifulmind	We should not wait for CRM to roll out all the required features, rather we should proceed with what is available and gradually, release & include new feature as they become available. (edited)
Scott Wolpow	They are intertwined , bur MP is reliant on CRM
paulmckibben	I must admit, I have a lot of trouble making the zoom meetings. The slack meetings work much better for me.I like the idea of having the member platform meetings focus on our own specific features/requirements. For CRM features that aren't as applicable, reserve those for CRM meetings. (edited)
JBWeb	From a newcomer point of view you should have MP and CRM as independent meetings with perhaps an overlap meeting every so often. I got a bit confused when I saw CRM because I thought it was about MP but now I understand they are inter-reliant.
Eric (sikofitt)	I agree with the above. Maybe 2 meetings with a monthly or every 2 month combined?

3️⃣ CRM Beta imminent. Call for folks to install the latest from the 1.0.x branch (fresh, no upgrade path yet), test, and open issues. Post here or in #crm with any trouble getting it installed.

Scott Wolpow	So we will need to uninstall alpha? Will data be lost?
jdleonard	@Scott Wolpow There is no support for upgrading from an alpha release. We've always said that upgrades between versions will start to be supported once we hit beta stability.
Scott Wolpow	Will data be lost due to namespace changes?
jdleonard	You should start fresh to avoid such issues.
Scott Wolpow	Then I need to wait, because I need to add a lot of records
Dan	Good news. What about moving from last dev to beta?
jdleonard	You can try, but it's in no way supported.

4️⃣ Relationships that ship with CRM. Should CRM include Relationships as default content? If so, which ones?

jdleonard	Current relationships that ship as default content:EmploymentHead of HouseholdHousehold MemberMemberParentPartnerSiblingsSpouseSupervisorVolunteer
Steve Ayers	I thought you didn't want to talk about CRM in these meetings?:sweat_smile: (edited)
jdleonard	Merely posed the question 🙂
beautifulmind	The relationship should be like defining new content type/taxonomy/terms etc.
paulmckibben	Having not looked at CRM in a while, take my comments with a grain of salt...That said, simpler is better. For member platform, my needs (Drupal user group) are pretty simple. I don't anticipate needing to track all these relationships. So minimizing the defaults to the simplest set possible makes sense to me. Is it possible to install these defaults as recipes for those who need them?
Scott Wolpow	We should just build upon what comes with CRM, If CRM adds something we already have, we could figure that out.
jdleonard	My $0.02: Whereas the contact types, contact method types, and contact method detail types that ship with CRM are very general purpose, the relationships that ship with CRM are effectively examples and only some of them will make sense for a given site. The base CRM module should not ship examples as default content.However, @Steve Ayers made a reasonable case to me for including Household Member as it is the only obvious Relationship that would connect the Household Contact Type to anything.
paulmckibben	Again, for my needs in particular, even household doesn't really have value.
paulmckibben	I feel like that sort of thing should go into a recipe for particular use cases.
James Shields	Not sure I would use household for any of my associations either, though I'm not opposed to including a useful minimum that can be deleted if not required.
Scott Wolpow	I have a slight need for household, but I can see others needing it.
James Shields	Though I think my preferred approach would be to have almost nothing created by the base module, and supply recipes that provide different common sets of relationships, which might include, family, workplace, club, church, etc.
beautifulmind	Employment, volunteer are universal
beautifulmind	For the rest, let the admin decide about it.
jdleonard	Each site may have vastly different needs with respect to what relationships they need to track. While the defaults can be deleted by the site builder, we should offer a clean OOB experience.I do think there's value in some concrete examples. I like the idea of those living in recipes, which seem perfectly suited to the task.In the back of my mind, I know there's potential value in having some relationships (at least their machine names) standardized (well-known) so that modules in the ecosystem can behave intelligently. For example, a "Family Tree" module could know to look for Sibling, Parent, etc. Relationships and leverage them to render a family tree. I don't feel great about that standardization being in the form of default content in the base CRM module.
Scott Wolpow	I think the issue is CRM is the base of the contact info, while member platform is specific use of that. Designed for a membership driven data. As opposed to a corporate driven.I need to also use CRM as the base of a directory with profile claiming.There is crossover.Do we duplicate features based on needs with different purposes in different projects, or do we make a project with lots of 'addons'. ig Event, voting/polls, dues?
jdleonard	Agreed. Member Platform's requirements do not need to impose on CRM, which serves a broader audience. I don't think we're talking about duplicating features. Member Platform is an initiative, not necessarily "a module" (though it may include one). Requirements that can be generalized, should be pushed upstream as dependencies (e.g. CRM, Event, CRM Membership, etc.)
richgerdes	I think having some standard relationships is good. I would suggest we consider a "CRM Families" module (or recipe, i don't care which) which provides the required relationships and contact types for families. To that point, I think we need the idea of a Guardian (non parent that's responsible for a kid, if we're going to have family stuff).The most basic relationship would have to be "Member of" to link people to orgs (or orgs to orgs). And some sort of general way to "link" people to people with a text box for "how". I feel like any complexity with working at/for a company (employee, supervisor, etc) should really be is own module/recipes (as with above).Now.... since we're already including most of this in the module as is, I think its reasonable to leave it in for V1. We can make a change for V2. I would just add Guardian along side parent.
James Shields	Displaying a family tree has an awful lot in common with displaying a company org chart. I don't see any benefit in imposing fixed relationships on the display logic. If you build display logic that's fully configurable, you can use it to display whatever relationships you need. However, having a recipe that sets up everything to set up family relationships and a family tree view in a single click would be immensely valuable.
jdleonard	https://www.drupal.org/project/crm/issues/3566217

5️⃣ Event / Event Registration status. Anyone have updates to share?

6️⃣ Member Platform wireframes. We made some good progress during our last Zoom call. Seeking feedback! Anyone can add comments and click around the wireframes (via View -> Full Screen Presentation): https://balsamiq.cloud/s3eo7f9/ptwnsii/r7C36Here are the Mockup Notes we've been using to document some requirements for the various screens. Feedback requested!

jdleonard	Anyone who would like to contribute, please DM me your email address so I can invite you to our Balsamiq project.
Scott Wolpow	I have to devote time to that.

7️⃣ Working Groups for Member Platform

jdleonard	@JBWeb wrote:Are there any? I am trying to work out where I can contribute but it isn't clear what working groups there are and how to get involved(edited)
jdleonard	We don't exactly have working groups, but we sort of have some work streams:CRM (general)CRM EventsEvent (entity) registration support for CRM Contacts as registrantsSee issue 1653458 SpecMockups for the various pages Member Platform 1.0 needsSee Mockup notes for some requirements toward that endOverall functional spec for Member Platform 1.0Membership / CRM Member (not needed for MP 1.0)
jdleonard	@JBWeb If you let us know how you might like to get involved / contribute, we can help direct you!
jdleonard	More hands needed. If anyone would like to lead any element of the Member Platform initiative, please reach out!
JBWeb	I am thinking there could be people who would contribute ideas, designs, documentation etc if there were defined working groups. Not everyone is a coder but someone could be good at interface design and user management planning, roadmap management, tutorials and docs etc. I am new to your module so trying to find my feet and where I could be useful has not been straightforward. I am also aware this is a well managed project and I don't want to come in and step on toes etc. I just thought working groups would be easy for people to attach themselves to for their skill set
jdleonard	"Well managed" is questionable :rolling_on_the_floor_laughing:
JBWeb	:rolling_on_the_floor_laughing:
jdleonard	We need folks to step up to lead what they would like to lead!
jdleonard	For now what I've found most productive is having a 1:1 with anyone looking to find their place. Please reach out to schedule!

8️⃣ Code contributions to CRM. There are plenty of issues to choose from in the CRM issue queue!

9️⃣ CRM terminology. What should the config entities (of a type in need of better naming) "Billing", "Fax", "Home", "Main", "Mobile", "Other", and "Work" be called? Currently they're referred to as "Method details" or "Detail types", depending on where you look.

kathc	In CiviCRM they’re locations.
jdleonard	@kathc Thanks! In CiviCRM, are they used for Addresses, Telephone Numbers, and Email Addresses?
kathc	Yes - the defaults are: