Meeting will happen in #d9readiness on drupal.slack.com.

Hello and welcome to this Drupal 9 readiness meeting!

This meeting:
➤ Is for core and contributed project developers as well as people who have integrations and services related to core. Site developers who want to stay in the know to keep up-to-date for the easiest Drupal 9 upgrade of their sites are also welcome.
➤ Usually happens every Monday at 19: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!
➤ Has a public agenda anyone can add to: `https://www.drupal.org/project/drupal/issues/3116922`
➤*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.

0️⃣ Who is here today? Comment in the thread below to introduce yourself.

mikelutz Its me, It’s me, I’m here, I’m here, Hi how are you? I’m here Mike! Hello!
Gábor Hojtsy (he/him) Gábor, Drupal 9 coordinator
tedbow Ted, Drupal core contributor
xjm :wave:
shaal Ofer, Drupal-Rector, Umami demo
martin martin, just trying to be helpful.
hestenet (he/him) Tim from the DA - located in Portland
dan2k3k4 Dan, on a train in Switzerland :smile: (edited)
drumm Neil, Drupal Association, Brooklyn NY
dww Derek
webchick webchick, Vancouver, Canada
greg.1.anderson Greg, catching up
heddn Lucas, following along from home
catch Nat from the UK.
lendude Len, lurking
larowlan Lee, late, timezones
vuil I have to follow the D9 updates.Ilcho Vuchkov, contributor to Drupal modules.Happy holiday to all Bulgarians! :flag-bg:
wimleers (he/him) :wave: catching up after the fact

1️⃣ Do you have suggested topics you are looking to discuss? Post in this thread and we’ll open threads for them as appropriate.

mikelutz I would like to discuss SF5 compatibility in 9.0 and 9.1. I realize it’s not a priority for beta, but I would like to have some discussions about timing, deprecations, and general thoughts on the process.
xjm Update on beta!
hestenet (he/him) Update on Drupal.org semver blockers for core (per @drumm) . (short version: no more blockers :tada: ) (edited)
mikelutz I’m also wondering if there are any D9 marketing messages that we should coordinate emphasizing as we come into conference season and have D9 related presentations.
hestenet (he/him) @mikelutz I think our ED Heather and Gabor have talked the tiniest bit about that - I know we have a marketing/pr consultant helping with the wider effort - but it would be good to tie that in with presentations people are giving. (edited)
Gábor Hojtsy (he/him) @hestenet (he/him) let’s leave the discussion for threads not here
tedbow Drupal core blockers for drupal.org semver.
dan2k3k4 So Switzerland enforces all events being cancelled with 1000+ members (and also cancels a lot smaller events)... how is coronavirus going to effect upcoming camps and therefore effect possible sprinting days for D9? e.g. DrupalCamp London, DevDays Ghent...I mean - do we plan a backup of doing remote sprints during those allocated camps if they were cancelled?Plus I assume some people might want to actively avoid travelling to camps so they may want to still participate remotely if they can :slightly_smiling_face:I've just thrown an idea into Amazee Slack... that maybe Amazee can help "sponsor" Zoom sessions by providing a Zoom ID for people to use if they need capacity (since free accounts only last ~30 minutes and maximum 20 guests I believe). Maybe the idea gets traction :smile: (edited)
xjm Start a D10 readiness initiative the day 9.0.0 (or RC1 or whatever) ships
webchick There seems to be confusion out there as to whether or not people can move directly from 7 -> 9 or whether they need to move 7 -> 8 -> 9. I suspect https://www.drupal.org/about/9/migrate-7-to-8-to-9 is the culprit, which was written at least a year ago AFAIK when an interim step to D8 would get you more "bang for your buck." It probably makes a lot less sense now.TL;DR: Can we have a topic about 7 => 9 migrations, whether we document that as an official valid way to do it, and if so where?
Gábor Hojtsy (he/him) I think all the topics were covered, thanks all!

2️⃣ Update on beta status

