 All right everyone, welcome to DrupalCon Amsterdam. It is my pleasure to be getting this all invited here and welcome to DrupalCon. Today we're going to hear from 10 different leaders of the Drupal community, all of whom are making Drupal better in different ways. We hope to have time for questions at the end. So if you have questions that you would like to ask of any of these leaders in our community, please use the hashtag Drupal Initiatives. And we will be asking questions as many as we can at the end. My name is Drew Gordon. I'm the director of developer relations here at Pantheon. And I'd like to start by just recognizing the fact that all of us are here to learn from each other, to get better at what we do, to have some improvements. And I'd like all of you actually just to take a moment to look to your left and your right in front of you, around you, and welcome the people who are next to you. We're all here together. So take a moment. Do it. Go on to everyone. Please welcome everyone. Hopefully, all of you have just made some new connections. Remember these people. We're all here. Talk to them. We're all here to learn from each other, help each other. It's a chance that you can help the person next to you, or they can help you. So keep these connections alive. Talk to them, not now, not during the keynote. But please do it sometime this week. In that spirit, I also want to say thank you for making us feel welcome. So I worked with Pantheon. This is our first DrupalCon, where we have European data residency. We are really excited about that. We started this in the summer. And many of you have already reached out to us, and we've started working together. And we're super, super excited and want to say thank you to all of you who have done that. If you haven't yet started working with us, we would love to talk to you. We have a booth here. We're printing these wonderful shirts. Please come by, have a conversation with us. We would love to talk to you and give you a shirt as well. In Drupal we have this saying that you come for the code and you stay for the community. And that's certainly been my experience. I'm really excited about the fact that here today we have 10 really awesome people who are all, again, helping Drupal get better in different ways. I hope this is a new tradition to help lead future DrupalCon's, where we hear, again, from the community leaders. So please join me in welcoming to the stage our 10 community leaders, starting with Tara King, my friend and colleague. I am Tara, as Drew said. I work at Pantheon in our developer relations department. You probably know me from the internet of Sparkling Robots on Drupal.org or Twitter. I live in Albuquerque, New Mexico in the US, but today I'm here to talk to you as a leader of Drupal Diversity and Inclusion. Drupal Diversity and Inclusion was founded in 2016 by Nikki Stevens. This is an entirely volunteer working group as everyone is in Drupal in some ways. And we are here to continue the conversation about diversity, equity, and inclusion in the Drupal community, as well as to provide a safe space to have that conversation, and also to support our underrepresented and marginalized colleagues in Drupal and in tech generally. In 2019, we're working on speaker diversity. We know that having more diverse voices on stage is gonna have a ripple effect into the audience. We're gonna have more diverse voices there, more diverse talks, and overall a healthier and stronger Drupal community. So to that end, we started wondering, what can we do to help with this problem? We hear a lot from camp organizers. Camp organizers want to help as well, but it's hard to recruit when your network doesn't look diverse. It's hard to recruit when your organizing team isn't diverse, and it's a volunteer organization, there's limited time and resources. So that's one side of the puzzle. On the other side, for the speakers, well, I mean, we all know it can be very intimidating to get up in front of a group and speak, but when you're marginalized in a community, that feeling is really amplified. It increases the self-doubt, it increases the imposter syndrome, and it can be really hard to speak in an event where you're not totally sure that you're welcome. Additionally, for underrepresented speakers, there's often barriers like time, money, family care, all kinds of issues like that. So how can we bring these groups together? Mark Drummond, who's from Drupal Diversity on the far side, and Jill Binder is from the WordPress community. They met in 2018 at Drupal Con Nashville. Jill had been doing speaker workshops in the WordPress community, designed to improve speaker diversity, and wanted to share her knowledge with the Drupal community. So we talked, and it turns out her workshops really work. In 2018, she gave them in 12 different cities in six countries. Those communities went from 10% or fewer underrepresented speakers to 50% or more. It was a huge impact in a very short time, very lightweight. So we knew we wanted to bring this to Drupal, but we needed funding. So we talked to Pantheon, who provided half of the funding as a match, which meant we needed our community to step up and finish the fundraise. We used Open Collective and had over 40 individuals and companies in the Drupal space donate money. It was an astonishing effort. We are super happy. This is only a few people who are involved, but once we finally got the funding, we were able to hire Jill to do the workshops. The workshops covered how to write a pitch, how to pick your topic, your bio, your speaker bio, all of that stuff. So anything you really need to do, a Drupal camp or con successfully, as well as a few things that are targeted specifically underrepresented people. Again, going back to that sort of exaggerated imposter syndrome effect that can happen. Jackie here is one of our attendees. She is from Los Angeles and she's a first generation American. She always wanted to speak, but she felt like she didn't really have anybody that looked like her to inspire her to do so. But after the workshops, she's now really excited to submit talks all around Los Angeles about her specialty of email marketing. Overall, we saw an increase in speaker confidence of 66%. There's just a huge, huge improvement. 30% of our attendees are ready to give talks tomorrow. 30% are getting ready, they're on their way. And 20% said they would like to bring this back to their own community to be able to spread the impact of this work and get more voices on stage. So we're planning a workshop you can sign up to. It is basically three short hours to help you have all the tools you need to give this workshop in your local community. We do find that an underrepresented person giving the workshop helps because people can see themselves reflected and represented, but everyone's welcome to attend. It's gonna be on Saturday, November 16th. It is on Zoom, so you can attend anywhere in the world. It's gonna be at seven o'clock Amsterdam local, but anyone can come. You can sign up there, bit.ly-ddi-ams and yes, the capital letters do matter. So you can sign up for that. We highly encourage everyone. We also have a session tomorrow. We're talking about this initiative and many, many other things we're doing in Drupal diversity. It's gonna be at 4.15 in G105. Please come down. We're gonna have a lot of time for question and answer. We wanna hear your thoughts about what will make this community healthy and happy. That's it. Thanks so much for your time. Happy DrupalCon, everybody. Hello, Ron. I'm Sean, I'm Sean B on Drupal.org and I'm one of the leads of the media initiative and also one of the maintainers of the media and media library module in core. And I've been doing this together with Christian Fritsch, Phenoproxima and Marcos Cano. I got inspired to work on the initiative back at DrupalCon Dublin and I've not been doing a lot of core development before that time, but I did always want to contribute more. So since the lack of support for media in DrupalCore was always kind of frustrating to me, I thought it was a good place to start helping out. And I got really overwhelmed at the start. It was, I really feel like I jumped in the deep end, but over the years I got to work with a lot of smart and inspiring people who really helped me understand Drupal a lot better, but also became a better developer and programmer at the same time. And I think that's also the reason why I love working on core so much, even though the process can be quite slow and painful at times. I think the people you work with are amazing. It's really some of the best out there. And also the fact that you helped shape the future of Drupal is really something I enjoy. For the media initiative in particular, I love the fact that it's very visible work. So we have a lot of user-facing features. And since I studied interaction design, I really love working on things where humans and machines interact. And also the fact that a lot of sites could potentially use the media module is also something I really like to work on. From a technical perspective, I love the complexity of the module. So we have custom entities, custom plugin types. We have widgets, a lot of super advanced AJAX stuff. And yeah, there's really a lot to learn and a lot to enjoy at the same time, really. So I keep learning a lot. And since we have a lot of user-facing features, we also work a lot with the UX and accessibility teams. And working with them really helped put more focus on UX and accessibility in general. And that not only benefits the initiative, but also the work I do besides Drupal Core. As an initiative, we try to get together a lot. We did some dedicated sprints in Berlin and in Barcelona. And we also try to meet up at things like DrupalCon and Dev Days and stuff like that. And we get to share ideas, we get to collaborate in real life and build consensus at times. And it's not only very important and helpful, but it's also really fun to do. For the last couple of years, we tried to get the media library module ready. We started last year with a sprint in Barcelona where we got together with some core committers, people from the UX team and product managers and rethink and redesign the library with all the lessons we learned in the past. And one thing we decided on was to design the new media library with some constraints in mind, which is also not very Drupal-y instead of trying to solve all use cases super flexibly, we just tried to focus on the most important things and just do them really well. And that really benefited the end results, if you ask me. So for the future, we are first trying to get the media library module stable, which is very close, but I'm not really sure we're going to make 8.8, but hopefully we do. And after that, we have some important UX and accessibility improvements to make. So that's also something we really want to work on for Drupal-9. And after that, we tried to get the media and media library module enabled in a standard profile. And since a lot of people got together and worked so hard on the media and media library module, I think it's also important to thank everyone. I'm really proud of what we accomplished and proud of all the people who worked on it. So a big thanks to everyone involved. But at the same time, I also want to ask everybody here to try and help us out where you can, not only writing patches, but also just installing the module, testing it, seeing how we can improve and give us feedback. It's really important. And yeah, hopefully you can help us out. So thank you. Workflow initiative. I want to start by thanking everyone who's been involved with this initiative for the last couple of years. It's been a lot of people has helped in all sorts of ways. If you're on the screen, or if you know that you've contributed in any other way, please stand up. Andrea, I see you. Come on. A round of applause, everyone. It really has been quite a journey. Five years give or take, we've been involved with trying to make this work. If you appreciate all the work that all these contributors have done, do send a tweet with the hashtag workflow initiative and celebrate with us on Twitter. We've really come through some quite major achievements during these years. I'm not going to go through this list in great detail because each and every item is almost a major initiative in and of itself. But notably, a long list of entity types have been converted to be revisionable and publishable. We've committed three new modules to Core that work with draft revisions in different ways. And we've also fixed a long list of bugs. But all good things do unfortunately come to an end as well. Drupal 8.8 will be our final major milestone, for now at least. The initiative will effectively go into maintenance mode, and we're going to keep taking care of the modules that we've contributed and all the functionality. And we're going to look for a new ways of kind of sustaining this work into the future. Sustaining open source is really hard. Five years of development can be as much as, you know, multimillion dollars worth of investment for a company or for an organization that wants to do something like this. Keep thinking a lot about this. There's been a lot of discussion in the community as well of how we make this work. And I kind of want to figure out how we can do this more in repeatable patterns and enable more companies and organizations to do the same. In fact, I'm going to talk in much more detail about this on Wednesday at quarter past five in room G107. So do come and join me there. For the workflow initiative, it's been more or less a single company that has kind of been driving this. And it's been a fine balance between, you know, figuring out what the community wants and what we want to get out of the initiative as well. So in this session, I'm going to give some of my own opinions on what we can do better as organizations and also as a community. I'm going to wrap this up by talking about a new exciting feature that we're looking to get into 8.8, something we call hierarchical workspaces. But I'll start by explaining, explaining first of all what a workspace is. So a workspace is this isolated place on your site. We can work on multiple changes at one time and publish them at the same time. Hierarchical workspaces then enables multiple workspaces to play together. Imagine you run a magazine and you want to start preparing your winter issue with lots of draft content. But at the same time, you want to start preparing your new year issue. New year happens during winter, at least in the northern hemisphere. So you want to work on these things at the same time. So the way it works is that published content is automatically inherited downwards so that Grace and Margaret here in this case can kind of work on these changes together where Margaret inherits all the changes that Grace is working on in the winter issue. And then they can merge and publish changes upstream. I'm going to show a demo here in just a moment. So on the left, we have the live workspace. We'll switch over to the winter issue workspace in just a moment. And on the left, we have Margaret. She's working on the new year issue workspace. So we're going to start by making some changes in the winter issue workspace. The changes that Grace is doing here will be automatically inherited down to the new year issue so that Margaret on the right-hand side can work on her new year things at the same time. So we're saving these changes, uploading a new image, and we can preview this one change from multiple other changes at one time. And if we reload this child workspace effectively, we can see that the changes have been inherited downstream. So now Margaret in this new year issue workspace, she's going to do some additional changes. She wants to start preparing for new years, so she's going to remove a redundant article from the front page and do some changes to this lovely milk chocolate recipe here. So we're changing the title and doing another few bits and pieces. And what's important to understand here is that the changes done downstream here will not leak upwards, so to speak, to the parent workspace. So we can review all these multiple changes together. So we can see the changes here. And if we reload the winter issue workspace on the left-hand side, we won't see those changes there yet because the workspaces aren't merged yet. So you can see how they differ at this time. If we're happy, we maybe want to then bring together these changes and start publishing them. So what we can do here is that we merge this content upstream. We see that there's two changes. We've removed an article from the front page and we updated the image. And we can now see that these downstream changes are now reflected upstream after that merge. And now if we want to go ahead and publish this, three changes will be published. The one workspace, the one change that Grace already did, along with the two other that Margaret worked on. We can go and these changes that we've been talking about should then be if we switch to the light workspace here. And that's it. Okay, hi everybody. I'm Cristina Chumillas, a secretary known, RuPaul.org, I'm a front-end developer, rule-a-bot, and I'm UX, core maintainer, and also I'm one of the leads of the admin UI and JavaScript modernization initiative. But I'm just one of the persons helping on the initiative. So there are several names there that are helping. So everything started a few years ago. Several initiatives, well, two initiatives started at Vienna and we came together and joined the work front-end united last year. And recently we reached our first milestone having Clado as an experimental theme into Drupal Core. So the initiative has several parts. One of them is the JavaScript app. Another one is the user research that was done a while ago. And also the Drupal design system. And all of them are trying to implement changes into Drupal Core, several of them are already there. One of the main challenges that we've had so far is that we didn't have enough designers to get and work on the new design system. So it was blocking a lot of the initiative. So if you know designers that know Drupal, please explain them that there's an initiative for this. One of the things, one of the tools that we've been using is Figma that was at the beginning, one of the great resources because it was several designers working at the same time in the same document from several places in the world. So it was really, really helpful to have this sense of a team. Another thing that really worked well was the collaboration between designers and developers because we've listened a lot when things could actually be implemented or where some things like weren't good enough on an accessibility perspective. So it's been a really good thing. Another thing that has been a challenge is that every design needed to be super flexible because you know Drupal, you can just enable some more modules and everything changes. So the UI that we were presenting had to be super flexible and give solutions for anything that Drupal can show. Another thing that really worked well was the iteration over the feedback that we were getting from people. One of the examples was, for example, this on the left, you can see the first designs that we had for fields and then we jumped over for the focus into something that was more general. And also something that we need to take care of is that we can't actually break people's Drupal because we are working on an administration theme and we need to be sure that everybody just keeps the same interface when they update their Drupal site. And something that we also needed to take into account is the backwards compatibility because as I was saying, we can change people's interfaces and if they are used to have things on one place, they will need to have it everywhere after dating and changing the layout, for example, something that we want to do wasn't possible to do that just on a small release. So something that it will be important you to remember is that now it's better, now it's an experimental core, Clara is in there, so please test it because we need to find all the bugs as soon as we can so we can have a stable release ideally and hopefully for the next Drupal release. Something that we struggled with was the communication. It's been a little bit hard as you've seen there are several parts of the initiative. So it's been really hard to communicate what was the state of the initiative, each part to find the same goals and work together on things. So an opportunity that we have right now being into Drupal core is that we will be able to have the new documentation. So we will need a lot of people actually updating this documentation. Here's the link where you can actually go and help, test Clara on help creating this documentation so we can get more people helping there. We'll have, if you want to see the new design, we'll have a session on Wednesday morning and please come on Thursday to the sprints, we'll be there. Thank you. Hi, I'm Ted Bowman, Ted Bowman, Drupal.org. I work for AQUI as part of the Drupal Acceleration Team and I'm one of the co-maintenors of the layout builder module. So the beginnings of the layout initiative for Drupal 8 started with this, the seeds started back in 2006 with the first release of the panels module and continued modules such as DisplaySuite and Context. And though a lot of good development into those modules, we have a lot more people to thank than that. Throughout the next decade, a lot of users pushed these modules in new ways that the developers hadn't imagined and they provided valuable feedback from rural use cases, improving the developer site builder and end user experiences of these modules. They filed bug reports and provided patches that improved all these modules. At the height of Drupal 7, half of all Drupal sites either had panels, Context or DisplaySuite installed. Obviously this was something that Drupal sites needed. Deciding which solutions to use though was often daunting for new and even experienced Drupal users. So the layout initiative in Drupal 8 was an attempt to learn from all these solutions in this space. It strived to make the system that could be used out of the box by site builders and content authors but also could be extended in new ways by developers. Additionally, it was formed by regular meetings with the Drupal UX team and input from Drupal's accessibility maintainers. Layout Bottle was marked stable in Drupal 8.7 and now the contributed module space is exploding with useful modules that extend Layout Builder. I'll list a few here today, but there are many more. Maybe some more will be made this week. Layout Builder Restrictions allows you to streamline the Layout Builder interface for site builders and content authors. The Layout Builder Library module allows you to make pre-made layouts for your content authors to select from and Layout Builder styles allows themers to create predefined styles to apply to your sections and blocks. For translations, we have two modules. Layout Builder Symmetric Translation keeps your layouts in sync across all your translations but allows you to have custom translations of your inline blocks and other strings while Layout Builder Asymmetric Translations allows each language to have a totally independent layout with unique blocks. It's often more used for localization. Currently is easier than ever to get involved with the work of the Layout Initiative. The long slog of getting Layout Builder stable is over. There are many features that are being worked on that need help for many different types of users. So for Drupal 9, as we look forward to Drupal 9, these modules and real world use cases of Layout Builder will inform the future of Layout Builder and Layout in general in core. As much as the contrib modules such as panels, context and display suite also led to the Drupal 8 Layout Initiative itself. So what's next? What features of these modules do we think belong in core? What features of Layout Builder are currently missing? What is the 80% use case of Layout Builder? Should the Layout API be used in new ways inside Drupal Core? So how can you help? We need help from, if your core contributor working on improving Layout Builder in core, you're part of the Layout Builder Initiative. If you're a module developer building great things on top of Layout Builder in the Layout API, you're part of the Layout Initiative. If you're a site builder putting all these things together in new ways that nobody has thought of yet, you're also part of the Layout Initiative. If you're a content author using any and all of these, all of the above on a daily basis, then you're also part of the Layout Builder Initiative. So it's up to us here and everybody in the larger Drupal community to decide what the shape of Layouts is in Drupal 9 and beyond. There's a lot of possibilities that could happen and so we need feedback from as many people as possible and just like all the other initiatives up here, we're always looking for people that can help developers, people with UX experience in all kinds of different experience. We have a couple sessions this week. Tomorrow, Tim Plunkett, co-maintenor of Layout Builder module is doing what's next for the Layout Initiative so he'll go in much more depth than I did. And on Wednesday, Boris, Boyan Borisov, sorry for your name. Mitt Sprounce, your name is looking at a larger scope of the Layout Builder module ecosystem. And on Thursday, please come to the Contribution Day where you can help on Layout Builder core issues but also I'm sure a lot of the contrived modules out there if you wanna help on those. So thanks a lot and we look forward to you getting involved. Hello and welcome to some story time about configuration management from Drupal 8.0 to 8.8. You know, configuration management has been a new feature to Drupal 8 and there was a CMI that was successfully completed for the first release of Drupal 8. I'm Fabian Birchir, I work for Nouvelle and I'm a co-initiative lead for CMI2 and I maintain a couple of fairly popular contrived modules that deal with configuration. For example, config split has recently reached 1 million downloads on Drupal.org. So Drupal 8.0 came with this amazing new feature. It allowed you to export all your configuration and then import all your configuration again. But unfortunately, that was it and for example, development modules were not something that you could do. So Drush already before 8.0 was shipped had a flag that you could add to the important export commands that would allow you to skip modules. So you can have your development modules and then skip them and they wouldn't be exported. Unfortunately though, there was a bug and the dependencies of these modules were still exported and not skipped. But this feature in Drush was built on a very simple configuration filter approach. And then in 2016, I created a module called config split that built on top of this configuration filter approach but completed it and it would split the development modules together with their config dependencies into a separate folder. Based on this, then later also came like the sort of API part of it, a config filter but it was not feature equivalent. You could not just give it a list of modules that you would never want to export. So someone created an issue and then because it was not really a good fit for it created a separate module called config exclude that did that. Changing gears a bit, in early 2018, we decided that we wanted to build a better core way of doing configuration management so we started a new initiative. And we met at the developer days but then around Drupal Europe one year ago we kind of agreed that we wanted to have an event-based API but rather than just putting config filtering into core but we didn't really know how to put just the API into core because we need to also use the API. So at Drupal Con Seattle, we created a plan, we created a lot of issues of how like each step in broken down little pieces on how we're gonna get this done. But then as the summer progressed and life happens and not a lot of people have worked on this, it was getting clear that we were not going to make it and it was going to be very sad. So we had to think like, okay, how can we still do something? And we went back to the drawing board and kind of thought what are the expectations? What do we need to realign to still make this happen? And talking with a couple of people in the Drupal community we came to the conclusion that actually this original feature that Drush had that you could just skip the modules was actually a very good use case that core could have and so with the help of the maintainer config exclude we ported it to the new API and added it to core and because it has no UI and really very, very limited configuration options it could be done relatively quickly. And so just a few weeks before the deadline or a few days actually, we managed to get everything stable and committed to the place it needs to be in core. So I think that's quite a success. And something to celebrate really. For those of you who are more interested there will be a session later today from five to six in G110 where I will go much more into detail of all the other things in configuration management initiative and also where there is still a lot of help needed from all of you. Thank you very much. Hey, a quick reminder, you can ask any of us questions on Twitter using the hashtag Drupal initiatives. Just saying. Hey, I'm Wim Lears. I work in the Drupal acceleration team at Acquia and I'm one of the three API first initiative coordinators. The other two are the delightfully pink people standing next to me in the photo. Mateo from Lullabot and Gabe who's a colleague of mine at Acquia and we have pretty different perspectives. We challenge each other but usually we end up at a consensus that is better than our individual proposals and the three of us spent more than a year scrutinizing the country module that Mateo had originally built, vetting it against the spec, getting it ready for core inclusion and it was a huge effort but the result is now that it's easier than ever before to build decoupled applications on Drupal and the lower barrier to entry is really exciting. It was not just the three of us though. People all over the world and from many companies made it happen and more than a hundred people in fact did. Only about 50 of which have actually contributed code and so more than 50 actually contributed in other ways than through code, through manual testing, improving documentation and so on and that has been a tremendous help. Speaking of lowering the barrier to entry, longtime Drupal user Bejibus recently returned to Drupal and instead of running a public Drupal site he's now running it in his basement on his home server with crown jobs importing photos from Google and then he generates a static site by talking to Jason API, getting the content out and he was surprised by how fun and simple it was and he did that before this tool was available, the Jason API Explorer tool which was built by my colleagues at Acrea, Peter and Gabe. It's a visual query builder with live results and it talks to your own Jason API instance meaning it's showing something actually for your site and you can choose what to filter by, what to include, which fields to fetch and so on and it's not just that one tool that exists. Lots of people are building various tools and entire ecosystem is growing around Jason API from automatically uploading static JSON to S3 for example to adding capabilities not yet covered by the spec to customizations of responses, the list keeps growing and one example that was just recently released by Elliot Ward from Interactive Investor was the Jason API reference module. I'm sure that pretty much everyone in the room here today knows what an entity reference field is. It's just like that but instead of referencing an entity in Drupal, you're referencing data in a Jason API instance and that opens a lot of interesting new possibilities. My colleagues Peter and Gabe have also been working on adding hypermedia support to Jason API and that essentially means that you're adding relevant links depending on the state of the data. So for example, a comment that can be replied to or can be approved gets a reply link or an approved link in the Jason which makes it very easy to build applications like the one that you're seeing here. There are Drupal community members out there operating Jason API instances today serving millions of requests per day. They helped identify bottlenecks and helped us discover problems that we cannot discover without such big workloads and that's also an example of non-code contributions. For example, Nikolai Dobramira from FFW played an important role in that. Our Jason API implementation can also easily be scaled to numbers even bigger than millions per day because it uses Drupal's unique caching capabilities. This chart here is powering Jason API instance powering a product launch site and at peak it was serving more than 300,000 requests a second or 30 minutes, sorry. Thanks to big workloads like that, we were able to make Jason API a lot faster in the upcoming Drupal 8 release. Special thanks to Nikolai again but also Jivran Ejas from previous Next. Jason API will be at least twice as fast for everyone and three times or more faster for most of us. And notice not just thanks to caching but also thanks to algorithmical improvements. And so the three of us are really proud and happy to see that Drupal's Jason API is being used widely by both enterprise and hobbyists. And we cannot wait to see how all of you will be adding to the ecosystem. Thank you. Hi, I'm Greg Anderson. I'm a core services engineer at Pantheon and I also do a lot of open source stuff. You've probably seen me here and there on the queues doing things with Drush and some of the libraries that go into that and other similar tool-y type things. And today I'm gonna talk to you about another tool-y type thing which is called Composer. We've done a neat thing for a Drupal 8.8.0. It's called the Composer Initiative. Of course, Drupal has been using Composer since 8.0.0 but now we're moving it into core with the goal of making tar balls composer ready from the get go. And it took a lot of work to do that and we had to be really focused. And so today I wanted to talk a little bit about the things that we had to do in order to make as much progress as we did since DrupalCon Seattle. Sometimes during core development it can be kind of slow where issues have to just sort of sit there and wait. So one of the reasons that we were able to make a lot of progress is we built on existing tools. Drupal Composer, Drupal Project, the Drupal Scattle Project and the Webflow tools like Drupal Core strict were already there and the community had a good idea about how to use them and they worked well. But even though they worked very well, we still had ideas about how to make them better. So we came together at DrupalCon Seattle and we talked specifically about how to focus on the scaffold tool and make the configuration for that a lot better and more focused. And we had this great plan that we're going to get it all committed there at Seattle. But that didn't quite work out. It took a little bit longer than we thought it would. So we started a process of holding meetings every two weeks where we could make plans and see if we could make new milestones. And we used an initiative or a format that was started by the Drupal Diversity Inclusion initiative where we take meetings in Slack where they can happen asynchronously and it's worked out really well. Collaboration is also really important. To get your issues committed, you have to get them from needs work to RTBC but sometimes they'll move back to needs work and we need to get them back into needs review as quickly as possible. So it helps to have two people working on the getting it to needs review step. And it's also good to have someone who's just working on the RTBC steps because you can't RTBC your own issue. So we communicated a lot in Slack so we could keep notes with each other and say, hey, could you help me get this back to needs review or I need a review to get this to RTBC. And when it was ready, we'd also ping the core committers directly. And I really wanna thank the core committers who really focused on our issue. We had a bunch of things that were happening simultaneously and every now and then we have an issue that was blocked and if we told the core committer that we were blocked on something, they would give us priority and we probably couldn't have finished if they hadn't been so attentive to our needs. So if you wanna get involved with initiatives and replicate some of the success, my first bit of advice is to keep recruiting. People are gonna get busy and fall away. So you have to keep evangelizing, making people feel guilty doesn't work really well, but if you just show a lot of passion, if you're working on something that gets people interested and that'll drive them to join. Give good feedback. During the process, we had an issue that went to RTBC and we're all hoping to get it committed. Someone moved it back to needs work and said, oh, I'm so sorry, but that's really important because there's a cost to waiting for that core committer if we can find out that it needs to go back to needs work sooner, that's really good to know. And it's also important to be persistent if you're learning how to be better at sports ball or trying to get an issue committed to Drupal, you're better off being really consistent and spending small amounts of time over and over again rather than having occasional spurts of really hard efforts. So remember, we're all in this together, we're going down the same road. Please focus on your relationships, get those mentorship programs going and community is really the key to keep that persistence and continuity. And if you go to g1a.io composer, that'll pop you over to your project page. Remember you can ask questions of any of these other maintainers by using Twitter hashtag Drupal initiatives, but if you wanna know more about the composer initiative, you should probably come to the drift note here tomorrow or our session in room G106, Wednesday at 10.15. Thanks, I hope I see a lot of you there. I'm gonna be telling the story of the promote Drupal pitch deck, which is just one part of the promote Drupal initiative. And this is really the story about how this project came to be. My name is Suzanne Dargecheva and I do a lot of marketing related activities these days, but my background's actually not in marketing. Over the 12 years I've spent running a Drupal agency, I've developed a passion for content and good communication and design. And so when I saw the promote Drupal initiative take off at Drupal Con Nashville a few years ago, I got really inspired. It was launched to coordinate community efforts to promote Drupal and really get people working together to expand the market for Drupal. Last year, just one year ago at Drupal Europe, I had my first chance to get involved in the effort. I actually went to an agency leaders round table that Rachel from the Drupal Association organized and we had lots of really great conversations there about how to help agencies, like what agencies actually need. And it turns out that small and medium agencies in the Drupal space really need help selling Drupal to new markets and help figuring out what messages, what content people wanna hear when they're considering a content management system. A lot of the times we're kind of in the Drupal space and we don't think about this bigger picture. So a small group of us there at that round table, Paul Johnson, Ricardo Amaro and I came up with this notion of a pitch deck. We thought this would be a really easy kind of first step, something really actionable we could do to give agencies a common set of talking points when talking about Drupal. So we set up a Trello board to kind of get ourselves organized and we decided to take a really small first step which was to get input from all those other agency leaders out there. So we put together a survey and just asked the community what they needed. And it turned out this was a great first step because we got a lot of good feedback. And we found out that something really useful for people would be able to tell stories about how Drupal's used in different industries. So we wanted to get a whole bunch of case studies and testimonials from around the world of how people are using Drupal, just like really good success stories that we could all draw from. And we also thought it would be good to have some key talking points. So when you're selling Drupal to higher ed or to government, you really need to talk about security and accessibility. So what is some really powerful content that we can all use to just speak about Drupal in that way and focus on the points that are most salient to customers? We also collected some impressive facts because there's lots of impressive facts about Drupal that we don't always mention. So we put together some facts and figures that we could include in this pitch deck, talking about what makes Drupal great. Now pitch deck is not just all about content and having a message. You also need to have design. So having that passion for design is really important. So I actually drew some designers into this process to designers on my team stepped in and helped take the brand guidelines for Drupal. There's actually a brand book for Drupal and apply that to our pitch deck. We wanted to be able to pitch Drupal in more than one language. So Paul Johnson actually came up with this great idea to manage all the pitch deck content in Drupal so we could get it localized. And that means that we can actually talk about Drupal in many different languages. So it's in the process of being translated now into many, many languages, which is very exciting. I think this is one of the most powerful parts of the project and gives it a lot of flexibility. Another aspect that's now underway is that by having all of the content for the pitch deck in Drupal, we can also customize the pitch decks themselves so people will be able to export the slides in the deck that they wanna use to pitch Drupal to their audience, whatever that is. So you can find out more about Promote Drupal in general if you have other ideas for projects that you wanna launch. This started last year at Drupal Europe so there's room for more projects like this. Come to our BOF tomorrow afternoon or you can reach out to me or any of the other initiative folks directly. Thanks. Hi, I'm Ellie. I'm here to speak to you about Drupal Core Mentoring. We are a group of mentors and organizers who help people become contributors to Drupal. And I guess I've been involved with mentoring since around DrupalCon Vienna or maybe Austin. It's been a little while now. But mentoring really got started back at DrupalCon Denver. So this is a representative image from 2012 of Tim Plunkett showing some folks how to work with patches. I think they may be writing a patch there. But the Core Office Hours concept really came from XJM suggesting that after a lot of success with Core Office Hours in 2011, we started doing that on a regular basis on IRC and over the years grew the program to where we had 30 mentors at DrupalCon Nashville last spring and we've brought it from around 100 contributors learning how to contribute to like 250 at one of these Thursday or usually Friday contribution events at DrupalCon. So a lot of what the mentors do at this point is organize around the larger Drupal events as well as some of the camps. So this is Drupal Europe last year. That's Friday morning, getting folks ready to start contributing. It's sort of an ongoing cycle of what we need to do. So there's the organizing beforehand, there's the event and then there's a lot of retrospective afterwards. So we are always changing and iterating on the program and I will be speaking about that on Wednesday afternoon if anybody wants to see that. I think one of the coolest things about mentoring is that there's sort of a cascade effect. So instead of just a mentor and a mentee, you have mentors mentoring each other like Kathy is an excellent example of a mentor of mentors. But it's also a collaborative web of people contributing and mentoring each other and everybody is a mentor and a contributor. That's the message here. Oh, I should also mention adding your mentors to your Drupal.org profile is a really nice way to say thank you. But mentoring should also happen places that are not these in-person events. Not everybody can make it to these. So I highly recommend if you're not already on Drupal Slack joining, there are a lot of great channels available like Drupal Diversity and Inclusion pictured there in Nashville has a contrib space where you can find some projects to start working on. A lot of what we hear from mentors at these events is that there's sort of three different paths a new contributor takes. You might mentor someone and they are just really excited to get started at all. Really excited to work with the tools to learn how to use the issue queue, some of the basics. And that's enough like they understand the community. It's pretty exciting. Or you might mentor somebody and they have a patch committed that very day. We can't always make a live commit happen but when it does, it's amazing validation. Or you might just keep contributing on your own. And the third path is mentoring someone and then they become a mentor which is what happened to me. This is DrupalCon Austin, I'm in the back and those are some of the mentors who held my hand very patiently through a lot of rough times learning Drupal. Probably shouldn't say rough times, it's been fun. It's awesome. But it's also really great to have somebody there who can help you and you know, you can reach out to them. So if you're interested in being a mentor or a contributor, I recommend just come by our booth here in the exhibition hall. We're behind Maisie's blue container which is kind of hard to miss, so we're over there. And if you want to mentor, come by the mentor orientation today or Wednesday, we will show you the ropes, help you get started. And the other thing I hope you all noticed in all of the presentations today is that folks need help with their initiatives. So if you already kind of know what you're doing with the issue queue, you might want to just join one of their initiatives in the general contribution room and otherwise come to the first time contributor workshop. Voila. I think we have one tomorrow and one on Thursday. We will help you get started learning issue queue, learning maybe you just need a Drupal.org account. There are lots of different ways to contribute too. So you might need a local development environment or you might not. This is a handy flow chart that Gabor put together. You can see that you just follow the flow chart. It's there. Great chart, love charts. That's pretty much all I have to say. I probably missed some of my speaker notes, but that's cool. Finally, I hope all of you speakers kept this in your decks. Thank you very much. All right. If we could have the Drupal initiatives hashtag on the screen, that'd be awesome. So as a reminder, Drupal initiatives is available for all of us to ask questions. We do have a few, but you can keep them coming in. We do have still a few minutes. I'm gonna start out with one which I think is kind of easy and it is, can we participate? The collective we participate in these initiatives. If someone can participate in your initiative, could you please raise your hand? Yeah, that's everything. For those who can't see, live stream. That was all of them. I'm asking for a volunteer to answer this one. How can I get in contact with the initiatives? Is there a centralized location? Can someone give some advice for somebody out there who's interested and maybe inspired by a couple of these? Anybody wanna volunteer? Oh, ha, okay. I know for Drupal diversity and inclusion, come to Drupal Slack. We have a channel, the hash diversity dash inclusion. If you don't know which channel, there's hashtag contribute. Well, usually someone will tell you how to get in through that or you know, hashtag composer if you wanna get into the composer initiative. What Greg said, but for the API First Initiative, it's the Contenta channel that you wanna join. Basically, most of the initiatives have a page on Drupal.org that you can go in and you will see the way to content each initiative and all the channels both on Drupal Slack and maybe Drupal Chat or whatever in there. Awesome. All right. There's a question. If we can have maybe two people answer this one. How do you organize or prioritize the tasks of your initiative? We can have just two people self-elect to talk about that. Two different initiatives. Yeah, we have a lot of contact with the product managers about the things, yeah, that we can really accomplish in a specific amount of time and amongst ourselves. We have a lot of discussions of the things we think is important, but we use the issue queue mostly to get the work in and just prioritize from there. I can answer for composer initiative. For us, it was easier than maybe some of the initiatives because our tasks were fairly linear where one would block the next, but there's a whole pile of issues that are area composer. So we also added a tag composer initiative for just the small number of issues that we're actively working on right now. So you can always look for that tag to see the active things to participate in. And the layout initiative, when we were getting layout builders stable, we had, I think bi-weekly meetings in Drupal Slack at Pound Layout and also we would meet frequently with the UX team. And that a lot of people who weren't necessarily, I guess, considered themselves part of the layout initiative gave us a lot of good feedback. Again, product managers, initially when we were looking at translations and layout builder, we had a totally different idea than we got feedback from framework managers and product managers as far as, like, no, that idea, it's not what people expect. So then we changed tact. So yeah. Awesome. And actually, Ted, if you could hold on to the mic because the next question specifically for you, is there any momentum in the layout builder initiative to expand the usage to cover arbitrary pages? For example, those created by custom modules or custom routes or via the page builder contrib module? I have not seen that. I've kind of been the last couple of months, I've been doing Drupal 9 stuff. Yeah, I know Page Manager had a patch for using layout builder and Page Manager, which would give you that. But if people are interested in that feature, you talk to us on Drupal Slack or propose an issue either in the ideas queue for Drupal core or you could propose a feature directly for layout builder. Cool. Next one I've got is actually not a question, but I thought I'd just share. Someone feels that workspaces are awesome. So, Greg, if you would tell us, do you think the composer will also bring more consistency to how different Drupal distributions are installed and updated? I think that will probably be answered at a later time, but yes. Teasing tomorrow's keynote, perhaps. Nudge, nudge, wink, wink, yes. Actually, this is for anybody if we maybe have one or two different people answer this one. It was mentioned several times that working on the core, working on core could be a challenge. Is there initiative to change this? So, I think there's definitely things that we can improve with how we govern core and how we work on core, but I do wanna highlight the fact that how we work with core and how we contribute to core has already changed a lot in the past couple of years. Bringing scheduled releases to Drupal 8, semantic versioning has really made a huge difference and make it a lot easier to plan and kind of argue for getting changes into core. So, I think we've already done a ton of good changes. Surely we can continue improving, but I just wanna bring that out, really. Yeah, I would say it's, yeah. There's been a lot of, I feel like it's an ongoing initiative, maybe not named, but it's been a lot of changes. I mean, compared to Drupal 7, right? It's when we had like multi-year release schedules. No one had the incentives to contribute to core, really, so. I don't know if people know about the Drupal core ideas queue where you can, if you don't feel like you wanna jump in and make patches that you can propose changes to Drupal core, or you can look through that queue to see what ideas are already out there and give feedback on them. I just wanted to highlight that sometimes it needs to be hard because we need to think about all the things, not just it works, it also needs to be usable, it needs to be performance, it needs to work for very big sites, for small sites, and it needs to be accessible, and that takes a lot of work and documentation. So there are a couple of questions about starting an initiative, or is there like, I would like an initiative for something, dot, dot, dot. Can anyone give advice for someone who would be interested in starting a new initiative? How to propose that? How to gather support? How to make that actually so that they could be up here? Next. So I would say one of the first things is first, get together several people because for sure not everybody's going to stay after some months. The next step probably is going to be filling an issue into the ideas from Drupal core, Drupal Arc. That's probably one of the best ways to start checking if people is interested in that. Promoting this issue and getting people to know about the issue, to propose more things, and after that getting support to the initiative. Yep, so the issue here to look at is Drupal Arc slash project slash ideas. And so that's where new ideas for Drupal core initiatives are being created, and the intent is to create a plan where you outline where you want to get and how you want to get there. But you should be doing it with multiple other people because doing it by yourself is kind of impossible. Yeah, usually getting someone that actually has some experience already on Drupal core or something similar will help you reach project managers and all the things that at the end are going to give you feedback and something. So it's like the following step after that. And also I'd like to say if possible, get it working really, really well outside of core, and then make a pitch for why it's much better to have it as part of core. Awesome, Suzanne, we've got one for you. So if we can get a mic to Suzanne. How will the pitch deck be kept up to date as clients evolve platforms? So when we first made the pitch deck, like kind of the MVP version was just in Google Slides. So it's kind of hard in there to do things like versioning, especially once you start adding translations, you can imagine then you have, you know, a hundred versions of a pitch deck, it's impossible. But now that all the content will be managed in Drupal, well, you know, with Drupal, we can have versions of content and we can have a workflow for managing that, getting things approved or translated. So there's endless possibilities there. I've actually got a combined question here. So do workspaces and the API initiative work together? E.g., can I specify a workspace from which to get my JSON results? I don't think it works right out of the box, but there's at least two companies out there that I know of that are doing some really, really exciting things with workspaces and JSON API. So one of the examples, I think we need to do a few tweaks in core to make this work, you can certainly get it working in Contrib. But imagine you have a JSON API per workspace, then all of a sudden you have a very capable content hub, for example, where you can have decoupled sites, kind of inherit content automatically between each other, regions, countries, whatever it might be. So there's definitely at least two companies out there that I know is using it together. But it's totally true that today it doesn't yet work in Drupal core, but the good thing is that workspaces has just become stable or is about to be marked. It's about to. Yeah, exactly. And JSON API does have the underlying infrastructure to make it possible to negotiate which kind of thing you want. So either revision or buy workspace. And so all of the foundations are there. It's now, workspaces is becoming stable. JSON API is already stable. So this is like one of the next things to do immediately after workspaces become stable. So it will be added, but today it's not yet possible, but I'm glad to hear that some companies are already experimenting. If you wanna know more, grab me if you see me around or we will be able to answer more questions. Or point you to the issue to do the work. All right. So what I heard was this week. That's what I. Yeah. All right. Does anyone know if there's an initiative for a module that makes use of eloquent? Does anyone know if there is such a thing? Seems like a lazy web thing, but I thought I'd ask, okay? Nobody? Okay. Moving on. Question about configuration management. So configuration management doesn't export files that are linked to configuration fields. For example, default images. Will there be a fix in the future? Possibly. Create an issue, target with CMI to candidate and then help work on it. Like it's with all these issues. If you have a need for it, and if you're blocked by core not having this solution, and if you create a patch and add tests, and then find someone else who marks it as reviewed and tested by the community, then it will happen. And if nobody creates a patch, then it's very difficult to make it happen. But that's why we're all here. And you don't necessarily have to create the patch yourself, but if you create the issue and you create like a buzz around it sort of, like you create, you make other people know about it and then maybe someone else who doesn't have this need necessarily but knows how to fix it can come in and help. So I think that's the best solution answer to this. Fantastic. That's good advice for all of the things. Christina, besides the new admin theme, is there room for front-end devs to help with initiatives? Sorry. Actually, maybe for everyone, but besides the new admin theme, is there room for front-end devs to help with other initiatives? I guess front-end devs can also help on the new admin theme because basically that's what it is. But yes, also the, well, I'm not really sure what, where would you start with JavaScript part of the initiative right now, but for sure there's a lot of need of front-end developers ideally with some experience on Drupal Corp, but not only that. So, yeah, that's. In the workflow initiative, we have some UI tweaks that we wanna do as we head into maintenance mode. With our initiatives, so if you're a front-end developer, do reach out to me and I'll be able to point you to a couple of issues as well. I also would like to point out that the media library module is close to becoming stable and there's a lot of themes out there, admin themes that are not necessarily incorporated also in contrib that could have a better styling or apply to it for the media library. So that's also something really a narrow scope to work on. There's a lot of issues in the layout builder issue queue that we need front-end. JavaScript CSS work on, so, yeah. I call first dibs. All right, so that's a lot of opportunities. A question about mentoring. Is there any region or local mentoring for non-English speakers? That is a good question. I think I would recommend reaching out in the contrib channel to start. So I don't know offhand of regional mentoring. Someone down there? Yes, good. But in general, there's more and more local Drupal associations, which would be a great place to start more mentoring at the local level. So if you're looking to start something in your region, definitely reach out to your local association and talk to them about it. Or start a local association. And as a, so we're still taking questions off of Drupal initiatives. We probably only got time for one or two more. So if you still have a question, get it in now. If somebody wants to volunteer, maybe one or two want to volunteer. What the biggest challenges or obstacles you've faced in leading an initiative? Somebody wants to be bold and speak to these things? I mean, I think it's, a lot of us is just organizing volunteer labor is always a challenge. People come in and out and so you have to design a process where that's okay. And that those small contributions can be, like a drive by contribution can still be productive. In our work, it's much more, it's sort of driven by the energy of the people who are in the room. I'm sure that's true of other ones too. But if somebody wants to work on speaker diversity, then that's what gets worked on. So it's really about cultivating energy and cultivating for us a community so that people do want to stick around and continue the work. Like you said, guilt doesn't work very well. So you want to get people who are excited. I would say that the biggest challenge we had is just coordinating the times. You know, you can't do all of the processes of an issue all by yourself. You need multiple people. And if someone goes away, then that can block an issue. And that's why it's good to have a plurality of people working on things. So if someone has to go on vacation or have a life or something, then you don't have an issue that just drags to a halt for a week. One thing I want to add, and I spoke about it during my slot, sustaining an initiative financially over a number of years is also really hard. Not everyone is in a position where they have time or kind of the ability to contribute. So paying contributors and sustaining people to kind of year after year really bring all these issues to completion. That's hard. Apart from writing the very, very complicated code, of course, sustaining that has been quite a challenge. Now, my session on Wednesday, you'll learn more about that. Tara, are there any plans for Drupal's diversity speaker training to be brought to a wider audience like DrupalCon? Yeah, so if you take the workshop, obviously you can take that. We're going to be doing it at DrupalCon Minneapolis. And I personally am going to try to do it as many times over the next year in as many cities as I can. So we are definitely still working on that. And if you're interested, we would obviously love help getting fundraising and that kind of thing going. Because Jill's, this is her full-time business is running these, so we need to be able to compensate her for that. All right, with that, we're going to conclude the questions part of the day. Everyone, please join me in giving a round of applause one more time. Have a fantastic DrupalCon Amsterdam, everyone.