 Namihi mai o ha kia koutou katoa. A warm welcome to everyone, and thank you for joining us today. As part of that welcome, I'd like to begin by acknowledging the traditional owners of the land in which we meet today, and pay my respects to Elders past and present, and to the whakapapa and ancestors of those of us who choose to make our place on the lands cared for by the Tangata Whenua and our First Nations people. I'd also like to acknowledge that we've just started a minute after 11, in recognition of Remembrance Day, and this will obviously might be different in different time zones, so feel free to take your own minute of silence when it's 11 a.m. wherever you happen to be. My name is Dave Sparks, and I am part of the Drupal South Committee, bringing you the second leg of the Drupal South Shorts event today. I'd really like to thank everyone who has come along and shown their support, and thanks for your interest in our online conference series this year. The response has been really amazing. It's great to see our industry doing well and continuing to do interesting and challenging work. Just a quick note, if you have any technical issues as an attendee or a speaker, or get stuck at any stage, live support is the orange icon near the top right of the platform screen. We've got a good team standing by, ready to help you all have an awesome experience today. As always, Drupal is brought to you by a team of volunteers and supported by our fantastic industry sponsors. They're all online, available here, ready to chat throughout the day, so feel free to get in touch, light up a discussion, follow up on their topics. You can do this using the meeting hub on the right-hand side of your screen, and if you look at the schedule, there are some sponsor showcase sessions coming up later in the day where you can learn more. I'd like to just pause for a moment and give a huge and a heartfelt thank you to our sponsors. Thank you to Accenture, Aqueer, Amazey.io, Annex, Catalyst, Doghouse, Just After Midnight, Morphed, Pantheon, Previous Next, Salsa Digital, Sector and Skipper. We really appreciate your contribution towards the community and the conference today. Not just for the conference today, but supporting meet-ups and other industry programs throughout the year. All profits from these Drupal South Events go back to supporting those activities, including programs identifying and bringing new talent into the Drupal community. So on behalf of the Drupal South Committee and the community, a big thanks to those sponsors for all that you do, not just to make things possible, but to support us to thrive and flourish. For the committee, you'll also see a spot in the schedule for the Drupal South Committee community update where we can give you the latest on what's happening and what's coming up next year. If you'd like to learn more or do more, please do come along and we have an open door for participation here at Drupal South. Now to kick the event off proper, I'd like to introduce Akhil Bandari, Engagement Manager at Salsa Digital. I'm sure Salsa really need no introduction, but they've really stepped up and been a fantastic supporter for our online series this year. And they are the keynote sponsor for today. So I'll hand over to you, Akhil. Excellent, thank you, Dave. As Dave mentioned, my name is Akhil Bandari, I'm an Engagement Manager at Salsa Digital and we're very pleased to be sponsoring today's keynote about Drupal 10 and beyond. Salsa Digital is a government company that really is focused on helping governments become more open, more connected and more consolidated. Salsa has been working past Drupal within the past decade and looking back, it's so much has improved. Especially in the past five years, we have seen a real growth of Australian government as it's adopted Drupal as its platform of choice to better serve digital citizens. My personal experience with Drupal has been working in government on Drupal sites on the business side for six or so years and more recently on the vendor side with Salsa. From Drupal 7 to 8 to 9, we've seen how quickly a digital product with a vibrant digital open source community can grow. And it's been amazing to see the growth of the Drupal community, especially around government, as well as the aim to do more and do better with Drupal. Now with Drupal 10 arriving soon, it makes today's event even more exciting. Especially to see where the community is going to lead Drupal today and beyond. Now, if you're not familiar with our speaker today from Drupal.org's issue queues, who goes by the handle L.A. Rowland, Lee Rowlands has been our reading's most prolific Drupal contributor over the past decade. He's joined Drupal's global security team in 2012 and has consistently been listed as a top 10 global code contributor ever since. Rising to the esteemed ranks of Drupal core committer in 2018. As many of you would be aware, while Drupal is a free open source software, the time and effort behind the scenes from people likely is absolutely critical to all of our projects, businesses and careers. Lee will touch on how you can start your own journey as a Drupal contributor in today's talk. And I'd strongly encourage you to join tomorrow's online codes rank, details of which are on the Drupal South website. Since Drupal 8 was released six years ago, we've seen Drupal mature into a product that's mission critical for organizations building complex large scale digital platforms. With Drupal 10 just around the corner, Lee will delve into what we need to be ready for and what direction the project is heading in beyond that. Thanks, Lee and over to you. Can I get my slides up please? Thank you very much. Okay, welcome everyone. So make yourself comfortable. There's a great program of sessions coming up today. And just looking through the list of attendees, I can recognize a lot of the names there. And I actually think that's a problem, but we're going to get into that later. So as Akhil said, I've been doing this for a long time and I'm not going to go into much of the detail here, only to say that if you want to talk to me about anything that I talk about here today, both today or in the future, feel free to reach out to me. My username is LA Rowland. The best place to get in contact with me after the event is probably on Slack. So if you head to Drupal.org slash Slack, there's instructions there how to sign up. And if you join the Australia NZ channel, you might be a lucky 500th member. We're getting very close. So another view of today's session. We're going to talk about two parts. First part is going to be largely informative, give you an update on what's coming. And the second half is going to be a bit more navel-gazing. There'll be some questions and I hope you come away with some things to my level. So we'll talk about where are we? Where are we going? And where do we need to go? So where are we? Well, as Akhil said, Drupal 10 will come out next year. A quick recap of the release cycle. 10.0 and 9.4 will come out next year. We hope to hit June 15, 2022 for 10.0. But if we miss that date, we've got a couple of fallback dates. The next one is August 16th and the following one is December 14th. Depending on whether or not we hit that June deadline, there may be a 9.5 in the middle there. By this stage, our plan is to reach 9.4 and 10.0 next year. 9.3 will come out next month. In fact, it's the beta release week this week and we encourage you to help test those pre-releases. There's a real bevy of new features coming and any feedback we can get now will make that as smooth as possible when we get to the 0.0 release. Drupal 8 itself is end of life. As Akhil said, it's six years old. It came out in January, 2015 and was end of life in November, 2021. To give you an occasion of what things were like when Drupal 8 was released, the latest iPhone model is iPhone 6. So it's quite some time ago. And if your site still relies on Drupal 8, then your homework when you get back to work next week is to get yourself to Drupal 9. There will be no more security releases for Drupal 8. Drupal 7 has got another year to go towards end of life. It'll be end of life in November, 2022. But it's been out since January, 2011, making it 11 years in total. There will be a paid extended support option available from vendors. And if you're interested in that and you haven't been able to move off Drupal 7 yet, I encourage you to search for Drupal 8.7 extended support plans. If you are on Drupal 8 and you do have some homework to do, updating between major versions now is much easier. This link will take you to the handbook page on Drupal.org. That gives you a run down a lot of the automated tooling you can use to make that process easier. And this is all provided and you're on Drupal 8. So the question many people may be asking is two years too soon for Drupal 9? If Drupal 9 came out in June, 2020 and Drupal 10 is coming out in June, 2022, is that too soon? And the answer is no, because we need to give people time to upgrade. So what's driving this? Well, it's basically end of life dates for our dependencies. And it's compounded by the fact that we're one major release behind Symphony. So the major release of Symphony at the moment is Symphony 45 and Drupal 9 is still on Symphony 4. So let's have a look at our security support for our dependencies. Drupal 8 was end of life in November, 2021 and it relied on Symphony 3. Symphony 3's end of life was November, 2021, hence the Drupal 8 end of life. And actually, Symphony extended the end of life for Symphony 3 just for us so we could get the life that we did out of Drupal 8. For Drupal 9, CK Editor 4 is what's driving the end of life. CK Editor 4 is end of life in November, 2022. So we want to give people six months to update, hence why the June release date for Drupal 10. Now, Drupal 10, we hope to get to Symphony 6 on. At the moment, a lot of work is taking place in the community to get to Symphony 5.4, remove the deprecations and upgrade to Symphony 6. We also are debating whether we will make 8.0 or 8.1, the minimum PHP version, Drupal 10, but it will be 8 PHP 8 of some form so there will be no support for PHP 7. And not surprisingly, we're gonna need CK Editor 5. Now, the difference between CK Editor 5 and Symphony 6 is quite significant. It's another two years of effective life for Drupal 10. So we're doing our best to get to Symphony 6. It will mean that we'll be jumping two major versions but we think that it's worth it. So that's where we are. The next question is where are we going? Let's have a little bit of a look at how the minor updates work. If you're running a site on Drupal 9.1 and you updated to that in December 2020, which was when it was released, its end of life is December 2021, i.e. next month when Drupal 9.3 comes out. So this means you must update at least once a year to remain on a security supported version. What we're proposing is to have regular two year majors. Now, at the moment, Drupal 8 had a four year life and Drupal 9 had a two year life. What we're proposing is to make that consistently two years. So Drupal 11 will come out in June 2024, two years after Drupal 10 and Drupal 12 come out in June 2026, two years after Drupal 11. We're also proposing to have an LTS release three months before the next major. LTS standing for long-term service. So in that case, 11.4 will come out in March 2026, three months before 12 and 10.4 will come out in March 2024, three months before 11. But here's the real sweetener of this proposal. We're proposing a six month overlap between the LTS releases. So that means the end of life at 10.4 will be September 2026, six months after 11.4 comes out and the end of life for 11.4 will be September 28, six months after 12.4 comes out. So under this proposal, Drupal 10.4 will come out in March 2024 and be security supported until September 2026, which means you must update once every two and a half years. Now, this is all assuming that this plan gets consensus and the issue ID for this is 3238652. But what we expect with this is that people will just jump from LTS to LTS. So they'll go directly from 10.4 to 11.4 and won't go to 11.3, two and one in zero in between. This is not dissimilar to what a lot of people do with Ubuntu releases and also with symphony releases. They jump from symphony 4.4 to 5.4 and so on. So there's some disclaimers here. This hinges on releasing Drupal 10 on symphony six and to a lesser extent, PHP 8.1. By the time that end of life of 10.4 comes around, PHP 8 will be end of life itself. It also assumes that some of our other dependencies play nice. So as you saw before, we also rely on other third party libraries such as CKeditor, but there's also things like Guzzle and Doctrine. And if that's not the case, then we might need to do some things creatively to continue to support those after the end of life. For example, we do some creative things behind the scenes to support multiple versions of PHP unit and we may need to do similar to support multiple versions of our other dependencies that don't have such fixed end dates like symphony does. So with that distant future aside, what's coming in Drupal 10? But actually this is wrong and we need to stop thinking this way. We instead need to think about what's coming in 9.3, which is out this month. Oh, sorry, which is out next month. Because we built Drupal 10 in Drupal 9 and we'll build Drupal 11 in Drupal 10. So what is coming in Drupal 9.3? Well, the big feature is PHP 8.1 support. PHP 8.1 will be released this month, it comes with new language features and a lot of work has gone on behind the scenes, hundreds of issues to remove deprecations emitted from core for using language features that would be removed. So this means if you want to use one of those new PHP 8.1 language features, you'll be able to run 9.3 on PHP 8.1 without core emitting any deprecation errors. You might not get the same mileage from Contrib, but the community will lift those up pretty rapidly like they have with PHP 8. Another feature coming is Bundle Classes and this was described by Moesh, the maintainer and author of Trush as one of the biggest features to come to Drupal in a long time. This lets you write a class to use to encapsulate your business logic and tell Drupal to use that class whenever you're dealing with a bundle of that type. So for example, you could write a class called recipe and declare the recipe class to be used for the recipe content type and then any logic that you have that relates to recipes can go in that class. This means you can use the methods on that class in twig files and skip the need for pre-processing, but it means you write a lot cleaner code and you'd be able to add a lot more test coverage for your functionality. Another new feature is the Manage Permissions tab. This will sit alongside Manage Fields and Manage Display and I'll talk about that in a bit more detail shortly. Another developer-facing feature is Generic Revision Access. So previously, if you wanted to check if a user had access to View or Revert or Delete or Revision, you had to do some special juggling based on the entity type. So if it was a node, you'd have to say, okay, do as the user have these permissions. If it was media, you had to check the difference in permissions and that was just the ones that you knew about. With this new API, you can simply call access on the entity and pass in new operations to deal with viewing revisions, deleting revisions and reverting revisions and you'll get back an access result. One thing we hope to ship is CK Editor 5. This will ship as an experimental module and because it's an experimental module, it doesn't have to be in Drupal 9.3 before the alpha and beta deadlines. So the beta deadline is this week and if we get this to alpha level, beta level stability, we'll still put this in after those deadlines. Being an experimental module, it's more for people to test it rather than to be used in production. We're also very close to marking our two new themes stable. So Olivero, the front end theme and Clearo, the back end theme are very close and one of the final blockers for Olivero went in overnight. So hopefully we're very close to that point. Now a couple of asterisks is here. These are all things going to plan. So this is the manage permissions tab. As you can see here, I'm looking at the recipe content type. We've got the manage fields, the manage form display tabs and we're showing just permissions that relate to the recipe. You'll also notice that is just permissions from the node module. There's some permissions from layout builder and from content translation. And this is made possible by some new improvements in Drupal 9.3 to do with the conflict dependencies between roles and the permissions and the things that define those permissions. So previously, if you enabled a content type and then you went and gave some permissions to a role for that content type and then exploited your configuration but then deleted the content type, those permissions would hang about in your role forever. Now with this new configuration dependency between permissions and the things they depend on, the role is able to update itself to remove those permissions when the content type has been deleted. And that also means we can do really cool things like this by interrogating that information. We can ascertain which permissions depend on the recipe content type and show a smaller cut-down permission form just for that content type. Here's a screenshot of CK Editor 5 and this is using the Linkit Contrib Project. The Linkit Contrib Project is a very popular addition to CK Editor that gives you the ability to search for links to existing Drupal content. And the great news is this has already been ported to CK Editor 5 as a proof of concept that the APIs that have been written on the Drupal side can support some of the most popular Contrib projects. It's also using Drupal's new Autocomplete component, which is a new component that we've written that lets us get rid of jQuery UI but I'll talk about that a little bit more in the future. So beyond 9.3, what's coming in 9.4? Well, if we miss marking Olivero and Clairo stable in 9.3, we'll definitely get them in 9.4. We also plan to deprecate the forum, HAL aggregator in QuikAd modules and move them to Contrib in Drupal 10. So they'll still be in Drupal 9.4, but they'll be deprecated and that will provide you a link from the admin page, hopefully telling you what to do to upgrade. We also plan to bring in a new experimental module called Decoupled Menus module and this adds JSON API support for menu links, not just for menu links defining content but also menu links that come from out of modules, et cetera. Because of the new revision access incoming in 9.3, this unlocks expanded JSON API support for revisions. So at the moment, JSON API can only fetch revisions of media and node entities. With those changes in 9.3, this unlocks the ability for us to be able to expand that to any revisionable entity and it also unlocks us the ability to add UIs for those. If we have a look at the generic revisions UI feature, this gives us the ability to add the same sort of UI that you see for node, so the ability to compare revisions, revert revisions and view previous revisions. Previously, this was only possible for node unless you added some contrary projects and those contrary projects were all doing things differently. This gives us a nice consolidated API to make it much easier to add that. And as I mentioned, there's a new auto-completion dialogue component that's being worked on and this is to help us move away from a JQuery UI which is now end of life. So some of these have got stars on them, that's all things going to plan. I've got a screenshot here of the new Olivero front-end theme. We hope to put this as the default front-end theme in the standard profile, which is still currently Bartik. Bartik was created in 2010, 2011. So it's very old, it's getting very long in the tooth and this new theme, Olivero, is a great foot forward to Drupal for people evaluating. So all those things coming in 9.3 and 9.4, we expect 10.0 to be boring and this is by design. We, for those of you on Drupal 7, this is probably cold comfort, but we've learned from the upgrade process and so 10, just like 9.0 will be the previous LTS minus deprecations. And it'll be easier again to upgrade. The release cycle between 8 and 9 was a four-year period and between 9 and 10 will only be two. So there's much less deprecations to remove. In fact, here's a chart from Gabor's presentation at Drupal Con Europe, showing the type of deprecations and how we can remove them and as you can see, well over half of them can be fixed by automated tooling. So what about in 10.x? This is where the new features start because in this way of thinking, we build Drupal 11 in Drupal 10. One important initiative is the automatic updates. At the moment, they're making some great progress. They've already got the ability for you to see public service announcements in your admin UI. They've built a whole API to perform readiness checks to ascertain whether your site's ready to upgrade or not and contrary projects will be able to hook into this. They've built the ability for Drupal.org to sign an update and for your site to verify that update to prevent man-in-the-middle attacks. They've got the ability to apply updates with rollback and the final piece of the puzzle is a composer-based updater. So all of the features they've delivered are available in the Contrary project in the 1.x branch and work is underway for the composer updater in the 2.x branch. Here's a screenshot of the designs and a lot of people in this call will probably be thinking that this isn't for them. If you're on GovCMS or you're on Acquio or Lagoon or one of our clients, for example, you don't apply security updates directly to production. You normally apply them as a locally or in a development environment and you go through a dev stage pod pipeline. But the automated updates is still very important to the project. And we're gonna explain that in a little bit more detail later. Another important initiative is the Project Browser Initiative. Work here is also happening in Contrib and there's a team that meet weekly in the Project Browser channel. This will build on top of the automatic updates and work with composer under the hood. But it'll provide you with a UI in your site to be able to browse modules and themes from dupal.org, filter them, sort them, look at the number of installs and the number of stars. And again, a lot of people in this call will probably think this isn't for them. If you don't install sites on production, you use composer and other things and you do go through a dev stage pod pipeline. But it's still very important to the help of the project. And as I mentioned before, we'll talk about that in more detail later. Another initiative, easy out of the box, is focusing on getting the layout builder, media and clearer enabled by default in the standard profile. Now I've made my opinions on the standard profile well known. And if you're interested in hearing more about that, this session I gave a trip to South Gold Coast called at 16 years of age, does Drupal have an identity problem where I talk at length about the issues I see in the standard profile. But since then, the Yamami profile has shown us what is possible with install profiles in core. And a lot of people in this call, again, will probably be thinking, I know how to enable layout builder. I know how to configure media. I know how to turn on Claro. But this is more aimed at people that are new to the project. We want them starting their sites on the good foot. At the moment, the article content type ships with an image field, which is something we haven't done for years. Everything's been focused on media entities for quite a long time. Another important project is the starter kit theme. Here's the Drupal NID for the meta around that. If you've been working with Drupal long enough, you probably remember the Zen theme, which was very popular in the six and seven days. It had commands for generating a new sub theme. And it's basically the same concept, but in core. What this will let us do is deprecate and remove the classic and stable themes. Now at the moment, most of you are probably basing your themes off that and thinking this is a bad thing. But there's actually a problem with the classic and stable theme. And the problem is if we find a bug in the markup and we have found several, we can't actually fix it in core because we've got a markup guarantee. If we change that markup, it might break your site. So we have to just tolerate those bugs and we try to fix them between major versions. And if you move from Drupal 8 to Drupal 9, you'll probably notice that a new theme appeared, Classy 9, which was Classy 8 with the bugs fixed. And that way it's basically, you have to make that decision to move from Classy 8 to 9 and fix any bugs that might come out of that upgrade. So having a starter kit theme will let us fix bugs in core because every site that's using a theme based on that will be based on that point in time and we can fix bugs in the starting point so that any new sites that come online don't continue to have those bugs. All sites will have to take those changes manually, but at least we won't be breaking other things. We're still continuing the death march to remove jQuery. And we've actually turned on no jQuery ESLint rules now. This issue is a meta tracking all of the detailed ESLint rules. And there's lots of short, small issues underneath this that are easy to get involved with. They're great for tomorrow's code sprint. So that's where we are and where we're going. Now to the more navel-gazing part of the talk, where do we need to go? We've got quite a few questions here and I don't have the answers to all of them, but I hope some of these questions spawn some good question and answers. And if you'd like to talk about these with me further, feel free to get in touch as Dave mentioned via the chat functionality of the conference or after that via Slack. So my first question is, if dependencies are driving our end of life, what's getting off the island the right thing to do? Was bringing in all those external dependencies at the expense of end of life worth it? And does the fact that Drupal 7 is still kicking indicate we got it wrong? Now to an outsider, this may seem to be the case, but the reality is core development is done by a small pool and they're stretched thin as it is maintaining the code that we wrote ourselves, let alone adding in other code that we don't even have to think about at the moment. And this leads me into a bit of a discussion around how core development works. A lot of people think we have predefined targets or predefined priorities and we work towards those in an organized fashion like you would with the sprint and we ship our releases. But how it actually works is that organizations and individuals bring their ideas and they progress them to fruition. Now Acre is the exception here. They fund a lot of initiatives that probably don't help their business but do help the ecosystem and we're grateful for that. But say for example Lullabot here, that Olivero theme, they identified the need for a new theme in Drupal 9 and they brought that to fruition. Some local examples, Service New South Wales, the New South Wales Department of Customer Service and my employer previous next have driven a lot of the big changes in 9.3 like the generic provision support and to a lesser extent the bundle classes. And I realize that not everyone knows enough about the guts of Drupal and how core works to contribute patches but there are other ways to contribute and you can always sponsor someone if you have an idea that you'd like to bring to fruition. Someone who's recently become a regular contributor at Drupal Core is Max Bognowsky. Max is based in Sydney and came along to our sprint in August in Drupal South and since then he's become a major contributor. And since doing so, one of the things he found is this. I'm rapidly discovering that what I thought was a large group of people working together to guide Drupal Core is a lot smaller than I once thought because the reality is contribution comes from a small pool and core nowadays is very vast. There are subsumstances in core that I can count on one hand the number of people who have a deep knowledge of how it works. In fact, there are some parts of core where the loss of a single individual could cause progress to grind to a halt. Which brings me to another quote. I've said this before, but I think it bears repeating. For an ecosystem that provides gainful employment to so many, so much work falls to so few. This is perhaps most evident if you look at maintainers.text. This is a text file that ships in Drupal's code base that lists the individuals responsible for each of the specific subsystems. There's some quite large holes in there at the moment. There are some subsystems with no maintainer listed at all. People pitching here and there to help with bugs in that component. But if your business relies on this piece of core, maybe you could step up and help out. Or perhaps you could sponsor someone to do it. All of this is taking place against the environment where contributions are down. If you've read Dries's blog post or you saw his presentation from DrupalCon Europe, you would know that there's been a 10% decline in individual contributors over the last 12 months and a 2% decline in organizational contributors. Now COVID is a factor here, but there's also a smaller pool of people. All the while, businesses are booming in the Drupal Business Survey 2021. Well over two thirds respondents indicated they felt the business was going to grow and quite a lot of them thought it was going to grow significantly. Now, if you look at the Drupal 7 and Drupal 8 statistics for usage stats, you'll see that there's still quite a lot more Drupal 7 sites. The business is still booming because we're building bigger sites, more complex sites, but just less of them. And this is perhaps most evident if you look at the usage stats for the Drupal 7 Contrib Project jQuery update. It still has more installations than Drupal 8 and 9 combined. So to try and address some of this imbalance, the Drupal Association have introduced the Certified Drupal Partners program. Trying to focus on makers versus takers. Their attention here is to recognize organizations that contribute back and award them with Certified Drupal Partners status. There are tiers of status, or there are tiers of recognition. And those that have been recognized will get stronger exposure throughout Drupal.org versus those who haven't, who will get none. Now contributing to Drupal is often something that is attractive to developers. Whilst all this is happening, it's getting harder and harder to fill jobs. If anyone's hiring lately, they would know it's hard. And likely here in our Australia-New Zealand community, it doesn't seem like the pool is growing. As I said at the start, I recognized a lot of the fact that it names you on the contributor list, in the attendee list here. And I think that's a problem because we're not seeing new faces. At the moment, organizations like Oxide, Previousnext, Salsa, the New South Wales Department of Custom Service are all hiring. If you are looking, please check out the Australia-New Zealand Jobs channel. One of the things that's making hiring harder are the barriers to entry. There's a blog post today from DrupalizeMe about the things that you need to become a Drupal developer. If you read that list in your experienced developer, you probably tick them off and go, yes, yes, yes. I'd encourage you to go back and look at that as an inexperienced developer and see how many things and how much pride knowledge is required just to be productive. If I think about how I got started, luckily I was building sites for local businesses. But as we get to more and more complex projects with bigger budgets, there's less opportunities for those smaller organizations to get into the community. Now, this is where initiatives like Project Browser and Automatic Updates and Easy Other Box help. They help make Drupal more attractive to new organizations and they bring in community members that can help grow the community. Project Browser, for example, at the last Global Training Day I ran, I avoided talking about adding modules to the site because it's a minefield. Now, adding modules used to be a major selling point of Drupal. There's a module for that. But now it's too complex to cover in a single day's training. All the while this is happening while JavaScript is eating the web. There is a myriad of JavaScript-based CMSs and a couple of CMS as a service offerings are coming up fast behind us, like Contentful, Prismic and Sanity. Now, I spoke about this topic at length after a couple of days this year and did a detailed review of those offerings. So I encourage you to check that out if you're interested. But entry to this space is much simpler. Hosting is easier and I have great starter kits. 10 years ago, a small agency could host Drupal 7 on a C panel and it was easy to see why. Nowadays, it's more and more difficult. And as a result of that, some of these offerings seem more attractive than Drupal. So if JavaScript is where new developers are starting out, how do we as a community build a bridge to them? There's a couple of menus initiatives that step in the right direction. We've already worked out how to ship NPM packages from Drupal.org. We've worked out tooling for non-PHP projects. We've enabled GitLab features like group GitLab pages and CI. And we're already using this for some core JavaScript libraries like the once library, which is replacing jQuery UI and the auto-completed dialogue that I spoke of before. We have a great headless offering in JSON API. But there are many places where the API is a second class citizen to theme and form APIs. Just ask Stuart from Reality Loop who's doing great work with drugs developers. So I'm gonna leave you with one final question. What can we as an Australian New Zealand community do to address some of these issues? What can we do locally to attract new talent to the project? Where are the entry level conferences? My first conference was a Drupal camp in Brisbane in 2010 and it was free. Events like today are great, but is the cost inhibitive to people considering Drupal rather than for the committed to it? I know Vlad's doing some great work in Brisbane. He runs the meetups out of the TAFE and he's organizing a camp in February next year. And similarly, Murray does some great work running meetups out of the TAFE in Sydney. I know the New Zealand Meetup Committee, we're talking about running some hack days to build some sites for NGOs as a way to onboard new people to the project. So I'd like to talk about this more with you and a good place to talk about it would be at the sprint day tomorrow. Max became a regular contributor after the last one and maybe you could too. Next one, thanks for that, Lee. So I think you covered a lot of ground there and there's a lot of exciting stuff in store with Drupal 10 and beyond. I think that managed permissions tab looks like it's gonna be a new favorite already for our crew. And I think overall, I know from our perspective as a business, we're loving this new era of modern Drupal and the release roadmap. Just looking, thinking back to the start of your talk, those dates you ran through, are there any really real key dates that you really want people to pay attention to? You think should be drivers for activity? Yeah, I think so. I think the first one is obviously coming up soon which is the 9.1 end of life. That will be early December when 9.3 comes out. So if you are on 9.1, you can move to 9.2 now which will have another six months of security support. Obviously the June 2022 for the Drupal 10 release is very important. There are a few things that we still need to do. So if you are interested in it, you have some spare bandwidth to help, please reach out to me. I am aware that everyone is very busy at the moment. It's a very busy, lots of work on. But yeah, those are probably the two key dates. Some things that you can do that probably don't seem like, don't take as much investment of prior knowledge is helping with that CKNF5 testing. We really hope to get that experimental version in 9.3 and that will enable people to enable it in their Drupal 9 sites and run the upgrade path because there is some work to upgrade your input format configuration from 9.0 to 10. And make sure that they don't get any issues and if they do report those issues, that's a really critical part of that. Intuitively, we've seen that the main issue with these major upgrades is to do things that make major data changes and that's definitely one of those. So the more testing we can get before then will help those that come after us to have a smooth process. Looking at their range of new features coming out, are there any that you think are particularly relevant or that you're really keen to make a big splash? And conversely, are there some features there you think are less important for maybe a more experienced Drupal agency or dev? Yeah, I mean, I think I touched on that a bit in the presentation. I think some of the things in there, there is the chance as experienced developer, you look at and go, well, I'm never going to use that. But I think I encourage you to assess that feature through the lens of a newcomer to the project and then think if it's important. I think if we need to continue to grow the project for its long-term sustainability, and we definitely do, then we need to be thinking about those that are new and to use sort of a breadcrumb analogy in leaving a trail behind us for those that come after us and things like automatic updates and project browser definitely fit into that category. But also that easy out of the box initiative, the people out there still starting with Drupal that are installing it and getting Bartik as a start and then image fields on article content types and thinking, okay, that's the right way to do things. I'd hope they install YMMAMI, which is a lot better, which is using things like Layout Builder and all of the new fancy things. But the reality of this, that says demo do not use and then you're supposed to uninstall it and start with standard or something, even lead us to maybe minimal. For the experienced developers, I think the two, the bummer classes is definitely a game changer on a project that I work with at the moment with some long-term Drupal developers. I've been around on the project for probably 10 years or so. We've added that patch already to the sites running 9.1 and it's instantly changed the productivity of the project. Things that used to be scattered, maybe in a hook here or a tweak template there or a pre-process, they now go in that class. You can write a unit test for that. It's a real game changer, as Moe said. Also the revision access stuff, I think is really important. If you're trying to do anything a little bit out of the ordinary with JSON API where you need to have access to revisions. So some of the stuff like Stuart's doing with drugs is building decoupled editing experiences and obviously being able to access all the data that the forms and themes can over JSON API is important. So I think those features will unlock a lot more experimentation and will improve our offering in that space. These feature releases that are driving the roadmap that we're all super keen for, they do depend on consistent contrib, right? Yes, yes. And increasing that core contrib team and contrib across the board. And you mentioned we're all busy and yeah, we are. We are all busy. But your own company and your own personal practice, you've consistently maintained a high level of contribution whilst getting the business done. What's your secret source? How do you unlock that conundrum? How do you make it happen without letting your day-to-day drive out that desire to contribute? I think I've been doing it for a long time as it probably comes second nature to me. But I think insight from people like Max who just done this recently, made this transition recently would be helpful here as well. I think what Max said at the time was the sprint was the kick that he was needing. But I think just getting involved is the first step. There's quite a lot of people and they're all involved and knowing who's who in the zoo helps. And I mean, I'm happy to find and point people to who the right person to ask is because I think often knowing who to ask is part of the problem. We have some initiatives like Bug Smash which is a great way to get involved. Personal plug for that initiative that it's based in an Australian time zone, Australian New Zealand time zone actually. It's also friendly to India and it's the only initiatives that is. Most of the other initiatives meet at stupid o'clock in the middle of the night. We have meetings every second Tuesday at 2 p.m. in Australian standard time which would be 4 p.m. New Zealand standard time, 5 p.m. Daylight time, 3 p.m. Sydney time and I think it's 9 a.m. in India. And basically we plot how we're gonna smash bugs in core and we've made some huge inroads. I think we're very close to a 10% reduction in the number of open bugs in the London 18 months. So it's a great way to get involved. It's a very approachable group. It's a small commitment of time come along for one hour on Tuesday and chat with people and you may go away with something to do for homework. But if you do get stuck, there's a really approachable group of people there that can help you with the next step. So often you might find an issue, you might write a patch and it might just sit there waiting for needs review. There's a real good culture of review swapping in that initiative. So if you want someone to review your issue, you sort of post with a particular emoji, they'll review it and then you can review theirs and that's how sort of things move forward. But I think it also needs to be set at an organizational level. I'm lucky in working in an organization where it's part of our DNA and I'm also lucky with the clients that I work with but also family committed to the project and a lot of them contribution is in their DNA. So if we're working on a feature, we might say in the onset, okay, we think this has got merit for the whole project and we'd like to open source it. What do you think? And overwhelmingly our clients will say yes. And I think that's why we see features like the revision access stuff that service in South Wales have been checking. And it's taken a long time. We've been re-rolling that patch since probably 8.4, 8.5. It's taken a long time to get it in. We'll talk in maybe three years there now. But as a result, the final patch is better. And yeah, I'm sure that project will be looking forward to getting those patches off there and just running with straight up core. Similarly, some of the universities that we work with, a lot of the things that they require aren't unique to their business and they have implications for other universities. So we will say, okay, you get this much functionality out of the module by default, you want to do this extra little bit. Do you have any objections to making that part of the project? And we go through that process and release that. And then everyone, different benefits. So I mean, to use the cliche, the rising tide with all boats. Yeah, in terms of that kind of organizational or business support for contribution, you touched a little bit on the DRIF associations push for a certified partner model. Do you think that's gonna help get those businesses and maybe some of those client businesses more on board with Contra? I hope that it does. Yeah, I think looking at it at the moment, there are quite a few Australian organizations that will qualify for is my understanding. And I think it's recognition that they deserve. I think at the moment, every six months at a DRIF note, they might see their logo flash up on the slides. And I think this is kind of extending that further. And that goes also to organizations that aren't agencies. So I think at the last DRIF note, to see some of our client logos on that screen is also really fulfilling. So I think this will continue down that route. Just to flick over to one of the other major things that you touched on and as a big issue for us is getting talent into Drupal, getting new people on board. Do you think that the moves towards decoupled, better handling for JavaScript, that is a door to bring people new in? Or do you see that as a kind of a side issue and we need to do more with your kind of core traditional Drupal? I absolutely think JavaScript is the future. And I talked about this at length at the couple of days session, but I think some of the work that Stuart doing in this space is the kind of place we need to be go. That's obviously geared towards Nuxton view, but we need similar for React and Next. And what I like to see in that space is a lot more collaboration. So Stuart's obviously open sourced all the drugs, which I thank you for doing so. What we see a lot of decoupled solutions is people are off building their own things off to the side. And I'm sure they're coming up with some great patterns and some great solutions. We're thinking about ways that we can componentize those and make them small utility components so that other organizations can continue to build and improve those. And so part of that is continuing the way that we collaborate, which is on Drupal.org. You've typically seen with the project that modules that live on GitHub are harder to find and harder to get collaboration than those that live on Drupal.org. And so the Drupal session making GitLab available, the full feature set for non-PHP projects is important in this space. Because I think it keeps the community together on Drupal.org, but also gives us all the benefits that you would get from somewhere else. So we can ship packages to NPM. We can have GitLab pages for documentation. We can use GitLab CI for testing that isn't running PHP unit and linting, et cetera. In terms of does that attract new people to the community? I'm not sure. And this is a tricky space, I think. One of the things that we've been doing when trying to recruit is actually going into those communities to try and find people that have front-end skills that are interested in looking for work that aren't wary of Drupal. And we basically, no Drupal knowledge required. This is kind of the message that we're sending because a lot of the front-end tooling, which I think Ricky spoke at at the last session that we have here is about generic front-end tooling, not Drupal specific. There is some prior knowledge required of Twig, but it's not that to say JSX. And one thing I did notice in reaching out to those communities and looking into their job boards is that the volume of looking for work versus hiring in our community versus compared with that in, say, Gatsby or JavaScript communities is completely opposite. If you drop into the jobs channel on Slack, it's just a sea of we're hiring, here's a job, we're hiring, here's a job. Whereas if you drop into the contrasting channel in, say, some of these JavaScript communities, which tend to be, they use Discord, it seems to be the other way, there's a lot more on the valve for hire. So I think whilst it's hard to find people, I think it's still a good career choice. And I think if we could somehow convey that to people that get past that initial learning curve. And I think Nathan said yesterday that you've got to push through that first, six, 12 months of the learning curve to realize the real value out of Drupal. If we can maybe buy those secure jobs is how we get people to push through that. But yeah, I'm not sure. I think the work that we need to sort of do some more advocacy work, I think, going out to communities, proposing sessions about Drupal for things that we wouldn't normally talk about. I've tried to do that. I've given a couple of sessions at React conferences but focused on React. I have submitted some things for those conferences with a Drupal theme. I submitted one for, say, Jamstack. Drupal has a decoupled CMS because that's their whole business, right? Is decoupled CMS is backing Jamstack. But unfortunately, I think we've probably got a bit of a stink on us. We'll have to see how we go there. But I'd like to see more people doing that and encouraging people that... I think it's not your grandfather's Drupal, maybe, is the message we have to go with. Yeah, I think that's a fair comment as well. I think Drupal has really made a huge investment and no small amount of pain and modernizing is architecture and its approach. And it's not your grandfather's Drupal anymore. There's an opportunity for us to push forward and really exploit those benefits that we've worked hard for. Yeah. I think we've got time for maybe just like one more quick little question and this is kind of more of a personal question. You've been involved for a long time. You've done a lot of really good work for the Drupal community. What keeps you engaged and motivated? What drives you forward? That's actually an easy question. It's the opportunity to work with some of the smartest people in the world. The people that are involved in contribution without a word of lie are some of the most technically brilliant people that I've ever met. Or many of them I've never met. I've only met virtually. But I think that intellectual simulation is something you just can't get from anything else. And the ability to learn from some of the brightest minds out there, effectively at no charge and the other than your time, I think, is pretty compelling. I've made no bones out of the fact that when I started contributing to CORE back in Drupal Seven days, there are a lot of things I didn't know. I didn't know what an interface was with PHP. I didn't know a lot of modern OO programming paradigms. And I've learned pretty much all of that by putting up patches and having someone who's an expert review it and learning from their knowledge. And now I get to pass a lot of that on, which is good. But I think you can't put a price on the amount of stuff that I've learned just from other people giving me constructive feedback on my things that I've done. So for me, that's what keeps me coming back. That's a great answer. That's a great incentive for anyone out there wanting to get involved, I think. Devs, documentation, front end, UI, UX, whatever. Thanks for your talk. No worries. Just got one minute left. I know you're back tomorrow for the sprint. You're mentoring this online sprint tomorrow. So if anyone's got any questions or they or wants to follow up, I think it's probably a good opportunity. On behalf of the community here, local community and internationally, I'd just like to say thanks. We really appreciate your work. Yeah, thanks. The role you've played on the project for so long and putting yourself out there and being so available and talking so much. It's really inspirational, it's motivating. And yeah, just to see what can be done, I think we should be all proud of the project and big thanks from all of us for everything you've done. No worries. Thanks for the opportunity. My first presentation was in 2010. And I drove down from Bundaberg to Brisbane with no idea what I was in for. And yet to come to be able to speak as a keynote is an absolute honor. So thank you very much for the opportunity. Wonderful. Thanks very much. And it's time for us to wrap up the session and the next one is starting in a few minutes. So choose your channel and we'll see you in there. Wonderful. Thanks again, Lee. Thanks, bye.