Gábor Hojtsy (he/him) @xjm proposed this
xjm So TLDR, we are planning to announce today or tomorrow that we'll extend the beta1 deadline for a June release to March 13. So the target window will be the week of March 16 and we will definitively announce that week, to a wider audience, whether June or August is the planned release date.
xjm There's a post draft with a call-to-action for outstanding items in https://docs.google.com/document/d/1_8DNw9gqh0cfNJxz_evtUUhd7cw8FdX-dZGg...
xjm Practically speaking, I'd say we're at as high as a ≈40% chance that we could complete the outstanding blockers by March 13. A number of long-running things landed in the past week, deprecation removals and dependency updates are almost done, etc.
xjm It's mostly down to the D9 theme work, the post-update removal and miscellaneous upgrade path criticals, and the DB requirement issues
xjm Anything folks can do to accelerate those issues is appreciated
berdir and some infrastructure issues I think :slightly_smiling_face:
xjm Right, those are the DB req things I was mentioning :slightly_smiling_face:
heddn Folks have put in a lot of effort. Its nice to see there is some chance at still landing on June
xjm (They're ready to start turning semver for contrib on this week once we release 8.8.3)
berdir ah. sounds great to me, should still give us plenty of time to finish up a stable release, still going to be a challenge but might be doable :slightly_smiling_face:
berdir somehow we always need a looming deadline to really progress, but I guess that is a very human thing ;)
xjm Yep totally :slightly_smiling_face: Although we're really seeing dividends of a year's work here too
xjm And as we narrow the list, more people are available to work on the last things :slightly_smiling_face:
berdir that's true, a ton of work went into getting the deprecation stuff cleaned up enough to properly remove it and so on
mikelutz I haven’t joined in the deprecation removal stuff much due to time, but I’ve started dedicating time to core work again. I was picking at SF5 compatibility stuff, but I can put that off until after beta if there’s a solid list of what still needs to be done for beta.
xjm There is indeed! The meta and tagged issue list should both be up to date
xjm (And the post draft summarizes the areas that need work) (edited)
Gábor Hojtsy (he/him) @mikelutz #3079680: [META] Requirements for tagging Drupal 9.0.0-beta1
catch I tried to surface the remaining sub-issues as much as possible on that one, so you can see more-or-less the full list of issues that are left there.
Gábor Hojtsy (he/him) both remaining deprecated API use issues are currently RTBC :suspense: (edited)

3️⃣ Semantic versioning! (wait for subtopics)

3️⃣ .1️⃣ Drupal core blockers for semantic versioning

Gábor Hojtsy (he/him) @tedbow raised this
tedbow Looking at this #3009338: [META] Support semantic versioning for extensions (modules, themes, etc) in Drupal core, and allow modules to be compatible with Drupal 8 and 9 at the same time#comment-13302725
tedbow This is a should have #3100386: Create contrib update module test cases that use semantic versioning
tedbow But I would be much more comfortable with drupal.org semver if this was completed.
tedbow that is the only 1 think we should block on. It is test only but I think we would have more confidence the update would actually work with semver on contrib
tedbow thats all I had. Interested in @drumm’s thoughts. Is there anything else you are waiting on for core?
tedbow basically without the test coverage I think will work but I don’t anybody can be sure
drumm I don’t think so. Want to be sure update status works well, and nothing like dependency scanning breaks badly.
tedbow dependency scanning. like when you enable a module in core?
drumm Yeah, any interpreting of version numbers like that.
dww #3113992: The 'Update' page has no idea that some updates are incompatible should probably be a blocker, too
dww Just needs tests at this point. @tedbow I pinged you for input on how the tests should work
tedbow @dww I will look at that today
xjm Yeah that's at least a should-have. @tedbow Let's also add a card for that issue and the tests one to our board.
tedbow yep. doing now

3️⃣ .2️⃣ Drupal.org blockers for semantic versioning

Gábor Hojtsy (he/him) @hestenet (he/him) raised this
hestenet (he/him) I believe per a conversation with @drumm just this morning, that all the D.O side blockers are cleared.We do have some follow up UX tasks - but nothing that should impact core's semver handling for contrib
drumm I think we would be comfortable enabling semantic versioning for all contrib projects at any time now.
dww We didn’t solve the issue queue grouping problem yet, right?
drumm Not yet, and that’s a good one to be aware of. I should be able to put in redirects for everyone’s bookmarks, but it will still be a little disruptive. #3089291: Group issue version “series” by branch instead of API compatibility
dww #3089291: Group issue version “series” by branch instead of API compatibility

4️⃣ Symfony 5 compatibility in 9.0 and 9.1

