This meeting:
➤ Is for core developers, initiative contributors, the Drupal Association and anyone interested in the initiative.
➤ Usually happens every other Wednesday at 11:00 PT / Thursday 06:00 UTC
➤ Is done over chat.
➤ Happens in threads, which you can follow to be notified of new replies even if you don’t comment in the thread. You may also join the meeting later and participate asynchronously!
➤ Lots of threads get posted all at once! Don't worry - start at the top and then jump into the threads that most interest you.
➤ Has a public agenda anyone can add to in the issue
➤ *Transcript will be exported and posted* to the agenda issue. For anonymous comments, start with a :bust_in_silhouette: emoji. To take a comment or thread off the record, start with a :no_entry_sign: emoji.

Agenda

  • Meet and greet
  • Update on the user story audit
  • Setting next steps (and maybe some teams to take them on)

Transcript

0️⃣ Who is here today? Comment in the thread below to introduce yourself and tell us why you are joining us- and maybe one fun thing you have planned for the weekend.

webchick Hi there, this is Angie / webchick. Very interested in this project from the community empowerment POV. :slightly_smiling_face:And this weekend we are going to try making pickles. :open_mouth:
hestenet (he/him) This is Tim from the DA - obviously an initiative coordinator, and lead of the engineering team for Drupal.orgGoing to the race track twice this weekend (edited)
drumm Neil from the DA - this weekend I’m going to pretend to be a plumber
bradjones1 Brad Jones - mostly lurking
bradjones1 Oh and working on a side project :smile:
markdorison Hey! Mark from Chromatic. Interested in efforts to further GitLab integration.Watching the Formula 1 race this weekend. :racing_car:
mixologic here from the DA tuning in
mixologic Im picking apples from my apple tree to turn into cider
dww Derek from TEN7. US. Extremely long-term interest in our community's collaboration / development tools. :wink:This weekend -- will be battling 3 months of growth on our land that went untended while we were back in the Bay Area. The grass is over 4' tall in places...
larowlan Lee, au, late (edited)

0️⃣ 1️⃣ Repeat: Do we have any volunteers to manage meeting issues for the initiative, including capturing the transcript using the browser add on and posting to the issue when the meeting is done?

moshe curious - whats the browser add-on?
hestenet (he/him) https://github.com/mdlutz24/drupal-meeting-parser
moshe Cool. Was wondering if we are using a standard slack app for meetings. Looks like its home grown. Pretty sweet format IMO.
hestenet (he/him) Yeah! It's worked really well for lots of the other initiative meetings.
hestenet (he/him) A true Slack app that did all this would be sweet.
moshe So many https://slack.com/apps/search?q=meetings
dww The timezone isn't ideal for me to actually run the meetings (open threads, etc).  I'll often be late.  And I'm already overcommitted (like everyone else).  But I could take a stab at dealing with meeting transcripts and issue shenanigans if no one else is willing / able.
hestenet (he/him) Thanks for the offer. We'll see if anyone else wants to step forward.

1️⃣ 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.

dww Don't have this fully worked out, but I'm thinking about a thread to discuss the short term strategy for making improvements to Gitlab + bespoke Project* while we sort out the migration to pure Gitlab.  E.g. it's painful and weird now when an older MR needs to have its branch changed. Requires bugging core committers, etc.  Can/should we try to improve anything in the short term, or should we just focus on how to move to full Gitlab?
mixologic is this an official “initiative” ? Is there an inititiave page with the hopeful goals and outcomes ?

2️⃣ Next steps: One of our stated goals last week was to work on migrating more user stories from docs/spreadsheets into our GitLab tracker for user stories:https://gitlab.com/drupal-infrastructure/gitlab-acceleration/user-storie... anyone like to volunteer to help?

