Project Browser Initiative Meeting for October 26, 2022 [#3328106]

1️⃣ https://www.drupal.org/i/3240319 has made more progress, what else can happen there while we wait for d.o?

timplunkett (he/him)	@fjgarlin ^
fjgarlin	not sure, still waiting for the live endpoint to jump up in the priority list.the tests are a GREAT addition, something I wanted to do from the beginning and I didn’t even know where/what to begin with, so I’m super grateful on that addition.I try to keep the plugin up to date with the latest changes every week, but other than that I’m not sure what else can be done from PB side.cc @hestenet (he/him) @drumm
timplunkett (he/him)	Could we commit it in a test module for now, which would share the burden of keeping the plugin up-to-date, and would allow us to start prioritizing it in tests more?
fjgarlin	making it into a test module would be really easy. if you are happy with that approach I can make it happen
chrisfromredfin	cooool

2️⃣ #3313292: Change layout to make plugin-specific content more clear lost a bit of momentum. It went all the way to RTBC, but then got a huge round of feedback and was made back to Need work. I think many of the suggestions mentioned could be child issues from this one if we want to keep the scope manageable. thoughts on whether to address them here or as follow ups or whether this issue need more changes/work?

timplunkett (he/him)	In general, I'm always fine with splitting out follow-ups (edited)
fjgarlin	I’d love to ship the improvement already made soon and then have follow ups to keep on improving things as needed
rkoller	handling some of the points in followup issues is totally fine with me as well. i think only #17 the second point about the still too narrow margin, #21, #22.1 would make sense to be handled within the issue cuz they are more or less directly related to the referenced issue (and the main reason i set it back to needs work). the rest (if they are considered valid) could definitely be moved to follow up issues imho.
fjgarlin	I think all points are valid, or at a minimum, worth considering/discussing them, so that’s totally fine. my main worry was about this issue becoming bigger and bigger, and follow ups are 100% ok.i think only #17 the second point about the still too narrow margin, #21, #22.1 would make sense to be handled within the issue@rkoller - could you summarise on a new comment the above, perhaps directly mentioning the actual issue (to avoid jumping back and forth and having a clear action plan). otherwise I could do it.
rkoller	i will quickly write a comment in the issue summarizing the directly related points left to be fixed and also note that the rest of the mentioned points will be moved to a follow up issue. (and some of the points definitely shouldnt be blockers for the issue. but the plugin source issue and the two different layouts it had in #13 by accident and in the latest patch state just helped to illustrate one underlaying problem i was unable to grasp nor articulate what was my problem with it).
chrisfromredfin	Even better, the points will be moved to their own issues instead of one follow-up? (where appropriate 🙂 )
chrisfromredfin	small chunks make for better drive-by contributions
rkoller	#3313292: Change layout to make plugin-specific content more clear#comment-14763451 added the comment. and one question. what is the difference between a follow up issue and an own issue? isn’t that basically the same or is a follow up labeled as a child issue?
timplunkett (he/him)	there's nothing special that indicates an issue as a follow-up (edited)
timplunkett (he/him)	just to contrast with a blocking issue
timplunkett (he/him)	working on X issue, get Y feedback. must Y happen before X or can it happen after?
rkoller	ahhhhh i’ve misunderstood what chris was writing. “Even better, the points will be moved to their own issues instead of one follow-up? (where appropriate)”he was just saying not all the other topics should be moved altogether into one single issue. instead he meant to split them into one to x follow up issues. and i thought he meant instead of follow ups it should be own issues. that is what i’ve understood. confusion solved. sorry. that was exactly my intention with the rest of the points to sort them and create separate issues accordingly
chrisfromredfin	^ exactly that
rkoller	ahhh and i have to create the follow up issues for that as well. too many things in parallel. not forgot about it. hopefully finish tonight.

3️⃣ One thing I wanted to discuss was that @nerdstein reached out from the Recipes initiative (great stuff happening over there!) and wants to start documenting issues in the distributions_recipes queue for what they might need/want to provide in terms of integrating with Project Browser.

chrisfromredfin	I filed an issue about needing a new project type on d.o. What else can we think through in terms of what needs to be done? I think the best way is as a backend source plugin. Who writes/owns that plugin - Project Browser or Recipes? I would think recipes especially if that's a module that needs to be installed, but I think it might just be "core functionality" that's not related to a module... ¯\\_(ツ)_/¯
chrisfromredfin	So I think there needs to be an issue somewhere to write the backend plugin
chrisfromredfin	Here's issue re: new project type #3317471: [PP-1] Define a new project type for drupal.org
chrisfromredfin	Also, how might this affect Package Manager integration? I do believe "getting" the recipe will be along the lines of "composer require drupal/recipe-name" but the "install" ("apply") might be different. Do we need to abstract that piece out?
nerdstein	I’m happy to set up a brief discussion about this. I fully agree with filing an issues where there are gaps, even if they are to kick off bigger discussions. I’m also working to establish plan issues to organize it all
nerdstein	I think we can file the plug-in issue in recipes
chrisfromredfin	ok I'll do that now
chrisfromredfin	#3317618: Create ProjectBrowserSource plugin
nerdstein	Thank you

4️⃣ As we make progress toward a stable contrib release, we should also keep in mind the ultimate goal of being added to core. We have a lot of issues open right now, some of which are Must Haves and others are Should Haves (and could and won't, see https://en.wikipedia.org/wiki/MoSCoW_method). For the issues we know we need to do in order to be included in core, we should use the core-mvp tag.

timplunkett (he/him)

This will especially help with keeping the Usability work focused, since there are a great number of improvements to be made, but only a subset of those issues would be hard blockers

Participants:

tim.plunkett, fjgarlin, chrisfromredfin, rkoller, nerdstein