Gábor Hojtsy (he/him) @mikelutz proposed this
xjm The closer we are to SF5 support as of 9.0, the better. Obviously once beta1 ships some of the issues will have to be 9.1, but others might be backportable during beta depending on the change.
mikelutz This stuff doesn’t really block beta, but I did want to kind of discuss when we wanted to do this stuff. After what we went through in Drupal 8 trying to get SF4 ready at the last minute, I’d prefer to be SF5 compatible from the get go, and then fix new issues as they come along rather than trying to do it all late in the cycle.
mikelutz I’ve been trying to push through some of the easy SF4 deprecations, but some of them will require us to deprecated things ourselves, so those may be forced to be pushed back to 9.1
mikelutz So maybe SF5 compatibility is a alpha blocker for 9.1?
Gábor Hojtsy (he/him) @mikelutz are BC changes required by either of those things?
mikelutz I don’t think so. The goal is to run on SF4 with no symfony deprecations suppressed, while running on SF5 with the SF5 deprecations that are unfixable on SF4 suppressed, much like we did with D8 and SF 3 and 4.
mikelutz So we should be able to make backwards compatible changes in D9 with our own deprecations to do that, then remove the BC layers in D10, just like we are doing now.
Gábor Hojtsy (he/him) ok if that is the case, great
mikelutz My main goal is to get to that point early, and then regularly test against SF5 releases and fix new issues as they come during the whole D9 cycle, and not just wait until we are getting ready for D10.
Gábor Hojtsy (he/him) then it is indeed not beta blocking :slightly_smiling_face:
xjm @mikelutz Minor releases do not have blockers
xjm So there's no such thing as a "9.1 alpha blocker"
xjm (Because minor releases are shipped on a fixed schedule, train leaving the station, etc.)
berdir could possibly add some noise to contrib testing/deprecation checking, but I guess that can't be avoided. in our project we have symfony event dispatcher 4.x thanks to search_api_solr and that adds a ton of extra warnings in upgrade_status :wink:
mikelutz Right, those are timed, so wrong phrasing. I suppose that would be an initiative goal/roadmap, assuming we rename the D9 readiness initiative to the ’Next major version initiative” @xjm :slightly_smiling_face:
xjm Or just bootstrap "Drupal 10 readiness" the day 9.0.0 ships :stuck_out_tongue:
xjm Which, honestly, we should do given that we've got like 2 years to accomplish mega technical debt for D10
xjm Actually I'm going to totally recommend that to my manager as a place we should make some ongoing investment
mikelutz No, I do think Drupal 10 readiness starts the day D9 is released, (if it hasn’t already started)
mikelutz But either way, 9.1 alpha makes sense as a goal to have SF5-latest compatibility, I think.
berdir I think one side effect of trying to do it in 9.0 is that we're trying to backport anything that affects our own API at least back to 8.9, for example the app.root changes (discussed that with @xjm a while ago). we won't have that requirement for 9.1, so in some ways, things will also be easier then. but at the same time, as mentioned before, especially that would be very good to resolve asap as it adds a ton of suppressed deprecation messages
xjm Yeah 9.1.x opens when beta1 is tagged, so we can start landing 9.1.x things during the beta phase before 9.0.0.
mikelutz We can always decide on an individual issue how far back we want to back port it too, Going through them some make sense to go back to 8.9, others expose new deprecations that really should stay in 9.1
berdir @mikelutz yeah, the question is about whether dealing with the SF deprecations will require us to new deprecations of our own and my understanding is that we would want to have those backported if at all possible. so e.g. for the app.root stuff, we would want to at least backport the new services so that modules can be compatible with 8.9 and 9.0 without deprecation messages (edited)
alexpott @mikelutz @berdir I’ve tidied up #3074585: [Symfony 5] Replace app.root and site.path string services with container parameters - think it is pretty ready now.
mikelutz @berdir we can backport the app.root stuff easily enough, but most of the deprecations we will need to add to be SF5 compatible will require at least SF4, so we won’t be able to backport them to 8.9. (We tried to fix anything we could fix in 8.8 already, the app.root stuff just got a bit stuck trying to decide the best way to go, but it was fixable in D8)
mikelutz The mime type guessers and event stuff will really not be backportable to 8, and we may want to just leave it in 9.1 to avoid muddying the deprecation waters in 9.0.
mikelutz @alexpott I definitely like going the parameter route better if you’ve solved all the issues with it.
mikelutz I’ll give it a +1, but since It looks to be based off my patch in #3074585: [Symfony 5] Replace app.root and site.path string services with container parameters#comment-13261603 I’ll let someone else RTBC
alexpott @mikelutz I realised the way we initialize the container in the kernel gave as the ability to set the parameters dynamically.
mikelutz @alexpott yup, and I am trying to figure out why I didn’t think to do that. I may have just been trying to avoid touching the bootstrap code as much as possible.
alexpott @mikelutz I only realised while stepping through container compilation when trying to work how to make Symfony’s expression language work :slightly_smiling_face:

