GitLab Acceleration Initiative meeting on 3 Nov, 2021
>>> [!note] Migrated issue
<!-- Drupal.org comment -->
<!-- Migrated from issue #3247507. -->
Reported by: [hestenet](https://www.drupal.org/user/54034)
>>>
<p>This meeting:<br>
➤ Is for core developers, initiative contributors, the Drupal Association and anyone interested in the initiative.<br>
➤ Usually happens every other Wednesday at 11:00 PT / Thursday 06:00 UTC<br>
➤ Is done over chat.<br>
➤ 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!<br>
➤ 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.<br>
➤ Has a public agenda anyone can add to in the issue<br>
➤ *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.</p>
<h2>0️⃣ Who is here today? Comment in the thread below to introduce yourself! On a personal note - what's something you're doing for fun this month?</h2>
<table>
<tr>
<td>hestenet (he/him)</td>
<td>Tim from the Drupal Association. I'm in Portland, OR where it is cold and chilly. Looking forward to a trip down to the family farm to see my Dad before Thanksgiving.</td>
</tr>
<tr>
<td>mixologic</td>
<td>Well Heyo, Ryan here from Portland. Gonna have a boardgame extravaganza for a buddies birthday this weekend.</td>
</tr>
<tr>
<td>irinaz</td>
<td>Hello, world :slightly_smiling_face:</td>
</tr>
<tr>
<td>irinaz</td>
<td>This is Irina, I am in Mountain View, California, it is sunny and warm here</td>
</tr>
<tr>
<td>markdorison</td>
<td>Mark from Chromatic! I am in St. Petersburg, FL. Pleasant and warm here. Learning to play pickle-ball this month.</td>
</tr>
<tr>
<td>larowlan</td>
<td>Lee from AU, playing social AFL with my daughter. Enjoying it</td>
</tr>
<tr>
<td>neclimdul</td>
<td>Been pretty overwhelmed with some D8 EOL stuff but getting some time to catch up.</td>
</tr>
<tr>
<td>hestenet (he/him)</td>
<td>^^ tell me about it :tired_face:</td>
</tr>
<tr>
<td>neclimdul</td>
<td>If you insist. :smile: That project takeover thing was both a life saver and maybe the end of my sanity since I know own 3 or 4 new modules.</td>
</tr>
<tr>
<td>hestenet (he/him)</td>
<td>Sorry/not-sorry, I guess? :sweat_smile: It did get an uptick in coverage.</td>
</tr>
</table>
<h2>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. Conversation moving slow? Go ahead and open your own thread in the next numeric order.</h2>
<table>
<tr>
<td>mixologic</td>
<td>status update of gitlab backups</td>
</tr>
</table>
<h2>2️⃣ The Drupal Association has welcomed @irinaz to help us as a consultant project manager for the GitLab acceleration project. She's gotten started just about a week and a half ago.Please make her feel welcome! She'll be reaching out to various stakeholders to get to know you and get your insight and feedback as the project proceeds.</h2>
<table>
<tr>
<td>irinaz</td>
<td>@hestenet (he/him), thank you!</td>
</tr>
<tr>
<td>larowlan</td>
<td>Welcome!</td>
</tr>
<tr>
<td>neclimdul</td>
<td>Yay! Welcome!</td>
</tr>
</table>
<h2>3️⃣ Internally, we've been discussing the two parallel paths that we need to take to start making some forward momentum:On the one hand, we need to keep answering big questions like how we will ultimately manage credit - or how core workflows specifically will translateOn the other hand, we should identify the places where we can begin delivering value now: For example all 'general' project types have GitLabCI, and therefore access to GitLab Pages - and a relatively early win we can pursue is enabling this for more project types. </h2>
<table>
</table>
<h2>4️⃣ On the side of GitLabCI and GitLab Pages - @mixologic - maybe you can chime in about some of the quesitons we still need to answer before we go ahead and turn those on for more content types</h2>
<table>
<tr>
<td>hestenet (he/him)</td>
<td>One is cost control, for example.</td>
</tr>
<tr>
<td>mixologic</td>
<td>Oh, I dont forsee gitlabci being enabled on more content types yet</td>
</tr>
<tr>
<td>hestenet (he/him)</td>
<td>Fair enough - but maybe you can elaborate on some of the considerations to get from point a to b.</td>
</tr>
<tr>
<td>mixologic</td>
<td>because then we end up with CI results in gitlab, but not on the drupal org issues.</td>
</tr>
<tr>
<td>mixologic</td>
<td>The reason we're able to do it on general is because general isnt using issues.. I think</td>
</tr>
<tr>
<td>hestenet (he/him)</td>
<td>I think some are and some aren't - although I'm not totally sure.</td>
</tr>
<tr>
<td>hestenet (he/him)</td>
<td>Also - we'd need to figure out what the 'template' test config is to be able to do things like test contrib against core using GitLabCI right? Not necessarily a small undertaking?</td>
</tr>
<tr>
<td>mixologic</td>
<td>Right, theres no pattern and people would like to invert control and make core just a dependency</td>
</tr>
<tr>
<td>moshe</td>
<td>There is a pattern in drupalspoons. The control shifts a bit but it's not inversion imo. Inversion would be a blank gitlab.yml.</td>
</tr>
<tr>
<td>moshe</td>
<td>I think there are valid concerns about supportability here.</td>
</tr>
<tr>
<td>moshe</td>
<td>But making a more generic solution helps the the community self-support. And also projects that vary from the golden path are not gonna get much support. (edited)</td>
</tr>
<tr>
<td>hestenet (he/him)</td>
<td>Yeah - I think ultimately that's where it ends up.</td>
</tr>
<tr>
<td>hestenet (he/him)</td>
<td>In Spoons, how do you set up that pattern - is it a shared base gitlabci.yml that people start with as a template and customize from there?</td>
</tr>
<tr>
<td>hestenet (he/him)</td>
<td>(This is sort of overlapping with our other thread, I guess)</td>
</tr>
<tr>
<td>moshe</td>
<td>There are 2 main pieces. The projects gitlabci.yml includes the "golden" one. Most projects do nothing else.</td>
</tr>
<tr>
<td>moshe</td>
<td>The other is that we have a composer plugin that sets up codebases for easy local and ci testing.</td>
</tr>
<tr>
<td>hestenet (he/him)</td>
<td>Gotcha</td>
</tr>
<tr>
<td>hestenet (he/him)</td>
<td>And forgive my ignorance on this point - but does each maintainer have to implement the golden 'gitlabci.yml' from documentation, or are you able to control that as a default from the 'organization' all the DrupalSpoons projects live in?</td>
</tr>
<tr>
<td>hestenet (he/him)</td>
<td>(And if that isn't something you can do, is that something we might want to do since we have a bit more control via a self-hosted instance than on the .com instance?)</td>
</tr>
<tr>
<td>moshe</td>
<td>It's a true include, not a copy. When golden changes, everyone benefits. Or the project can choose to follow tagged releases of the golden. That's what I recommend and what spoons documents as best practice. (edited)</td>
</tr>
<tr>
<td>hestenet (he/him)</td>
<td>+++ Okay very useful</td>
</tr>
<tr>
<td>hestenet (he/him)</td>
<td>We obviously need to go back through all the spoons documentation again.</td>
</tr>
<tr>
<td>larowlan</td>
<td>Yeah govcms uses gitlab. They lock the .gitlabci.yml at the repo level (you need to submit a support request to unlock it). There's some sort of git hook that prevents pushing commits that change it. The file it self just includes from another project. I will dig up the links. I think @Stuart Rowlands or @Alex Skrypnyk might know more about how it is setup. Might be a good model to follow</td>
</tr>
<tr>
<td>larowlan</td>
<td><a href="https://github.com/govCMS/scaffold/blob/develop/.gitlab-ci.yml">https://github.com/govCMS/scaffold/blob/develop/.gitlab-ci.yml</a> is the per project file</td>
</tr>
<tr>
<td>Alex Skrypnyk</td>
<td>GovCMS uses LFS locking to prevent certain files to be changed.As for CI config - GitLab allows to include parts of the config from the other repo (as per example above). This means that every project can have a minimal CI config to just include referenced CI config managed elsewhere.</td>
</tr>
</table>
<h2>5️⃣ Also on the 'quick win' side - one of the things that d_rumm (who is on vacation today) has been doing is finding places where project pages and user profiles are tightly coupled to versioncontrol_api and it's tables, and seeing which items can easily be replaced with links straight over to Drupal.org.</h2>
<table>
</table>
<h2>6️⃣ Another one of the sub-tasks within this very large scope of work, is that we're evaluating is what the blocker items might be to enabling new projects to choose to use GitLab issues or D.O issues.This is where I'm sure @irinaz would love to chat with some of the people who participated in DrupalSpoons for example, to understand how some existing contrib projects have already made GitLab issues work for them (edited) </h2>
<table>
<tr>
<td>hestenet (he/him)</td>
<td>Possible blockers:They still need to test for compatibility with core - so that problem needs to be solvedThey may have to live without credit, until we have a more generic credit solution.</td>
</tr>
<tr>
<td>irinaz</td>
<td>I would love to talk to folks who maintain modules on Drupalspoons to understand the whole process of going from project page on drupal.org to code to tests and back to next release on drupal.org (edited)</td>
</tr>
<tr>
<td>hestenet (he/him)</td>
<td>Irina has also started a thread over in #drupalspoons to meet those folks where they are</td>
</tr>
<tr>
<td>moshe</td>
<td>I suggest reviewing the issues as shown on devel project. The link is on the devel project page.</td>
</tr>
<tr>
<td>moshe</td>
<td>Can you elaborate on "test for core compat"? Is this referring to gitlab ci?</td>
</tr>
<tr>
<td>hestenet (he/him)</td>
<td>I think so yes - i.e: have you replaced DrupalCI testing with GitLabCI testing for your project on spoons, and if so - how...Certainly it looks like there's also still some DrupalCI testing configured for devel, for example: <a href="https://www.drupal.org/node/3236/qa">https://www.drupal.org/node/3236/qa</a></td>
</tr>
<tr>
<td>moshe</td>
<td>Yeah, there is testing of all prs in gitlab ci plus weekly testing of main branches. We left Drupal ci enabled as well because some people Want or expect that. (edited)</td>
</tr>
<tr>
<td>moshe</td>
<td>I’m happy to give a demo of spoons. Some possible topic are issues, CI, local development, issue migration from d.o, …</td>
</tr>
<tr>
<td>irinaz</td>
<td>@moshe, demo of all these topics would be fantastic. What times would work well for you for the first demo? I am sure we will have tons of follow up questions. Very much looking forward to seeing GitlabCI in action and all the other great things! thanks you!!</td>
</tr>
<tr>
<td>moshe</td>
<td>I'm pretty flexible. This Friday I could start anywhere in the 12-2 timeframe. On Monday I can start in 11am-2pm timeframe. I'm on eastern time. I suggest we block 1 hour. You guys can decide who attends. I suspect it would be valuable for @hestenet (he/him) @mixologic and @drumm</td>
</tr>
<tr>
<td>hestenet (he/him)</td>
<td>Thanks @moshe Will work with @irinaz to figure out schedules.</td>
</tr>
<tr>
<td>hestenet (he/him)</td>
<td>Can I ask what your Tuesday might look like? I'm doing a quick skim and seeing a bunch stacked up on our side.</td>
</tr>
<tr>
<td>moshe</td>
<td>Tuesday 12-2 are good start times Eastern time. (edited)</td>
</tr>
<tr>
<td>hestenet (he/him)</td>
<td>1pm Eastern on Nov 9th works I think - so will coordinate with Irina to get an invite together.</td>
</tr>
<tr>
<td>moshe</td>
<td>great</td>
</tr>
<tr>
<td>irinaz</td>
<td>@moshe @hestenet (he/him) - very much looking forward to our meeting on Tue, Nov 9!</td>
</tr>
<tr>
<td>neclimdul</td>
<td>I've been playing with spoons from a CI perspective for some things recently. Also use non-spoons gitlab CI for daily work. So happy to join any discussions about that.I don't use gitlab's issue queues for anything so can't help there though.</td>
</tr>
<tr>
<td>irinaz</td>
<td>@neclimdul, looking forward to hearing your perspective and experiences with CI on gitlab!</td>
</tr>
<tr>
<td>irinaz</td>
<td>@chrisfromredfin @timplunkett (he/him) @hestenet (he/him), had a great conversation today with @chrisfromredfin about using gitlab issues, looking forward to continue conversation!</td>
</tr>
<tr>
<td>chrisfromredfin</td>
<td>Yeah, we're happy to and excited to help or be "guinea pigs" for it - we're still pretty early on (i.e. have very few issues, so easy to migrate over, etc).</td>
</tr>
<tr>
<td>chrisfromredfin</td>
<td>I'd like to join the DrupalSpoons demo to learn what I can.</td>
</tr>
<tr>
<td>neclimdul</td>
<td>I'm not sure its repeatable but a quirk of how spoons is setup means I could both use it for ci, but also add a few lines to my lando config to make it duplicate the spoons test environment. locally. let me iterate super fast.</td>
</tr>
<tr>
<td>irinaz</td>
<td>@chrisfromredfin!! experimental project !!To join Drupalspoons, open a new issue as per <a href="https://gitlab.com/drupalspoons/webmasters/-/blob/master/docs/onboarding_user.md">https://gitlab.com/drupalspoons/webmasters/-/blob/master/docs/onboarding_user.md</a>. This lets you contribute code or open an issue. (edited)</td>
</tr>
<tr>
<td>neclimdul</td>
<td>wouldn't be mad if it was though. ddev and lando environments for modules that match CI would really improve developer experience.</td>
</tr>
<tr>
<td>moshe</td>
<td>I'm not sure its repeatable but a quirk of how spoons is setup means I could both use it for ci, but also add a few lines to my lando config to make it duplicate the spoons test environment. locally. let me iterate super fast.That is 100% by design. It took quite a while to get that to hum nicely. IMO its the best way to develop contrib modules.</td>
</tr>
</table>
<h2>7️⃣ Status update on GitLab backups, which were a thorn in our side preventing forward momentum</h2>
<table>
<tr>
<td>hestenet (he/him)</td>
<td>@mixologic raised this one.</td>
</tr>
<tr>
<td>mixologic</td>
<td>We've been working on a secondary method whereby we take the backups of the Geo secondary in lieu of making backups on the primary, because the built in method de-references all of the objects in the repository, and we dont want our backups to balloon and then contract if we ever have to restore.</td>
</tr>
<tr>
<td>mixologic</td>
<td>Turns out there is a race condition that was causing new forks on the secondary to not be deduped.</td>
</tr>
<tr>
<td>mixologic</td>
<td>So the secondary was pretty huge as well.</td>
</tr>
<tr>
<td>mixologic</td>
<td>We've got a set of commands now that we can run to dedupe everything, and gitlab has pushed an MR upstream that we should see in this months release, so we're moving forward with actually backing up gitlab in a new way and not losing our minds rummaging through the couch cushions looking for spare disk space.</td>
</tr>
<tr>
<td>hestenet (he/him)</td>
<td>:100:</td>
</tr>
<tr>
<td>larowlan</td>
<td>Good news</td>
</tr>
</table>
<h2>8️⃣ Credit as a generic system taking inputs from multiple data sources (Drupal.org activity, GitLab, other places)^^ In the last meeting, this was a model for credit endorsed by quite a few folks. What are some other considerations we should take into account here?If this were the direction we went, how do we try to focus on simplicity rather than get drawn into complexity?</h2>
<table>
<tr>
<td>hestenet (he/him)</td>
<td>At the All Things Open conference, for example - I had some just generic concepts that sort of speak to this kind of idea:</td>
</tr>
<tr>
<td>nod_</td>
<td>Making credit data available through an API. Currently there is no way to know who was credited outside the commit messages (that I know of) there is the credit data for everyone on the issue though, including people who where not credited</td>
</tr>
<tr>
<td>nod_</td>
<td>Mockups looks good smart to make a link instead of fancier integration. Easy to port to GitHub :+1:</td>
</tr>
<tr>
<td>nod_</td>
<td>Maybe figure out how we reference the thing we give credit for. Just a link? Preset list of options to categorize contrib?</td>
</tr>
<tr>
<td>nod_</td>
<td>Since I don't think we want to tie it to issues always</td>
</tr>
<tr>
<td>matt_paz</td>
<td>Credit as a generic system taking inputs from multiple data sourcesI think that is a great model. I know there are immediate needs that have to be considered, but it might also be interesting to think even more broadly.If you think beyond an initial MVP, one might envision a standard/spec for credit systems that might be used outside the drupal island. Such an effort might get traction from lots of other actors in the broader OSS community. Again, I'm thinking about that <a href="https://lfx.linuxfoundation.org/">https://lfx.linuxfoundation.org/</a> example, but know lots of thriving OSS communities ponder the same set of questions.One might also consider trying to find inspiration from other areas.Inspiration from the Caliper specification used in ed-tech might prove intriguing. There is also interesting work going on in the CLR (Comprehensive Learner Record), Open Badges, W3C Verifiable Credentials and Decentralized Identifiers spaces.Long term, one might envision a scenario wherein a range of "credits" across different types build into some form of stackable set of badges/or certifications that represent a empirical record of substantive engagement/contribution/expertise in a certain area.We know people try to game the credit system today, but something like this probably wouldn't make it better or worse.I also realize that doesn't address immediate needs, but perhaps it is food for thought as you all begin navigating future considerations for this use case. (edited)</td>
</tr>
<tr>
<td>hestenet (he/him)</td>
<td>@matt_paz We've actually done a bit of that broader community exploration with folks like the CHAOSS project (@mtift might be able to tell you a bit more about that)</td>
</tr>
<tr>
<td>mtift</td>
<td>@matt_paz Yeah, what you are talking about might be related to what we've been working on in <a href="https://github.com/chaoss/wg-evolution/issues/410">https://github.com/chaoss/wg-evolution/issues/410</a></td>
</tr>
<tr>
<td>mtift</td>
<td>The title of the metric we're developing is called "Contribution Attribution" <a href="https://github.com/chaoss/wg-evolution/blob/main/focus-areas/community-growth/contribution-attribution.md">https://github.com/chaoss/wg-evolution/blob/main/focus-areas/community-growth/contribution-attribution.md</a></td>
</tr>
<tr>
<td>matt_paz</td>
<td>Oh, that's interesting. I hadn't run across that yet. Thanks for send it it along!</td>
</tr>
<tr>
<td>markdorison</td>
<td>We’ve actually done a bit of that broader community exploration with folks like the CHAOSS projectIs there further collaboration planned with CHAOSS or others or are we at a moment where we need to push forward independently?</td>
</tr>
<tr>
<td>hestenet (he/him)</td>
<td>I think it's a parallel pursuit, just because I don't think we can afford to block other things (like GitLab migration) on it, but ideally it's in alignment - for example - they did accept a merge request to their proposed metrics for our concept of attribution to volunteer vs. org (employer or client).</td>
</tr>
<tr>
<td>matt_paz</td>
<td>Odds are you are already aware of IEEE's GitLab work, but if not, they might be interested in some of the work that Drupal is doing as well.<a href="https://standards.ieee.org/initiatives/opensource/index.html">https://standards.ieee.org/initiatives/opensource/index.html</a></td>
</tr>
<tr>
<td>hestenet (he/him)</td>
<td>Yes - I believe at least one of those folks is also involved in CHAOSS so there's definitely some crossover</td>
</tr>
<tr>
<td>matt_paz</td>
<td>One more link to pass along (hopefully this isn't just noise) ...<a href="https://credit.niso.org/https://credit.niso.org/contributor-roles-defined/">https://credit.niso.org/https://credit.niso.org/contributor-roles-defined/</a></td>
</tr>
</table>
<p>Participants:</p>
<p>hestenet, Mixologic, irinaz, markdorison, larowlan, neclimdul, moshe, Alex Skrypnyk, chrisfromredfin, nod_, matt_paz, mtift</p>
issue