hestenet (he/him) The source document to copy from is: https://docs.google.com/document/d/18VOCpmDRljM2845Fz0nFFWbR8xL4IDMtDIH-...
larowlan Shared to #australia-nz as gitlab initiative came up a lot at last week's sprint
tim Lots of questions.Not sure yet but interested.There might technical limits on my end.I don't have permissions to create new issues or edit existing. (Figure that is easily fixed) I was able to put in comment with markdown, bold....Couple more questions about purpose etcPossibly interested in moving it all. Also great for some help as am still new to gitlab, but figure what better way to learn!! :dancerbanana: (edited)
hestenet (he/him) Sure! I've been trying to fiddle with permissions. If you refresh that link do you now get any 'request access' button or something?
tim Worse now get 404 error.  :)
hestenet (he/him) Try again?
hestenet (he/him) (I'm twiddling settings boxes..)
tim In. Can create new issues. But not add labels or anything on right side
hestenet (he/him) Interesting... Hmm...
tim Or should i be able to?     Need....
hestenet (he/him) You should be able to select existing labels and add them to the issues you are creating...
tim Looking again
hestenet (he/him) Going to invite your user to 'reporter' role and see if that helps.
tim Yes just got email.....
tim Ok looking good now
tim Some sort of voice call @hestenet (he/him)? Or dm better?
hestenet (he/him) DM - I'm in another call atm
tim @hestenet (he/him) I got 1 done - couple questions/updates, good time for dm? (edited)
hestenet (he/him) In and out of meetings all day really - but feel free to DM notes and I'll try to get back to you in the gaps.

3️⃣ Next steps: A 'quick win' was proposed to unify the git access agreement with the regular terms of service - we can discuss hereEDIT: Needs issue created for this thread (edited) 

hestenet (he/him) I've pinged the SecWG on this in case of concerns
hestenet (he/him) @drumm any red (or other colored) flags?
drumm The security team does like the explicit affirming that you will work with them.
drumm The “only GPL” requirement is a bit weird. People should know somehow. I’m ambivalent for how that works exactly.
drumm https://www.drupal.org/docs/develop/git/setting-up-git-for-drupal/drupal... is the opposite of a CLA, so not missing anything there.
drumm Maybe put some words on project node add pages
drumm And if this removing the step to pick a Git username (which is a good idea), that’ll need some thinking. We probably can support changing Git usernames now.
drumm Depending on how GitLab counts “active” users, back-filling to give everyone an automatic GitLab account might blow through our license.
drumm Yep, definitely would https://git.drupalcode.org/help/subscriptions/self_managed/index#billabl...
hestenet (he/him) Yeah - we'd probably only want to 'create' that the first time they actually go to interact with GitLab.. Hm..
hestenet (he/him) This thread should probably be captured into an issue
drumm And with more ways to interact with GitLab, in particular, commenting on things, that’s tough.
drumm Might be able to slot it into the JWT exchange for that
greggles I've seen some sites where there's a TOS and then there's some bonus explicit things that are pulled up in "plain language" to remind people of stuff that is in the TOS. I think some things like "must be GPL" should ideally be pulled up to plain language in a context appropriate place where people need to see it.
greggles Same for security type topics.
drumm When creating a project is actually better for those. Informing closer to when you’ll be pushing code. Doesn’t proactively inform co-maintainers though.
mlhess I would rather not merge this with the TOS.
hestenet (he/him) If I take the imagined scenario:You can now create an account on d.o with your GitLab.com credentialsSomeone swings by to open a PR on some module in ContribThey get to the repository in our GitLab instance - click create accountGet redirected/popup for SSO D.O account creation How minimal could we make that pop-up so that when we redirect them back to that repo they can immediately start on that PR?
hestenet (he/him) Might it be possible in the same authentication window to have a separate optional checkbox for git access  + field?

4️⃣ Next steps: 'Experiment first' letting some projects use more of the vanilla gitlab features to try things out

hestenet (he/him) @moshe Raised this last time.I think the Decoupled Menus Initiative is doing some of this already with once.js and their other projects.We enabled GitLab Pipelines for them, for example, and their next request was GitLab PagesShould we chat with them about issues also?
moshe Yeah, I think that would be good. As mentioned last time, I have a scoped label setup in Spoons that might help with issue setup
hestenet (he/him) Right! Is there a link to a place we can see that config?
hestenet (he/him) And/or a screenshot or documentation of it?
webchick This general approach does make sense to me... provides us a built-in list of people who are interesting in "beta testing" and can be used as a sounding board for different decisions if necessary
moshe https://gitlab.com/drupalspoons/devel/-/issues
hestenet (he/him) So category, component, priority, state, and version are each scoped? That makes total sense..
webchick Oh, I see... so "version", "category", etc.
hestenet (he/him) And I see you have kanban boards with lanes for each scope step of the 'state' label for example. Cool stuff
moshe If you login and are a member of spoons you can create a test issue if desired. to play with the labels
moshe New projects get the default scoped labels automatically in Spoons. We would presumably do same for drupalcode.
hestenet (he/him) Would you add my @hestenet-drupal account as a member?
moshe Any chance you could you create an issue as per https://gitlab.com/drupalspoons/webmasters/-/blob/master/docs/onboarding...? There are a few steps and I'd rather the automation handle it. Sorry.
moshe Its cool that Decoupled Menus is using Gitlab. Yet they arent a great test case IMO. I'd love to see a few contrib projects so they can PR their own code, run own tests, manage issues, etc.
mixologic GitlabCI isnt fully setup right now, but if people are willing to bring their own runners, that would accelerate things
bradjones1 Is there a centralized location for info on what is and isn't enabled on Drupal's gitlab? I stumbled across Decoupled's use of runners and (wrongly) assumed this was more enabled than it is, after reading this thread
hestenet (he/him) Not at this time - partly because it's not as simple as a selection of feature toggles - GitLab matches up a lot of things onto big monolithic configuration pages, so we're doing some stuff by block paths and things. Hmm..
bradjones1 It's self-hosted CE?
drumm EE, or I think they changed the tier names. We get the top one. (edited)
drumm Self-hosted Ultimate
mixologic We hope to upgrade to optimus prime someday.
drumm Omnibus prime?
larowlan As with last week, happy to be guinea pig
hestenet (he/him) Thanks @larowlan I think we'll take you up on that relatively early in this process.
hestenet (he/him) I'm not yet sure we have the clear ability to selectively turn on/off some of those things just yet - but will get closer

5️⃣ Breaking down the meta into actionable steps -- one of my personal priorities is to take the meta issue and break down the 'Targets' section into mini-roadmaps for each area. Would welcome some input or proposals #3227737: [Meta] GitLab Acceleration Initiative

webchick Do you have an example of what you have in mind for "mini roadmaps"? Kind of like you set up for e.g. telemetry? or?
hestenet (he/him) Yeah - I guess so - just a rough order of operations for each of those targets.
hestenet (he/him) (Not a fully formed idea yet!)
dww Yeah, breaking things down into smaller action plans sounds like a very good idea.  I probably won't have time during this meeting / today to actually do any of that, but I'd be interested in trying to help this along if possible. Feel free to @dww me if someone's working on it and I'll try to make some time to join the fun.
hestenet (he/him) Sure

6️⃣ Short term wins: There are some rough edges on the current hybrid gitlab + d.o issues (reassigning the branch of MRs, core's merge workflow etc) - what's worth investing in - knowing that we're trying to move off of this?

hestenet (he/him) per @dww
mixologic I think that we should still open infrastructure issues with the current system, as I dont think theres necessarily a rule of thumb we can apply that determines whether something is or isnt worth doing, except on a case by case basis
bradjones1 +1 on changing target branch.. maybe it's tied to the branch on the d.o. issue?
mixologic ie. the specific issue @dww mentioned sounds like something we need to do
dww @bradjones1 The problem with that approach is that (part of) the point of this initiative is to kill off d.o issue nodes entirely.  So that'd only be a very temporary solution to the bigger problem. (edited)
dww @mixologic Makes sense.  We have to decide case-by-case.  Just wondering if such chatter is a distraction from this initiative and should be handled separately, or if the "scope" of this would include short-term bandaids and the like...
mixologic Granted, this issue is the same whether we’re using d.o. issues or gitlab issues.
mixologic if your MR is against 9.2.x, and then we move to 9.3.x, you still need to rebase your MR against the new branch. Now, Its unclear if there is a clean way to do that en-masse
mixologic or if theres something we can try that catches 80% of the use case, and the other 20% will have to be a manual action by interested contributors.
bradjones1 Similar but not necessarily the same; the current integration makes for a rather cluttered issue when the integration prints out 100's off commits from the diff on a wrong branch - in native GitLab it just collapses more gracefully (edited)
hestenet (he/him) If that's not captured here: https://docs.google.com/document/d/18VOCpmDRljM2845Fz0nFFWbR8xL4IDMtDIH-... ideally here: https://gitlab.com/drupal-infrastructure/gitlab-acceleration/user-storie... should make sure we capture it even in brief
mixologic One potential solution is to fundamentally alter branch management of core development. Its a huge change, but it might be better in the end.
mixologic instead of ‘developing on whatever the highest branch’ is, we always develop on main , and its not until a certain point in the release cycle that the release branch is created.
mixologic (be that alpha/beta etc)
mixologic It certainly has all kinds of other implications, but really we treat whatever branch happens to be most recent as “main” until we open the next branch. Then that becomes ‘main’ etc..
markdorison I think this issue would fall under this “rough edges” category: Gitlab MRs are unsuitable for use with Composer Patches - need a way to make a branch stableAt the very least maybe it should be addressed within the context of this effort. I am not sure if a move to “kill off” Drupal.org issues would make this issue more or less relevant. (edited)
dww Yes, Gitlab + composer-patches is a whole other can of worms.  That's only going to be worse moving forward.  I think that's something definitely in scope for this initiative, and something we need to have a good answer for.
hestenet (he/him) ^^ Repeat the please capture on the doc - so we can move into the kanban board request for this one too
greg-boggs One way to handle the patch difficulties (If we are still using the issue queue) would be to automatically post a patch file when a merge request is created or updated. Right now, that's done manually, and if a person doesn't do it manually, there's often no patch file for MRs.
mixologic That also feels like an issue that exists in both workflows. But, also an issue that people have been doing mostly wrong the whole time.
mixologic The design of ‘fetching the patch you need from somewhere else to build your codebase’ is flawed.
mixologic its convenient to just have a url to a thing, but if you need something for your build, you should store it and not necessarily rely on it being served from a url. i.e. its also why composer has a cache etc..
dww We're getting off topic for this thread. :wink: I don't want to debate the philosophical points of where the patches should live in here.  I think the main point is that we should be capturing the "rough edges" and pain points into issues now, and we can sort out / prioritize them as part of this initiative.  In many cases, the pain will continue (if not get worse) once we move to full Gitlab.  So we should definitely capture everything now and use it as part of our planning.
markdorison Agreed. I think regardless of our best-practice recommendations for composer patch workflow, the inability to easily obtain a patch for an MR is a rough edge worthy of improvement.
dww Another pain point for short and long term: It seems that only MR admins (aka the original author, or core committers can mark a review point comment thread as resolved. That seems like one of the primary things we need the community to be able to do, or Gitlab MRs are going to be extremely painful and time-sinky for core committers. :cry: If they have to personally review/resolve every review thread, it's going to be a huge drain on committer time/energy.  It seems we need to find a solution for this so that "anyone" can resolve each other's review threads...
moshe Agree, thats desireable for sure ... Just to push back on the need part - d.o. issues have never had resolved or unresolved or threads. And many open source projects dont bother to resolve threads on Github and Gitlab. It works out just fine. (edited)
dww At least with d.o issues + dreditor reviews, we have a way to identify review points. E.g.:New patch: Fixes #43 points 1, 2 and 4.  Still todo: 3 and 5I don't even know how to refer to review points in Gitlab other than via the threads.
drumm Since that would be a GitLab change, it probably isn’t short term.
dww So the only possible short term work-arounds are:Ignore the problem and let folks figure out what's resolved or notBug core committers about it if it's confusing and worth cleaning up?
drumm Or grant everyone developer access, maybe put in some pre-push validation, see what happens when everyone maintains everything.
moshe You can still refer to comment numbers and bullet points. Example: "https://gitlab.com/gitlab-org/gitlab/-/issues/1234#note_101075757", which is rendered as #1234 (comment 101075757)
hestenet (he/him) Drumm's comment about elevating access and then restricting via GitLab 'policies' may be a possibility - however, they haven't created that feature yet - https://gitlab.com/groups/gitlab-org/-/epics/4168
moshe that issue looks unfocused and unlikely to proceed in my eye
drumm I’ve seen more mentions of “policies” unblocking paying customers. Certainly more support than https://gitlab.com/gitlab-org/gitlab-foss/-/issues/12736. That said, yes, it’s a huge architectural change and will take awhile, if it happens at all.
drumm Oh and magic words that trigger a bot are always an option. Then we’re back to special workflows and custom code in the bot.
moshe Paging @morbus (they/them) :slightly_smiling_face: … I do think bots are part of the eventual solution for us. Gitlab has a simple API so the bot can be so useful. Triage https://medium.com/analytics-vidhya/gitlab-triage-bot-ba8afca4440a is a gitlab bot that they have made available. Bots arent so much code nowadays but yeah, its another thing
neclimdul a name (534 kB)https://media1.giphy.com/media/VMgcrwq9imGHu/giphy.gif?cid=6104955edfb39... using /giphy
drumm Yeah, bots are probably somewhat inevitable. Many projects have them to work within the confines of GitHub/Lab. A welcome bot with no UI is great. Needing to know what is needed to trigger an action is not ideal.

7️⃣ Making things official - This initiative was announced a Driesnote and has a big meta issue, but we don't have an official initiative page yet - we should probably create one? (edited) 

hestenet (he/him) per @mixologic
mixologic https://www.drupal.org/about/core/strategic-initiatives not listed etc
dww There was some weirdness / pushback that #bugsmash wasn't "really" an "official" initiative or something.  I think the compromise was that we're considered a "community" initiative" not a "core / strategic" initiative.  I'm not sure what the difference is or why it matters. (edited)
dww I do think an initiative page can be helpful, if nothing else, to be a landing page with links to all the other spots where things are documented.
hestenet (he/him) Added us to the main landing page - didn't make a sub-page yet, but linked to the meta issue instead for now: https://www.drupal.org/about/core/strategic-initiatives
webchick If Dries shouted it from a Driesnote, IMO it counts as a "strategic" (top-down) vs. "community" (bottom-up) initiative.
webchick So +1 for the page.

Participants:

webchick, hestenet, drumm, bradjones1, markdorison, Mixologic, dww, larowlan, moshe, tim, greggles, mlhess, greg-boggs, neclimdul

Comments

hestenet created an issue. See original summary.

hestenet credited Mixologic.

hestenet credited bradjones1.

hestenet credited drumm.

hestenet credited dww.

hestenet credited greggles.

hestenet credited larowlan.

hestenet credited markdorison.

hestenet credited mlhess.

hestenet credited moshe.

hestenet credited tim.

hestenet credited webchick.

hestenet’s picture

hestenet
He/Him
Location Portland, OR 🇺🇸
CreditAttribution: hestenet at Drupal Association commented
Issue summary: View changes
hestenet’s picture

hestenet
He/Him
Location Portland, OR 🇺🇸
CreditAttribution: hestenet at Drupal Association commented
Status: Active » Fixed

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.