Added Google Doc link
Tweaked Slack agenda starter
To avoid introducing another proprietary system into our open source project's workflows, I'm closing this issue. Anyone should feel free to re-open if they feel there's significant value in using Luma to manage our meetings.
Updated issue summary to make the purpose/scope more clear, more simply describe all potential early adopters as "interested" rather than "declared" / "undeclared", and add URLs to existing early adopters' sites.
@skessler Thank you for contributing this!
Could I trouble you to copy this to 🌱 Real organization use cases / requirements Active and close this issue as as duplicate? This will help us keep the issue queue maintainable.
Would it make sense to parallelize the "test" stage next to the "build" stage (and have "deploy" stage dependent on the other two)? Won't make much difference for a while, but in theory? Also wonder whether "build" should be "build-docs" and "deploy" should be "deploy-docs" given we will eventually have other tasks that could probably be performed in parallel. I'm undoubtedly over-optimizing...
Nice one!
jdleonard → created an issue.
jdleonard → created an issue.
jdleonard → created an issue.
jdleonard → created an issue.
jdleonard → created an issue.
Very nifty, thanks!
I tried to find a way to get the preview URL bubbled up somewhere more discoverable than the job logs, but failed :(
0️⃣ Who is here today? Please post your Drupal.org username (for issue credit) if you have one and, if you’re a new contributor, tell us how you’d like to contribute or why you're here.
1️⃣ JD is traveling home from vacation and hasn't planned any topics for this week so... Go ahead and open your own thread in the next numeric order for whatever you'd like to ask/discuss/propose. Be bold!
2️⃣ Anyone doing needs assessment with member organizations?
3️⃣ Design/Logo/etc
4️⃣ End user implementation pathway (Relationship to DrupalCMS) (edited)
5️⃣ Call for declaration of intent to adopt Member Platform 1.0.
6️⃣ Member Platform at DrupalCon Atlanta (all times EST) (edited)
7️⃣ Tasks for DrupalCon Atlanta Contribution Day. Seeking ideas for how best to onboard new contributors including good tasks for them to work on. (edited)
Participants:
bsnodgrass, sarahlorenzen, ridefree, jdleonard, Grienauer, lostcarpark, ashrafabed, aangel,esmoves
jdleonard → created an issue.
jdleonard → created an issue.
Fixing alphabetization
@alexdmccabe there's now a merge conflict that I think you'll be able to resolve more efficiently than I.
Ideally, the changes would be deployed using GitLab Pages to a separate URL that doesn't overwrite the deployment from the default branch, but I don't know if this is possible.
I think we saw this work recently here 📌 Set up MkDocs for docs.memberplatform.org Active , no?
Thanks!
Thanks!
jdleonard → made their first commit to this issue’s fork.
jdleonard → created an issue.
jdleonard → created an issue.
jdleonard → created an issue.
Happy to follow core, thanks!
Fixed a stray character that caused the GitLab link in the footer to not work.
@alexdmccabe My preference is for whatever the best practice is. I'm going to assume from the question that it is to unassign when fixed. Please educate me!
@rockthedrop Spot on! Thank you to everyone who has contributed to date.
Crediting @rocketeerbkw who contributed to the TxDUG use case linked in a previous comment.
jdleonard → created an issue.
Cloudflare proxy seemingly isn't an option because of Drupal.org's Fastly-based protections. Added a simple redirect in the interim.
Marking this as fixed and if ✨ Enable custom domains for GitLab Pages Active gets fixed, I'll create a follow-up issue to take advantage of the custom domain in GitLab Pages.
Also crediting rocketeerbkw who helped debug the Cloudflare page rule attempts.
jdleonard → created an issue.
Just confirmed with drumm that Drupal's GitLab Pages doesn't currently support custom domains (i.e. for docs.memberplatform.org). He advised me to create a feature request, which I shall.
MemberPlatform.org uses Cloudflare so I'm going to see whether I can simply proxy the subdomain from there.
Leaving this open and assigned to me until I have resolution on that.
Thank you for getting this set up!!
@thejimbirch We accomplished this for Member Platform today in 📌 Set up MkDocs for docs.memberplatform.org Active
Updated issue summary based on consensus at DrupalCon Atlanta 2025.
volkswagenchick → credited jdleonard → .
Looking good! Assigning to me to replace license with GPL 2.0
jdleonard → created an issue.
jdleonard → created an issue.
jdleonard → created an issue. See original summary → .
jdleonard → created an issue.
jdleonard → created an issue.
jdleonard → created an issue.
Blocked on the related issues.
Adding tag for possible logo improvements during DrupalCon Atlanta.
All explorations welcome.
One direction would be to explore variations on the logo on the right here:
including seeing how it looks with the Member Platform text in various positions.
One could also tweak the existing logo in Figma to more closely reflect the logo on the right.
Organizers are never required to issue credit. I think having the option is good.
I think there's value created for the community in attending an event and in causing attendees to engage with Drupal.org, but (to @heatherwoz's concern about credit inflation) I don't think doing so should result in significant issue credit being received. What if the weighting for such credits were 10% of normal or something like that?
Perhaps ✨ Add support for simple signups to community events Active could somehow seed a list of people "maybe attended", which an organizer could then confirm for each attendee without the extra work of collecting usernames?
The last comment referenced GitLab Pages, but also changed the title to reference GitHub Pages. Will leave it to @thejimbirch to correct whichever is inaccurate.
I'm interested in the eventual solution here for 📌 Set up MkDocs for docs.memberplatform.org Active
I think this latest one is too abstract.
jdleonard → created an issue.
I like these! I think the second one is stronger.
I assume these last two haven't been used elsewhere.
Think we should transition to this?
Want to create versions with the "Member Platform" text in various configurations?
Austin Slack channel name change, Austin see also Texas
Ordered attached.
jdleonard → created an issue.
mandclu → credited jdleonard → .
mandclu → credited jdleonard → .
teknorah → credited jdleonard → .
jdleonard → created an issue.
jdleonard → created an issue.
jdleonard → created an issue.
Alphabetized
jdleonard → created an issue.
jdleonard → created an issue. See original summary → .
Created a few variations of a simple logo. Thanks to @beautifulmind for his simpler variation of my original experiments, which inspired this set of variations.
There hasn't been much eagerness to improve the logo so this is probably good enough for the time being. Happy to entertain a better logo when someone contributes one!
Exports (Google Drive) (inc. SVG)
Samples:
I think there's significant value to keeping the representation of a "membership" very lightweight so that an ecosystem can form around it to serve many use cases, with various modules / recipes leveraging the key concept of membership (whether for an individual, household, or organization, or multiples of those types).
It might indeed make sense to use Group for some Member Platform functionality, but I don't think we should necessarily require it simply to track memberships.
Commerce License seems incompatible with the approach @bluegeek9 is taking here in CRM, which doesn't require a Contact/member to be a User.
Contacts → does require the use of Users (but removes the need for a User to be able to log in / have credentials) and thus would be more compatible with Commerce License. However, overloading the concept of a User to cover people who don't log in seems unwise and a Drupal anti-pattern.
Looking more at the Membership module's model, I see that its Membership entity has a User as its subject/owner.
My bias for Member Platform (and for a CRM in general) is toward the approach proposed here for CRM of tracking Contacts (and their Memberships) separate from Users and separate from Commerce. I would expect some module to offer the ability to link a User to a Contact and grant roles or Group membership or whatever. I would expect another module to offer integration with the Commerce ecosystem or whatever other payment system.
I think there is lots to learn from the Membership module, but I'm not confident it's worth attempting to actually use the module. Anyone else have thoughts on this?
@freelock Would be great to see the Commerce Membership code!