>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3516524. --> Reported by: [jdleonard](https://www.drupal.org/user/80902) >>> <p>Start of meeting on Slack: <a href="https://drupal.slack.com/archives/C07RLHPTSUR/p1743692413236159">https://drupal.slack.com/archives/C07RLHPTSUR/p1743692413236159</a></p> <h2>0&#65039;&#8419; Who is here today? Please post your Drupal.org username if you have one. We provide issue credit for those contributing to the meeting. Especially if this is your first meeting, please mention a non-profit or other membership organization (MO) you think could benefit from this initiative and/or tell us why you&rsquo;re joining us.</h2> <table> <tr> <td>bsnodgrass (he/him)</td> <td>Bob Snodgrass (bsnodgrass) here from St Charles IL. Sunny and crisp&nbsp; 46 degree day here</td> </tr> <tr> <td>aitala</td> <td>I&rsquo;m here (ish) - Eric Aitala (aitala) - I do web stuff for IPMS/USA</td> </tr> <tr> <td>Barbara Errickson</td> <td>Barbara Errickson here</td> </tr> <tr> <td>jdleonard</td> <td>JD Leonard (jdleonard) in Austin (76&deg;F, cloudy, humid, chance of thunderstorms). I&rsquo;ve been procrastinating writing up the use care for Zilker Neighborhood Association&hellip;</td> </tr> <tr> <td>mtift</td> <td>Matthew Tift (he/him), mtift, Lake Fellowship</td> </tr> <tr> <td>mr_scumbag(Lee Walker)</td> <td>Lee Walker (mr_scumbag)</td> </tr> <tr> <td>Barbara Errickson</td> <td>I support an HOA with 1080+ members</td> </tr> <tr> <td>Ashraf - DebugAcademy.com and Drupito.com</td> <td>hello :wave::skin-tone-3:Ashraf Abed (ashrafabed) from Northern Virginia (Centreville). I run a hosting platform that is designed for small orgs &amp; small sites, and I host &amp; maintain a site for a small member org non-profit</td> </tr> <tr> <td>Barbara Errickson</td> <td>User name is barbarae</td> </tr> <tr> <td>Barbara Errickson</td> <td>I implemented a Drupal + civicrm site that is running Drupal 10.4.6 with civicrm 6.0.3</td> </tr> <tr> <td>Barbara Errickson</td> <td>I&rsquo;ve done multiple sites using Drupal/ civicrm since 2008 - interested in a &ldquo;simple&rdquo; all Drupal solution.</td> </tr> <tr> <td>Andr&eacute; Angelantoni</td> <td>aangel representing BADCamp</td> </tr> <tr> <td>Barbara Errickson</td> <td>From Austin TX - in JD&rsquo;s group</td> </tr> <tr> <td>paulmckibben</td> <td>Paul McKibben - paulmckibben on d.o</td> </tr> <tr> <td>thejimbirch</td> <td>thejimbirch - here if I can help with any recipe related questions or issues.</td> </tr> <tr> <td>Esmeralda</td> <td>Esmoves Here</td> </tr> <tr> <td>Nico Grienauer</td> <td>Nico Grienauer (grienauer)</td> </tr> <tr> <td>freelock</td> <td>freelock here</td> </tr> <tr> <td>beautifulmind</td> <td>Bhavin Joshi (beautifulmind)</td> </tr> <tr> <td>James Shields</td> <td>Hi, sorry I'm late. I was looking for this yesterday, but it seems to have been later than I thought!</td> </tr> <tr> <td>James Shields</td> <td>James Shields (lostcarpark)</td> </tr> </table> <h2>1&#65039;&#8419; Want to receive an @ ping here on Slack when our Slack/Zoom meetings are starting (and you&rsquo;re not already)? React or reply to this thread to be added. DM me your email address to be added to meeting calendar invites.</h2> <table> <tr> <td>freelock</td> <td>please add me here :grin:</td> </tr> <tr> <td>James Shields</td> <td>Yes please!</td> </tr> </table> <h2>2&#65039;&#8419; Do you have any topics to propose for the meeting today? Feel free to propose them in this thread, and then I will give them their own unique threads for discussion. Conversation moving slow? Go ahead and open your own thread in the next numeric order.</h2> <table> </table> <h2>3&#65039;&#8419; Call for new volunteers to identify themselves and &ldquo;join the team&rdquo; at <a href="http://drupal.org/i/3508389">drupal.org/i/3508389</a> then reply to this thread to celebrate!</h2> <table> </table> <h2>4&#65039;&#8419; Call for organizations (e.g. DUGs and meetup groups) to identify themselves as possible early adopters of Member Platform 1.0: <a href="http://drupal.org/i/3514527">drupal.org/i/3514527</a> then reply to this thread to celebrate!</h2> <table> <tr> <td>bsnodgrass (he/him)</td> <td>Fox Valley Drupal might be an early adopter, it&rsquo;s still on our agenda to discuss</td> </tr> <tr> <td>paulmckibben</td> <td>Atlanta Drupal Users Group is interested!</td> </tr> <tr> <td>jdleonard</td> <td>@paulmckibben Please add Atlanta to the list in the issue!</td> </tr> <tr> <td>Robert Carr</td> <td>Drupal Scotland on the list already. Rest of Drupal Scotland Officers very supportive</td> </tr> </table> <h2>5&#65039;&#8419; Call for use cases / requirements from real organizations (the easiest way to contribute today!): <a href="http://drupal.org/i/3507591">drupal.org/i/3507591</a></h2> <table> <tr> <td>bsnodgrass (he/him)</td> <td>I have a meeting scheduled for later today with a client and another on Tuesday next week to discuss their use cases</td> </tr> <tr> <td>mr_scumbag(Lee Walker)</td> <td>I&rsquo;m currently trying to get the RFP from the local scout council. It may not be ready for a while.</td> </tr> <tr> <td>mr_scumbag(Lee Walker)</td> <td>I can meanwhile build what I know it will be from my scout master experience.</td> </tr> </table> <h2>6&#65039;&#8419; The big recipe / module / distribution / site template question.</h2> <table> <tr> <td>jdleonard</td> <td>So some of the big news coming out of DrupalCon Atlanta is the concept of &ldquo;site templates&rdquo;, which remains fairly undefined, but broadly sounds like a recipe + a theme + maybe more design stuff. That broadly fits with our direction and I don&rsquo;t think there&rsquo;s any consideration we need to give it at this time. Anyone else have thoughts on site templates?</td> </tr> <tr> <td>Ashraf - DebugAcademy.com and Drupito.com</td> <td>I think it may very well be a good-fit for this, but I don't think there's anything to discuss until the direction is finalized / more refined</td> </tr> <tr> <td>aitala</td> <td>And we&rsquo;ve been down this road a few times, only to have to turn back&hellip;</td> </tr> <tr> <td>bsnodgrass (he/him)</td> <td>I suppose we could weigh in on what we would need to make the member platform into a site template, but it would mean a delay for decisions to be made or us to dive into at least some experimentation&nbsp;(edited)</td> </tr> <tr> <td>bsnodgrass (he/him)</td> <td>@Ashraf - DebugAcademy.com and Drupito.com I assume you have been involved in a number of distributions in the past? Do you have a feel for where the technical details for a site template might go?</td> </tr> <tr> <td>jdleonard</td> <td>&ldquo;Are we building a recipe?&rdquo; I propose that the answer to this be &ldquo;Yes and&hellip;&rdquo;Based on many good discussions at DrupalCon, I&rsquo;ve been moderately convinced that key configuration (i.e. that which provides significant functionality for the platform) should live in and be maintained by any relevant modules (whether dependencies of the platform or created as part of the platform) so that we maintain smooth upgrades for a membership org (MO), which might not have a technical person available to troubleshoot etc.However, there are clear benefits to (and I haven&rsquo;t identified significant drawbacks of) creating recipes targeting specific types of target organizations that configure some settings and add some demo/base content. For example, we might (eventually) create one recipe for neighborhood associations / HoAs and one for DUGs / meetups.We&rsquo;d still need to iron out the model for an MO to modify config shipped by modules and retain upgradability.Thoughts?</td> </tr> <tr> <td>Ashraf - DebugAcademy.com and Drupito.com</td> <td>@bsnodgrass (he/him) I think the site template discussions are very early -- I have a vision of how they should work which is slightly different than how I think it's been laid out so far.But what I'm mostly understanding is a site template would be:recipe(s)theming/stylingconfiguration (can be part of the recipe)content (can be part of the recipe)Essentially it can be a ready-to-go-website which likely would not include custom module code (but contrib is OK)&nbsp;(edited)</td> </tr> <tr> <td>Ashraf - DebugAcademy.com and Drupito.com</td> <td>@jdleonard I think breaking "upgradeability" into 2 parts is valuable:Maintenance of the site (i.e. drupal 11 -&gt; 12 and so on)staying in-sync with the MOP#1 isn't complicated by the recipe route since recipes are 1-time use. You apply them and they go away.#2 complicates things significantly, IMO (unless you fully build this on Drupito - which will allow syncing config from parent to child sites, but comes with tradeoffs.)Assuming you don't go the drupito route for #2 - MOP would become a traditional distribution if you try to do #2. And, personally, I've been burned by distribution-maintenance in the past (i.e. distribution updates lag behind core, and eventually may be deprecated entirely)So I personally would aim for #1 (again if you don't plan on the drupito route) only. I think it significantly simplifies things</td> </tr> <tr> <td>thejimbirch</td> <td>I'd recommend defining the entity data structure, and functionality pieces, first.&nbsp; A single recipe will most likely not be the best option, but a suite a recipes that allow for customization.</td> </tr> <tr> <td>Ashraf - DebugAcademy.com and Drupito.com</td> <td>with my post there ^ in mind, orgs would get the version of MOP at the time they sign up, and they don't get future updates from itre @thejimbirch: I agree. multiple recipes with each recipe representing features and can be mix and matched</td> </tr> <tr> <td>paulmckibben</td> <td>Ryan Szrama from Centarro published a blog post stating that Commerce Kickstart 5.0 is the "first contributed site template". - the blog post describes a bit what they did. Might help us frame what "site template" means right now (even if that definition shifts over time).<a href="https://www.centarro.io/blog/meet-commerce-kickstart-50-first-contrib-site-template">https://www.centarro.io/blog/meet-commerce-kickstart-50-first-contrib-site-template</a></td> </tr> <tr> <td>jdleonard</td> <td>If I understand what Centarro did, they re-created Commerce Kickstart using recipes and provided an installer using Installer Kit. I think their claim to having the first site template is incredibly tenuous because the technical details of what a site template is are not yet defined. A PR win for sure though and I do think the concept of providing an installer could make sense for Member Platform.</td> </tr> <tr> <td>Esmeralda</td> <td>It would be great if we can (also) use oldfashion modules to add to existing websites.</td> </tr> <tr> <td>jdleonard</td> <td>@Esmeralda That would be a goal of mine as well</td> </tr> <tr> <td>bsnodgrass (he/him)</td> <td>@Esmeralda pretty sure that&rsquo;s still a thing :smile:</td> </tr> <tr> <td>bsnodgrass (he/him)</td> <td>Modules can also include recipes which can be applied.</td> </tr> <tr> <td>jdleonard</td> <td>IIRC modules are strongly discouraged from shipping recipes. @thejimbirch?</td> </tr> <tr> <td>bsnodgrass (he/him)</td> <td>@thejimbirch would know&hellip; maybe I am hallucinating. (all these damn lego blocks!)&nbsp;(edited)</td> </tr> <tr> <td>thejimbirch</td> <td>Correct.&nbsp; Module technically can provide recipes, but they could not require dependent recipes other than core since recipes all need to be in the same folder.</td> </tr> <tr> <td>thejimbirch</td> <td>I believe @Esmeralda is requesting functionality that can be added to existing sites, not just a site starter.</td> </tr> <tr> <td>thejimbirch</td> <td>That would be salved by a suite of smaller recipes rather than just a "site template", whatever format that takes.</td> </tr> <tr> <td>thejimbirch</td> <td>If new modules are need to be created for this initiative, they definitely should, but I believe the idea is to try to use what exists already.&nbsp;(edited)</td> </tr> <tr> <td>bsnodgrass (he/him)</td> <td>So any recipes included in a module would be &ldquo;optional/examples&rdquo; (is there a doc for that? :eyes:)</td> </tr> <tr> <td>thejimbirch</td> <td>Any recipe in a module would not be discoverable by other recipes, which are kept above the webroot in a single /recipes folder.&nbsp; I have never had a use case to include a recipe in a module, so would not be comfortable giving them a name like &ldquo;optional/examples&rdquo;.</td> </tr> <tr> <td>thejimbirch</td> <td>Recipes should require and install modules.&nbsp; Not the other way around.</td> </tr> <tr> <td>Ashraf - DebugAcademy.com and Drupito.com</td> <td>A module's composer file should be able to declare a recipe as a dependency. That should result in the recipe being placed in the appropriate location when the module is downloaded.(but that is a little backwards -- normally a recipe would require a module)Feel free to correct me &#128578;</td> </tr> <tr> <td>thejimbirch</td> <td>That is correct also, but yea, a little backwards.</td> </tr> <tr> <td>bsnodgrass (he/him)</td> <td>Thanks, my misunderstanding. So a recipe could be included in a module, but DON&rsquo;T, just because you can doesn&rsquo;t mean you should!</td> </tr> <tr> <td>bsnodgrass (he/him)</td> <td>Sorry to take us down that rabbit hole, LOL</td> </tr> <tr> <td>jdleonard</td> <td>Member Platform 1.0 will be used primarily by Drupal User Groups, which have knowledgable technical volunteers on hand.But our mission focuses on &ldquo;especially those [MOs] with low technical or financial resources&rdquo;. Eventually, I believe that this target audience using Member Platform will do so via SaaS solutions e.g. Drupito because&hellip; how else would they get the project installed, maintained, updated, and supported?So, as a first port of call, I ask how can we as the open source project best structure the project to serve this audience? What does a SaaS provider need to cost effectively provide Member Platform as a service over the long-term?</td> </tr> <tr> <td>jdleonard</td> <td>@Ashraf - DebugAcademy.com and Drupito.com wrote about his option 1 &ldquo;orgs would get the version of MOP at the time they sign up, and they don&rsquo;t get future updates from it&rdquo;.I think it will be unreasonable to many MOs to never receive future updates. I think we need to provide feature updates. Do others share this view?</td> </tr> <tr> <td>Ashraf - DebugAcademy.com and Drupito.com</td> <td>I think that all depends on what's included at launch. If we're talking about very small orgs, and if you launch with the features they need, they would be OK with it.They'll still have the ability to add features (i.e. hire a sitebuilder) if they really need something specific. But in my experience, a lot of the small orgs are happy to leave their sites as-is for a year, then come back when they need a feature added</td> </tr> <tr> <td>Ashraf - DebugAcademy.com and Drupito.com</td> <td>two quick examples: I have two Drupal 7 clients whose sites haven't been updated in 7 years. they both love their sites and not receiving updates doesn't occur to them</td> </tr> <tr> <td>jdleonard</td> <td>My assumption is that the less well resourced orgs we aim to optimize for are highly unlikely to ever hire someone to perform specific work on their website.</td> </tr> <tr> <td>Ashraf - DebugAcademy.com and Drupito.com</td> <td>agreed. but if their core needs are met, they may be okay with that (like the d7 site owners I mentioned). I would say there are likely tens (or hundreds) of thousands of drupal 7 sites out there that haven't received any updates in many years, but the sites still serve them well</td> </tr> <tr> <td>jdleonard</td> <td>I think you make a good point. I guess it&rsquo;s a question of how rich an offering we provide.</td> </tr> <tr> <td>Ashraf - DebugAcademy.com and Drupito.com</td> <td>one angle might be, instead of focusing on launching the whole MOP, we focus on launching recipes, one at a time, that fulfill specific needs to the point where not-receiving future updates for that recipe would be OK to small orgs</td> </tr> <tr> <td>Ashraf - DebugAcademy.com and Drupito.com</td> <td>i.e.:MVP: Launch recipe #1 (let's say events)Early-adopter users install recipe #1. they will never receive updates for events.Later, launch recipe #2: FAQ section.new &amp; old users can install recipe #2. No upgrade path needed for Early-adopter users since it's a new recipe...and so on, until there's a catalogue of X refined recipes</td> </tr> <tr> <td></td> <td>(and even though the users who installed it won't receive updates, you can still update it for future users)</td> </tr> <tr> <td>bsnodgrass (he/him)</td> <td>interesting, sounds worth considering</td> </tr> <tr> <td>Ashraf - DebugAcademy.com and Drupito.com</td> <td>My motto is minimize dependencies, simplify maintenance. This is in line with that. But as always there's a tradeoff -- not pressuring you to go in this direction</td> </tr> <tr> <td>jdleonard</td> <td>Interesting. I do think there&rsquo;s a spectrum here. For example, key membership management stuff (much of which might live in the CRM project if we go that route and other pieces might be in the member namespace) might be a set of modules that are more carefully maintained while there could be a suite of feature-focused recipes that build on that.</td> </tr> <tr> <td>Ashraf - DebugAcademy.com and Drupito.com</td> <td>And I think it's worth noting that what I'm suggesting doesn't prevent adding modules and updating those modules. It's more about the config &amp; content pieces, which I would personally have live in the recipes. I wouldn't send updates for anything added by the recipes.But the actual contrib modules (possibly created as part of the MOP effort) which get downloaded (by the recipe or otherwise) would be regular contrib modules. Regular modules typically do provide e.g. upgrade hooks as needed</td> </tr> <tr> <td>jdleonard</td> <td>Yep, understood. I&rsquo;m thinking more about business logic that might live in ECA config and where that should live.</td> </tr> <tr> <td>jdleonard</td> <td>I can&rsquo;t help but keep comparing a future SaaS offering of Member Platform to its proprietary competitors, which I would expect to provide ongoing feature updates to end users.Let&rsquo;s say that Member Platform itself doesn&rsquo;t provide an upgrade path for various features. Is there a cost-effective way for a SaaS provider to do so?</td> </tr> <tr> <td>Ashraf - DebugAcademy.com and Drupito.com</td> <td>Gotcha. Yeah, personally, I would file that under does-not-upgrade</td> </tr> <tr> <td>Ashraf - DebugAcademy.com and Drupito.com</td> <td>drupito will have a config-sync option. it can sync all config from parent site to child site</td> </tr> <tr> <td>Ashraf - DebugAcademy.com and Drupito.com</td> <td>(until/unless the child site opts-out)</td> </tr> <tr> <td>Ashraf - DebugAcademy.com and Drupito.com</td> <td>we're looking into when we can make it more granular as well. but initially it will sync most config from parent to child.child site would be prompted: new updates available - accept updates? If yes, it will apply the config from the parent site to the child site</td> </tr> <tr> <td>jdleonard</td> <td>Interesting. Will changes made to the child site necessarily be overridden even if there wasn&rsquo;t a &ldquo;change&rdquo; made to that config on the parent site?</td> </tr> <tr> <td>Ashraf - DebugAcademy.com and Drupito.com</td> <td>Eventually, no. But we're going to release this in stages:Bare-minimum MVP looks like: child site is in config-readonly mode (with a few exceptions, like site name, logo, etc). All updates are synced.MLP (minimum 'lovable' product): more granular syncing so child-sites don't need to be in config-readonly mode. We have a handful of ideas on how to handle this. For example, one option is the parent site specifies which config should be readonly for the child sites, so only that config gets 'locked'. If a child site breaks the 'lock', then they can't receive automated config syncs again</td> </tr> <tr> <td>jdleonard</td> <td>Nice</td> </tr> </table> <h2>7&#65039;&#8419; CRM selection.</h2> <table> <tr> <td>jdleonard</td> <td>We have discussed basing Member Platform on a CRM as this is effectively required for some organizations.</td> </tr> <tr> <td>jdleonard</td> <td>Discussions at DrupalCon Atlanta (and in our prior meetings) have shown that most people are uncomfortable with necessarily treating a contact/member (which could be an individual, household, or organization) as a Drupal User. I propose that this eliminate <a href="https://www.drupal.org/project/contacts">Contacts</a> for consideration for an underlying platform.</td> </tr> <tr> <td>jdleonard</td> <td>The other CRM with recent activity is <a href="https://www.drupal.org/project/crm">CRM</a>, which is very much under development. @bsnodgrass (he/him) mentioned <a href="https://www.drupal.org/project/redhen">RedHen</a> and <a href="https://www.drupal.org/project/crm_core">CRM Core</a> for consideration, which I had initially dismissed due to lack of recent development, but I want to throw those over the fence here for consideration as well.</td> </tr> <tr> <td>jdleonard</td> <td>@Steven Ayers is the maintainer of CRM and is a co-maintainer of CRM Core. Steven, rather than me putting words in your mouth, I&rsquo;m hoping you can shed some light on your rationale for starting a new project rather than improving on CRM Core or RedHen.</td> </tr> <tr> <td>bsnodgrass (he/him)</td> <td>I&rsquo;m not sure I agree that we should eliminate the contacts module from our potential CRM options until we have determined the scope and evaluate all the options.&nbsp;(edited)</td> </tr> <tr> <td>bsnodgrass (he/him)</td> <td>This issue for reference:<span class="drupalorg-gitlab-issue-link drupalorg-gitlab-link-wrapper"><a href="https://git.drupalcode.org/project/member/-/work_items/3509536" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/member/-/work_items/3509536</a></span></td> </tr> <tr> <td>bsnodgrass (he/him)</td> <td>@Steven Ayers I also was confused by the CRM Core vs. the CRM module.</td> </tr> <tr> <td>Steven Ayers</td> <td>Hi,CRM and CRM Core are two different projects; both are CRMs. I used CRM Core in Drupal 7. With Drupal 8, Organizations became separate entities. Having people and organizations as separate entities makes it harder to define relationships between them. CRM Core uses Dynamic Entity Reference, which has issues on certain hosting platforms.RedHen also has organizations as separate entities.CRM Core expects the site builder to define the telephone, email, and address fields. The problem with this approach is that the existing email, telephone, and address fields are not what you want for a CRM. You will want to select a primary email/telephone/address for a CRM. You may also want to select with type, e.g., home, work, etc.To build out the more advanced features, such as address labels, bulk email, robo dialer, etc., you need to have common fields.CRM has a single contact entity. It also has custom email and phone fields. The address is still a work in progress.</td> </tr> </table> <h2>8&#65039;&#8419; DrupalCon Atlanta reflections. Anything relevant to Member Platform (e.g. from BoFs, sessions, contribution day) that you recall and want to share?</h2> <table> <tr> <td>jdleonard</td> <td>There were lots of compliments of @Nico Grienauer&rsquo;s promo design (that I tweaked slightly). Thanks Nico!</td> </tr> <tr> <td>Nico Grienauer</td> <td>lol ok thx. but we can do here better. this was just a aquick draft from me :stuck_out_tongue:but yes. it was done thx to Tamara, that we did the figma implementation of the theme as a community project.hearts/shares/usages appreciated if you use figma &#128578; <a href="https://www.figma.com/community/file/1464993429217686833/drupal-brand-community-edition">https://www.figma.com/community/file/1464993429217686833/drupal-brand-community-edition</a></td> </tr> </table> <h2>9&#65039;&#8419; Issues in need of a volunteer.</h2> <table> <tr> <td>jdleonard</td> <td>Issues have been created for drafting parts of the functional spec for 1.0. See child issues of <a href="http://drupal.org/i/3515926">drupal.org/i/3515926</a> and feel free to assign yourself and dive in!</td> </tr> </table>