5️⃣ Confusion out there as to whether or not people can move directly from 7 to 9 or whether they need to move 7 to 8 to 9

Gábor Hojtsy (he/him) @webchick raised this
Gábor Hojtsy (he/him) this seems to be coming from https://www.drupal.org/about/9/migrate-7-to-8-to-9
Gábor Hojtsy (he/him) which I think we worked on with @hestenet (he/him) et al
webchick Yes, according to the Migrate maintainers, 7 to 9 is a valid approach. (I've been testing it locally, and seems to be the case.)
webchick But I can't point anywhere on D.o to docs which tell anyone this. Just side-slack discussions
catch You can do either, but more modules are available for 8.x at the moment, and also it has a release.
webchick Yes, though its EOL is ticking along the same rate as D7
xjm Yes, 7 to 9 should theoretically just work, but migrating to 8 first is also a totally smart thing to do ATM since it's the best way to ensure readiness
webchick So if you're doing a big "something huge redesign-y to justify the cost of a migration" it might make more sense to target D9 for that.
catch Once 9.x is out, you can either update your 8.x site that you already migrated into, or you can update your in-development site to 9.x and migrate into it.
berdir yeah, I think the important message that we wanted to communicate is that you should not wait
Gábor Hojtsy (he/him) Drupal 9 even has a complete Drupal 6 to 9 migration path, just saying :stuck_out_tongue: (edited)
webchick Indeed :D
webchick I guess I worry that from an end user POV, that sounds like doubling the work. (WE know it's not, it's something like 1.2x the work, but it's still more)
heddn I think the idea is that you don't have anything "stopping" from upgrading to D8 and you are encouraged to upgrade now. But D9 upgrade support is 100% possible.
webchick So it would be great if we could at least state that it is possible, in a somewhat credible way, even if our official recommendation is to move to D8 first.
berdir So if you're doing a big "something huge redesign-y to justify the cost of a migration" it might make more sense to target D9 for that.exactly not that. we want people to move to D8 now and not wait until D9, as it gives them more them to do that now and test that migration. Unless they add modules that aren't going to be D9 compatible, but most should be soon enough
webchick We WANT them to do that yes. Will they do that? Probably not. :wink: Anyone who was gonna move to D7 => D8 probably has by now.
berdir what @heddn said
xjm @webchick Also since the D7 upgrade is 90% the work, we should just say tht
webchick Yes, we should definitely say that too.
Gábor Hojtsy (he/him) I don’t know if I should touch that page, it was worked on by DA marketing folks back in the day too, @hestenet (he/him)?
hestenet (he/him) For the moment I'd really welcome any edits. Although we are planning an overhaul with a consultant we're working with to come in a few weeks.
hestenet (he/him) I can certainly make an initial change right now.
webchick So I thikn all we literally need is like
webchick "We recommend migrating to Drupal 8 prior to the release of Drupal 9."..."While Drupal 7 => 9 migrations are supported, we recommend migrating to Drupal 8 prior to the release of Drupal 9."
webchick or similar
webchick And maybe an additional bullet on the benefits of "90% of your upgrade is done already between 7 and 8, so you need only worry about the small differences between 8 and 9 when the time comes"
berdir yeah. possibly even for a bit after the D9 release until all the modules you want to use have a D9 compatible release out but that's a detail :slightly_smiling_face:
webchick Alternately, if we don't want to soften that message, another "box" like we have for "What if I want to stay on Drupal 7?" for "Can I move directly from D7 to D9?" "Yes, but moving to Drupal 8 first will simplify migration to Drupal 9"
webchick @hestenet (he/him) should I just hack at the text or would you like to take the lead? :slightly_smiling_face:
hestenet (he/him) I just saved a couple changes.
hestenet (he/him) But go ahead and refresh and keep hacking if you like.
webchick Oh that looks great!
xjm Err I tried to edit the page but the content is not there; must be a placed block or something
xjm Maybe we could plop the text in a gdoc for refinement
hestenet (he/him) It's a panels pane, so the 'customize this page link' at the bottom. But a GDOC is not a bad idea.
mikelutz It would really be nice to have some focus group numbers to understand how people take the messaging here. The ‘move to 8 now’ message was designed to encourage people not to wait, but at the point that people take that to mean they have to migrate twice in a row and suddenly start looking at alternative platforms where they can migrate to once, then the messaging has negative value.
mikelutz Practically and honestly, whether people move from 7 to 8 or 9 now really depends on the contrib modules they need and whether they are ready, but anyone starting the process of an upgrade now with a 6-9 month turnaround should plan to release on D9 even if development starts against D8.
mikelutz But I don’t want to explain that to anybody in a marketing sense.
Gábor Hojtsy (he/him) Yeah starting on Drupal 9 now is “apply these 55 patches against these 30 contributed modules and pray it holds together” (edited)
Gábor Hojtsy (he/him) starting after Drupal 9 came out will be “apply these 32 patches against these 19 contributed modules and pray it holds together”

6️⃣ Start a Drupal 10 readiness initiative the day 9.0.0 (or RC1 or whatever) ships

Gábor Hojtsy (he/him) @xjm raised this
xjm So we deferred some massive technical debt to D10
Gábor Hojtsy (he/him) Sounds like a very good idea given that Drupal 10 is planned to be release 2 years after Drupal 9 :slightly_smiling_face:
xjm jQuery UI components, CKEditor 5, etc., plus PHP 8, SF 5 or even 6, etc.
xjm I think we can start adding "9.1.x followups" to our D9 readiness meetings as we transition to beta, and just roll over to a new initiative as the core parts of D9 readiness wrap up. We can probably go back to bi-weekly meetings though at that point. :slightly_smiling_face:
xjm We also will have the whole D9 process fresh in our minds, so we can file a (postponed) D10 meta issue based on the D9 one and make the adjustments from our lessons learned (edited)
xjm I'm even adding a card to JIRA for myself for that now :stuck_out_tongue:
mikelutz I would love a big D9 retro meeting sometime this fall, Maybe DCEur, where we can see what we can improve for D10
xjm Retros make me sad because I'm never able to attend them, but a good idea nonetheless. Maybe we could do it as a Slack meeting instead of an in-person one.
mikelutz That’s fair. I would definitely like it to be inclusive.

7️⃣ Drupal 9 marketing messages that we should coordinate emhpasizing as we come into conference season and have Drupal 9 related presentations

Gábor Hojtsy (he/him) @mikelutz raised this
Gábor Hojtsy (he/him) I think the developing tagline some of us have been using is “The easiest major version upgrade in a decade” (which assumes Drupal 8 to start with mind you)
Gábor Hojtsy (he/him) There will not be a Drupal 9 logo, the DA is focusing on getting rid of version based branding, so the 8 logo will be phased out AFAIK
hestenet (he/him) Correct - we're reviewing concepts for the evergreen logo starting on Friday (had initial interview with designers about two weeks ago ish)
Gábor Hojtsy (he/him) for clarity the evergreen logo will not replace the Druplicon and will not replace the wordmark, right @hestenet (he/him)?
mikelutz My presentation is supposed to be an honest look at the “gotcha’s” that people might run into while upgrading. I want to give that information to developers so that upgrades ARE easy, but I don’t want to make it sound like the upgrade isn’t going to be easy or conflict with that message, so I’m going to have to have a bit of a balancing act going on. (edited)
Gábor Hojtsy (he/him) @mikelutz I have this steps rundown for what you need to do to update to Drupal 9 and will explain the blue stuff is all done on Drupal 8 (except very edge cases), so you have a fully running Drupal 8 site at the end of the blue and then just switch out core
Gábor Hojtsy (he/him) Screenshot 2020-03-02 at 20.46.56.png
Gábor Hojtsy (he/him) @mikelutz so its definitely a bunch of stuff to do but you are doing it to make your site better and you still have a working site
Gábor Hojtsy (he/him) so again piecing apart the actual Drupal 9 upgrade from what’s not :slightly_smiling_face:
mikelutz That’s a good breakdown. So a focus on the fact that you can do all of this stuff right now in D8 without waiting for D9 to come out.
Gábor Hojtsy (he/him) well, most things :slightly_smiling_face: some modules will have a dedicated 9.x only branch, but that is hard to foretell, it looks like most can just update and have a multicore branch
wimleers (he/him) “The easiest major version upgrade in a decade”I like this :smile:
mikelutz That might be fair, somewhere else in this meeting we discussed not using the word ‘easy’ though.
Gábor Hojtsy (he/him) That was also me. I think in a relative form it is ok. We need to be able to express that this one will take less work than before.
mikelutz But I wonder semantically and psychologically if ‘less work’ is better than ‘easier’
Gábor Hojtsy (he/him) I mean it's easier to build a condo than a skyscraper but both are quite hard :)
Gábor Hojtsy (he/him) Compared to let's say a shed :)
mikelutz I feel (as a native english speaker) that ‘less work’ relates to effort, while ‘easier’ relates to ability.
mikelutz I for example, find it easier to build websites than to make new friends. I don’t think that’s the same for everyone. :-)
mikelutz but making friends is definitly less work than building a website, even if it’s harder for me. :stuck_out_tongue:
Gábor Hojtsy (he/him) Makes sense. I am neither a marketing person nor a native speaker :) so revisions would be welcome

8️⃣ How is coronavirus (covid-19) going to effect upcoming camps and therefore contribution days for Drupal 9? e.g. DrupalCamp London, DevDays Ghent

Gábor Hojtsy (he/him) @dan2k3k4 raised this
mikelutz This one does worry me a bit.
Gábor Hojtsy (he/him) I think there was some communication on the London site, looking now :slightly_smiling_face:
hestenet (he/him) DA will have a statement out shortly about DrupalCon Minneapolis.
Gábor Hojtsy (he/him) MidCamp has https://www.midcamp.org/2020/article/psa-midcamp-and-coronavirus
Gábor Hojtsy (he/him) London posted https://twitter.com/DrupalCampLDN/status/1233379905573969920?s=20
Gábor Hojtsy (he/him) (it is not posted on their site for some reason)
Gábor Hojtsy (he/him) Talked to @aburrows just now and they will put it on the homepage too
mikelutz Tough to predict what the situation will be in May or September.
Gábor Hojtsy (he/him) @aburrows put it up on the London site now
Gábor Hojtsy (he/him) Screenshot 2020-03-02 at 21.00.40.png
Gábor Hojtsy (he/him) I am personally planning to still attend London
Gábor Hojtsy (he/him) @dan2k3k4 makes a good point that some people will choose not to attend for their own safety
Gábor Hojtsy (he/him) (especially if they have other conditions and are at bigger risk)
Gábor Hojtsy (he/him) I think this is a good reminder to try to include people not at the event in contribution activities at the event (which BTW I think is generally a good idea)
xjm It would be good to get a statement from the DDD team since that event is going to be key for D9 readiness
xjm Can anyone escalate to them for their plans?
Gábor Hojtsy (he/him) They’ve been discussing it and monitoring the situation ATM, will push it more to make a statement :slightly_smiling_face:
mglaman :grimacing: yeah ^ I plan on still going, but paid a pretty penny for my flight
aburrows adding more atm to the page
aburrows https://drupalcamp.london/event/coronavirus-update
heddn @aburrows there's still mention of midcamp in your copy/pasta ^
aburrows thanks for spotting it :slightly_smiling_face:
aburrows @heddn++
aburrows @Gábor Hojtsy (he/him) ++
dan2k3k4 Just a quick update: so from Amazee side - we have the Pro License for Zoom for most (all?) of our employees, along with 1x webinar license.A Meeting allows up to 100 people... however it means everyone can talk :smile: so at that size it can be messy but it would be good for smaller sprints, plus we could potentially provide multiple meetings.A Webinar allows up to 100 people (well the license we have is capped at that), and webinars have more control. Only hosts can talk / show video - and you have to manually add talk ability to attendees.https://zoom.us/pricingIt's not set-in-stone whether we (Amazee) can sponsor/help out :smile: but I believe the answer is more towards the "potentially yes" (edited)
dan2k3k4 That's in relation to providing/sponsoring/enabling more remote collaboration^ for those who can't attend (whether they choose to or whether they just can't fly out of their own country).
dan2k3k4 With Webinar - people have to register with an email... and it's possible to approve registrations case-by-case (or remove some registrations after).So potentially - if you have one main room you want to give a live stream, with Q&A functionality, then you could screen registered emails against emails who registered to the camp in question (e.g. DCL). Thus allowing those who paid to potentially still "attend" virtually.Just throwing these ideas out there :slightly_smiling_face:Although I've never tried Twitch or other live streaming services... I'm sure those provide Q&A too and perhaps cost less than Zoom... but well since a lot of use Zoom already for work :smile: (edited)
xjm We actually prefer Slack meetings over voice chat, on purpose, because they're more accessible to people from all different timezones, etc., and are their own meeting minutes.
xjm Scheduling a meeting so that everyone from Australia to India to Europe to the West Coast can attend is... kind of impossible. The semi-synchronous Slack meetings address that really well. (edited)
xjm They're also much easier for people to add in their workdays and have lower fatigue for participants
Gábor Hojtsy (he/him) well, this is for contribution activities at events especially with people staying home due to covid-19.. I personally prefer Slack for that too, but I know not everyone does (edited)
dan2k3k4 Yeah the suggestion is more for replacing adding onto sessions/activities at events which are scheduled at specific times... either to open it up more and allow people to join the talks remotely or to open up remote "sprinting" opportunities (edited)
dan2k3k4 And the Webinar option is more for people who paid to attend a camp - and I've helped organise camps before so I know how hard it would be to refund if you're already slightly out-of-pocket since you didn't have enough sponsors to cover the full price of venue/food... so I'm just suggesting a way to offer some "exclusivity" towards those who paid so they could still "attend" without getting the full refund of their ticket (as well that money would have been used to foot the bill in renting the place and that might be non-refundable...)
xjm At sprints, the background noise is a big problem for remote attendees
xjm That said, for sessions, I could see it as a sort of lightweight livestream option
xjm There's also the "sacrificial laptop" problem for a room that doesn't already have a conferencing A/V setup
xjm One person at the table has to run the hangout and can't type because the keystrokes overpower the participants' voices because of the inverse square law
xjm I've taken two laptops with me before because of that :stuck_out_tongue:
xjm There's an issue IMO with MidCamp's text about "Don't attend if you've been diagnosed with COVID-19." Most people in the US can't even be tested for it because the CDC is still very short on testing kits and has only been testing people who traveled to China themselves.
Gábor Hojtsy (he/him) I don’t think any countries have adequate testing capability ATM.
xjm Overall it's a good resource; just that point in particular should mention any flu-like symptoms :slightly_smiling_face:
heddn Costa Rica has sufficient to get results in 24-48 hours I saw in the news today.
dan2k3k4 Perhaps a page about how to possibly setup remote sessions/remote sprints could be useful? If it's done in advance, organisers or even some attendees could help volunteer to bring equipment if needed.---At work we have these 360-degree mics Jabra Speak 410 :https://www.jabra.com/business/speakerphones/jabra-speak-series/jabra-sp... can be useful and you don't get much background noise, just the people speaking (around a table for instance). However we don't have any people at the office using mechanical keyboards :slightly_smiling_face: and I'm sure the mic would pickup that if people used those close to it.---But yeah, I suppose if someone is not attending a camp, then that could mean they're stuck in their own country which could be many timezones ahead or behind the camp timezone. Therefore it could be difficult for them to virtually attend... :thinking_face: still an option to try to accomodate them is always nicer than nothing :smile: (edited)

9️⃣ Time’s up, we covered all suggested topics! Exciting week with Drupal 9 alpha2 coming out :slightly_smiling_face:Thanks all for coming and keep up the great work! :clap:Next meeting on next Monday at the same time same place :slightly_smiling_face: #3117226: Drupal 9 readiness meeting / 9 March 2020 (edited) 

Comments

Gábor Hojtsy created an issue. See original summary.

Gábor Hojtsy’s picture

Issue summary: View changes

Gábor Hojtsy credited dww.

Gábor Hojtsy credited xjm.

Gábor Hojtsy’s picture

Issue summary: View changes
Gábor Hojtsy’s picture

Issue summary: View changes

Attempting to fix markup errors between 5 and 6

Gábor Hojtsy’s picture

Issue summary: View changes

Don't know how those table tags were missing. The messages are there.

Gábor Hojtsy’s picture

Status: Active » Fixed

Status: Fixed » Closed (fixed)

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