 Okay, then let's go ahead and kick off. So you are all here for WhatStacks for Drupal.org. I'm Josh Mitchell, I'm the CTO for the Drupal Association. And basically what I'm gonna run you through real quick is a little bit of background information around what the Drupal Association is doing right now on Drupal.org, what we're focusing on, kind of how we came to that focus and talk a little bit about what the next steps are because there's several things in the strategic roadmap that we haven't quite started yet and I want to be able to kind of give people a preview of that. So first of all, a little bit about the Drupal.org product and engineering team. We go to 11.5, as Nigel Tufnel would say. Spinal type reference, come on. So that basically is made up of about a third DevOps, a third product and design, product management and design and a third engineering. That focus is nice to have because those are all full-time, well, except for the .5 who is half-time support. We have 10 completely focused staff that are working full-time on Drupal.org which has been really important in accelerating a few key things on Drupal.org. Staff aren't the only ones involved though. We've got the governance structure that was put in place starting really late 2013. Dries worked with the board to kind of establish some working groups and this is roughly what it looks like. We have the software working group which is focused on the developer tools and functionality of Drupal.org. There are advisors to the software working group. We used to call this the dev tools team and the community tools team and what we found is that individual members were all kind of focused on a particular thing that interests them and so the meetings were kind of updates about what everybody was doing but they weren't about working together on something so we kind of shifted it to more of an advisory thing and we're doing more of that over an advisory email thread with regular issue updates whenever somebody has made progress on one of those. We have the Drupal.org infrastructure working group which was kind of taking some of the leadership from the infrastructure team and turning that into a formal strategic structure to help advise. We have the D-Dado content working group and that is focused on the usability, the content strategy behind Drupal.org and they've worked with us really closely on the content strategy and if you get an opportunity to, please do check out the session that Courtney and Tatiana did on the Drupal.org content strategy because it'll go into more detail on some of the things I'm gonna gloss over. A fairly new working group is the licensing working group. They are gonna be focused on reviewing licensing questions so it's about setting policy and about having someone to escalate a licensing question to and then we have a marketing committee that works closely with the Marcom team from the Drupal Association and also with the content working group. That marketing committee is also very nascent. It's just really starting back up after not having a chair or members for about six months or so. So that's the kind of the Drupal Association influenced working groups. The Drupal project of course has its own structures that you could call them working groups as well. Obviously the initiative leads and the core maintainers kind of represent that project structure. There's also the technical working group also appointed by Jarriz. They're focused on questions like what are the technical parameters under which the project will work? What are the technologies that we're gonna introduce to Drupal? What are the code format, the kind of meaty stuff? They're meant to basically be a tie breaker and kind of solve disputes if that can't be figured out through regular community processes. The documentation working group of course focused on documenting how to use Drupal, documenting the API, making sure that that documentation is as complete as possible. And they work closely with obviously the project. We're also trying to pull them in more closely right now with the content working group and with the software working group because there's a lot of overlap between the tools that they need and their kind of mission to make sure that the documentation is in place. Security working group, most of you know that the security team is constantly reviewing things. There's a subset of the security team that kind of acts as the face of the security team and helps work with the Drupal Association on doing security releases, PSA is that sort of thing. The community working group would be the other project related group and obviously they're focused on things like enforcing the code of conduct or supporting the code of conduct I guess because they don't seem like the enforcer types. And I would say probably the community working group probably has the least direct impact on the tools of Drupal.org. So we don't have a lot of direct work with them but there's some representation on the other working groups that overlap with the community working group. So we hear a lot of things about oh well this particular feature may or may not influence how community members can work together. And of course all of you are also critical to Drupal.org and how that's been developing over time. Every time you comment on a Drupal.org related issue queue there's six major queues that we're focused on have about 1200 open issues in them. I would say about half of those are feature requests, the other half are either bug reports or tasks or support requests of some sort. There are another 40 issue queues that are related to projects that are used on Drupal.org and we do keep an eye on those but not quite as close an eye on that. I wanna go over a little bit of like how we got to where we are right now because I think it helps set the stage for how we've set up the process of interacting between staff and the working groups and the community and what that looks like. A lot of this kicked off in Austin of last year. We had some working groups, members and community members that were kind of key to a couple of areas come together. We did some brainstorming and we basically came up with a set of four objectives that we were gonna use to determine a lot of our work and those four objectives are really around increasing Drupal community engagement on Drupal.org. Growing the adoption of Drupal through Drupal.org and that's very much a content play because there's not a lot of developer tools we can use to grow adoption. It's about giving people the marketing information they need to be able to sell Drupal within their organizations. We wanna make it easier to build Drupal so this is really important to both Drupal core and contrib having the right tool sets that make that as easy as possible and we wanna make Drupal.org the home of the community and one of the ways that we chose to measure that was basically by traffic and engagement with the community. So what are the touch points we have? How frequent are those? And also what is the total traffic coming to the site? Are we doing things that will help grow that in a sustainable way? So in summer of 2014 after DrupalCon Austin we spent a lot of time with the working groups documenting what the needs are and there's this whole ideation process that have been put in place. It's safe to say that there's not a lot of new ideas. For the most part they've been documenting the issue queues for years and in many cases we have four five year old issues that were opened up when the real explosion on Drupal.org occurred somewhere between six and seven when Drupal started really gaining a place in the marketplace. So we have a lot of great ideas what we should be doing that we were able to take and begin to take through our prioritization process. The working groups had never really used a prioritization process before other than talking about it and saying yeah I think that's important too but let's bump that issue up to major or let's bump that issue up to critical. I've done a lot of work in government organizations in taking kind of disparate needs and having processes that help people get to a definitive list of this is the most important thing to work on next. And so it's basically prioritization methods that give you a score for every initiative based on those objectives we have. I'm not gonna go into that in detail cause frankly it probably bore you but we got through it with the working groups and it basically took us into a process that broke our work down into four areas of prioritization. We need to do work on Drupal.org that funds Drupal.org development and that could be working with supporting partners or hosting supporters or figuring out ways to do responsible advertising on Drupal.org. All of those things are things that we can use to develop revenue streams that are sustainable and that are not influenced by any one company or organization. They've gotta be something that's sustainable because they represent the community as a whole and not any one institution. Work that we need to do to just sustain and support Drupal.org and this is the things that we do with the servers making sure that they're up and running, that we have high availability, that the site is very performant, those are all things that it's the sustaining work that you just have to do. It's also work that doesn't tend to lend itself to volunteerism. Getting a pager call in the middle of the night is not conducive to a volunteer process. It burns volunteers out and while we do have a few very committed volunteers who still do that sort of thing, by having staff we've been able to make it more of a rotation rather than an expectation and often an unfulfilled expectation if somebody's life takes them in a place where they couldn't do that volunteerism. We work with community initiatives. Some of the good examples of this were Drupal CI. We've been doing work such as through the Drupal 8 Accelerate Fundraising. We were able to do some work with them by having them come to our offices in Portland, do an extended sprint with our team and start working on productionizing that. Other community initiatives that we've worked pretty closely with would be things like localize.drupal.org. The upgrade process for getting that where it needs to be to remove it as a Drupal 8 blocker. Community driven Amsterdam was a great sprint where they did a whole bunch of analysis of what does it take to get it to Drupal 7 for the localize.drupal.org and now the team is actually coming in helping productionize and finalize a couple of those things because the community members don't have the time to finish it off. So that's kind of a good example of that. Those priorities I talked about being able to take that finalized list. We ran that through the working groups. We ran that through the board of the Drupal Association and that is the major focus of our work. If you set priorities, you wanna be able to say these are the things we're gonna do first. So all through August and September of last year we were really doing that prioritization process. We were getting the buy-in. In Drupal, Khan, Amsterdam, we announced the strategic roadmap and kind of put it in front of everyone of here are the priorities. So our strategic roadmap basically consisted to start anyway with these seven items. New user engagement was one of the critical things that we wanted to improve because out of Austin, we decided that the people that we most need to focus on to really grow Drupal are the people who are transitioning in skills acquisition that are transitioning from being a learner to being someone who's skilled in Drupal. The full pyramid looks a little something like you go from newcomer to become a learner. Newcomer's just somebody finding out about Drupal. A learner is somebody who wants to know more and they're gonna start trying to do things with Drupal and maybe they've even done some small sites or small instances. They proceed to skilled and at skilled is probably at the point where they start doing enough work in Drupal that either they've become someone who's looking for ways to get engaged as a volunteer or they're making money, making income doing Drupal in their professional lives. That's a pretty important transition because it takes them from this spot where they're interested to where they're really doing things. The next level in the skills acquisition is expert and expert is really about the people who are really doing this day in, day out. They're full-time job doing Drupal in some capacity or they're just really, really expert volunteers in our community who are regularly in the issue queues and doing amazing things. And then we kind of top the pyramid with this concept of master. The master, our initiative leads our core maintainers, people who have been in the community for a long time and who are able to help shape the direction the community is going. And so that master level, we don't really want to spend a lot of time building tools for them per se. The real focus for the tools we want to build is to make them easier for that transition from learn to skilled. Because then we're gonna help the master by doing that as well. But it's the focus on really growing that space that we want to do. So new user engagement was a big part of this and one of the areas that we focused a lot on was account creation and login and also some things that perhaps are hard to do with volunteerism such as spam fighting. Tweaking those algorithms so we can do it really well. Organization and user profiles is also something that we've done quite a bit with in our putting things in place like user pics and reorganizing those pages to look a little bit nicer. There's some other things I'm gonna talk about in some later slides that we're doing to try to make that even more compelling and make that really the home of the community by having that be the place where people have a profile that you would go to to know that that organization or that user is involved in Drupal. We put responsive redesign of Drupal.org on the roadmap as well. Issue workflow and get improvements and I'll talk about that in more detail. Make Drupal.org search usable, improve tools for finding and selecting projects and then updating Drupal groups. So that was the initial seven initiatives that we put out. That was what we were working under through much of the previous months post DrupalCon Amsterdam. In December 2014, the content working group had started a process for the reinvention of Drupal.org, particularly as it relates to its content. So we had done the user research. The content strategy was next. We kicked that off in December with forum one, began presenting those findings in the January, February timeframe, had our first all working groups quarterly meeting. So prior to January of this year, all those working groups that I had mentioned before had never collectively, all of them been invited to come to a common place to have a discussion or hear something. So we were able to get them all together, walk through the strategic roadmap, get feedback about what works and what doesn't and also begin showing some of the early research from the content strategy. And so that was an important time. I mentioned that the working groups were involved in that. We also began showing it to key community members. In February, late February, early March, we started realizing that the strategic roadmap that we had set had some holes and the reality is sometimes things happen. Prioritization should not be this fixed process where it lives forever. As you finish things, they fall off the list. But as more important things come up that you realize are either emergent priorities that need to be inserted in, you have to have a process for making that happen. So our strategic roadmap really has expanded to include a couple of other things. And you'll notice Drupal events is something that pulled into there. In the previous years, DrupalCon events websites have been from scratch every time, basically building a site from scratch. And any of you who've helped run a camp know that close to a third of your effort for any given camp is gonna be about building the website because it's a lot of work. The distributions that are out there are varying degrees of done. And then depending on the complexity of your ticketing and your registration, the tools that are out there have to be customized pretty significantly. So we were dealing with that over and over again with DrupalCon's. And we decided in late last year that we were going to apply staff that would be pretty much dedicated to getting our DrupalCon distribution to a point that we could use it over and over again. So that definitely got inserted in as a priority. And we've been very fortunate to have Jacob Perry and also Emily Nouveau who both worked a lot on Cod. They've been coming in doing some amazing work. They're now full-time on our staff here at the Drupal Association. And they've been focused on making that event registration process better. All of it's going back into Cod as well, which has been awesome. We've been hearing some really positive feedback from that. And they're hoping actually for a 1.0 release that will be a significant community improvement for camps that want to run on that in the near future. So it's good example of something we needed to do both from a revenue standpoint because DrupalCon websites have to work for us to be able to put on conferences this large. But it's also something that was a great way to give back to the community from work that we were doing for that purpose. So a couple of other things that we had to kind of squeeze into the process were infrastructure stabilization and trying to really improve the infrastructure in some significant ways. I don't know how many of you are familiar with say the CDN implementation over the previous year. Our websites are all now fronted by Edgecast and updates.drupal.org. The site and the service that every Drupal site in the world that's our very Drupal installation in the world calls back to to see if its modules are up to date. That's now funded by Fastly. Both of them have been excellent technology supporting partners that have been huge and giving us services at a discounted rate that has made our money stretch further. But those sorts of stabilizations are just one example. We've had a couple of surprises and emergencies to deal with and we've also been working with making our environment more standard. We've been moving our entire structure over to using Puppet for our configuration and the management of our servers. We've been doing some key efforts to separate ourselves from open because most of our hosting is with the open source labs in Corvallis, Oregon. We've been really trying to reduce our dependency on things that they would have to answer a support ticket from us in order to resolve because now that we have staff, we can actually get to it and resolve it faster than their ticketing process could work. And so we've been trying to establish the tools that we rely on them and the tools that we need to do internally and figuring out what that balance is. And that's contributed a lot to the stability of Drupal.org. We've had amazing uptime and ever increasing response time on Drupal.org since beginning to implement those things. Drupal CI is another thing that I mentioned as a community initiative that has really become also a staff priority. As the project has moved along, we've had great work on the individual components. But outside of Jeremy, whose time is limited to nights and weekends and being able to jump in, there's few people who understand how they all connected together. And so we've spent some time since the Drupal CI Sprint in Portland in March, spent some time with our staff working on productionizing those systems and getting us to the point that we can do full end-to-end testing for the Drupal project using Drupal CI. And that's been an important shift as well. One more that was a community initiative that I mentioned that has taken up a little bit more staff priority has been localize.drupal.org. Contacted Gabor and Sebastian and say, hey, what do you guys need most from us to make sure that this is moving forward and removed as a Drupal A blocker? Both of them said the best thing we could possibly do was be to spend some staff time removing or fixing a few of the issues that were found in the review in Amsterdam. And so we were able to take Oliver Davies from our team and he jumped in and was able to remove most of those and we're hoping for one more review here in Los Angeles and hopefully within a month or so after Los Angeles, localize.drupal.org will be on Drupal 7 and we'll have those final pieces in place that make it a non-blocker for Drupal 8 which is key. You may have noticed too that we changed the title instead of it being responsive redesign of Drupal.org, we changed the title of that one to content strategy and design of Drupal.org. We actually did a responsive redesign push of a lot of the code that Lewis, Nyman and others had done at Dev Day's Zegad. We did that right around the new year. We called it our Christmas gift to the community. That deployment and getting that out the door really meant that we had kind of met the initiative of responsive redesign but the reality was we still had this larger content strategy project that was clearly a priority and we wanted to make sure to get it into the initiatives that we communicated to everyone. So speaking of that content strategy, over the last couple months a big part of our work has been communicating what that could potentially mean and I'll go into it in a little bit more detail and even more detail can be seen in Tatiana and Courtney's presentation from yesterday. It's recorded and online. One of the big shifts that we're recommending is actually moving groups.drupal.org into Drupal.org, moving that functionality into the same installation and because that was gonna be such a significant shift, we over the last couple months have been getting those groups, maintainers involved in that conversation and having that influence a lot of the presentations that you'll be seeing from both our team and from community members who are involved in this during DrupalCon here and that gets us to DrupalCon Los Angeles, woohoo, we made it. So I was gonna show a couple of just screenshots of some of the things that the team have worked on and that we were particularly proud of. The login process and the creation of a new account look a million times better. Also every single Drupal.org sub-site now logs in through Drupal.org, so we actually do a redirect. It's all bakery integration, but previously it was bakery integration but you would log into each sub-site. Now you are guaranteed to have an account on Drupal.org that isn't synchronizing but is actually getting created there first and then we redirect you back to the sub-site. So this was a big change that allowed us to do some important things in terms of being able to look at spam fighting from a single point of entry rather than looking at it as all the separate sub-sites which was an important change. It also I think looks a lot better and has much better instructions for the new user getting started. There's still some improvements to be made. For instance, you can sign up for newsletters now straight from your sign up form. We've done some nice little MailChimp integration there and we're using MailChimp for all those newsletters now which has really helped improve the speed of delivery. We still need to figure out how to get the security updates, the security announcements, moved over onto that as well. So for right now there's two places to sign up for that so there's some small tweaks like that that we will be working on but for the most part most of the user profile account creation process that initiative is mostly done at this time. One of the things I also think has been a huge hit and Holly mentioned this up on the stage the other day but I'd like to keep pointing it out is identifying new users and actually labeling them as such has been huge. It gives us an opportunity to say hey, welcome to the community. It also allows you if you're in the issue queues and you see somebody post something, you're like why are they post, oh they've only been a user for 90 days or less because they have the new label on them which I think is an important kind of change for the community to be able to think about people in a learning and growing sort of way rather than expecting them to come in and just know everything. The other bit that's related to that is the confirm button. For any of you who have done a significant number of issue creations or comments or forums, I'm not gonna say the specific number because we're still tweaking it a little bit to figure out what the perfect number is but a significant number. Enough that we know you're not a spammer. We give you a role called community and that community role used to be called spam fighters but really that's kind of a negative connotation because that's not the only thing the community role is about, right? And we wanted to expand it to everyone who is at that level. I think at last count, we're in the thousands. I haven't done a query recently. I'm kind of looking over it at Neil because he'll probably shout out the number if I look at him strangely like that and he'll just look it up. I'm totally joking. You don't have to, Neil, it's okay. What's that? There's thousands of users who have now been given the community role and those thousands of users all have the ability to confirm a new user who is still being blocked by like say Honeypot and Malum and some of those things that might be slowing down their ability to contribute to the community. But say you're in a contribution sprint. I'm guessing quite a few of you in this room now have the community role. If you're in a contribution sprint and you hear somebody said, oh, I just told me I have to wait 10 seconds, you can say what's your username, look them up, hit confirm and they now will no longer be blocked by that and that rapid ability to get people involved in contribution sprints, we think it's gonna really grease the wheels for that particular process. So it was a huge win to be able to roll that out. Another thing and Dries has touched on this, this notion of recognizing organizations and their role in our community. When Drupal was nascent, it was really about the volunteer hobbyists getting involved to do something to scratch an itch. It's increasingly become the economy of Drupal is being driven by large organizations that need a stable platform that's gonna work really well. So we're trying to be stable and professional and enterprise on Drupal.org. We also wanna recognize those organizations that are helping us do that. Really good example of that is the organization profiles and credit system. Someone has to have an organization profile in order to be awarded the credit. You can create one for your customer or organization that you belong to if you need to. But the basic idea behind it is that you'll be able to give attribution to the organization that you're doing the work on behalf of. So if my company is giving me time to work on core, I should check I'm at this organization so I could say Drupal Association or in this case, Frank could say that he's at phase two. He can mark that and by being given that time, he's then passing on that credit to his organization. In the maintainer UI where commit credits previously were awarded, you are now able to by saving the intention in that maintainer UI, you're able to give issue credit to users and organizations, which I think is an important distinction and a pretty significant shift because what it says is that we're valuing people who review but maybe didn't submit a patch. We're valuing organizations that give their people time to do reviews and some of those other parts and processes of contributing to Drupal.org. So big shift, I highly recommend if you aren't using this, you should because even if you're doing it on your volunteer time by marking I'm a volunteer, it gives us a much better picture of what the ecosystem looks like. We are gonna take this data and once we have the org credits, which we already have a fair amount, Dries shared some of the initial credits in his keynote. We're gonna be highlighting organizations that contribute and what that means is we'll probably have the marketplace listing ordered by organizations that contribute the most rather than alphabetical or purely alphabetical. We'll still have lots of filters so that you can get down to the type of organization that you may be looking for to help you with a particular project or process but we really want to give that extra visibility to the organizations that do the most. Selfishly, we also hope that this makes organizations give their people time to contribute back and that's an important part of this as well. It's not just about the organizations though because the changes in how we're storing this data make it much easier for us to show how individuals are contributing and so every contribution that an individual is making is also gonna be showing up on their personal profile and we're gonna be doing things to make that show up in a more meaningful way. I think it also gives us an opportunity to identify people who frequently contribute on particular types of issues and it gives us a better insight into how our community is organized around particular topics. So if we see an issue is tagged with accessibility and we see that people have a lot of issue credits for issues tagged with accessibility, we can go out and say well, they might be a good person to be a topic maintainer for accessibility or they might be a good person to get involved in a new initiative that needs accessibility review or something like that. It gives us a little bit more insight into those community contributions which we think is gonna be important and exciting. A lot of you are gonna be really excited about some of the things we have planned for issue workflow. Really big changes here. I'm not gonna go into it in too much detail because Tatiana and Ryan, TVN and MixaLogic, are going to be doing a detailed session on issue workflow a little bit later today. We've got this excellent example of an issue get flow of what it might look like. So I'm gonna say in order to find out what that actually means, you have to go to the other session. See how I did that? That's nice. I will say a couple of other things that come along with that issue workflow that I think are some key features that we're hoping to implement here. Inline editor so that we can get contribution from people who may be blocked by learning how to do the whole patch process which is a little bit of a daunting thing to do for your first contribution. We want code review incorporated into it so that we have a better process there and it's gonna have some integrations with our testing infrastructure as well that I think is critical. I love this concept here and Ryan, as I said, we'll be talking to it more but the idea that you can create an issue workspace, a get namespace that is dedicated to working on that particular problem that you can do it with the press of a button. That's gonna be cool and we're excited about that. Kind of like a pull request for lack of a, we're still trying to decide if we wanna call it a pull request just so everybody's on the same page. But also the idea that maintainers will be able to merge with the button meaning that we can really speed up that workflow and we see a test is passed when we see all the other issues it might affect through code review and then be able to push a button directly from within the UI on Drupal.org to make that get action occur. It could really speed things up. I mentioned the testing and localization already so I'm gonna kind of skip through this slide real quick. Content strategy and design. I mentioned earlier that it was going to really affect the way we work. We're shifting to thinking about content based not on what is the content type. Right now we tend to think of issues that belong to projects and everything else is a book page or a forum post. That's kind of a limiting way to look at content. We really wanna structure it by what are people trying to do. These are the major user tasks that we know we need to achieve with Drupal.org. We often joke that Drupal.org is part JIRA, part GitHub, part Wikipedia and a little bit of Stack Exchange all rolled together. And that's really what it is. It's our community's version of a lot of those tools in an attempt to have something that meets our community workflow rather than having to integrate all those systems together. Once we're looking at user tasks, it allows us to think about the information architecture of the site in a little bit different way. If you're big into code, you're gonna be going to the contribute section of the site and getting right down into the projects and initiatives that allow you to work on that code. If you're really into documentation or if you need documentation, you can go to the documentation portion of the site and work through that. And we'll have governance around each of these structures or these sections that will help structure maintainers for content on Drupal.org, which we're really excited about because I think right now there's a lot of question about, well, who really is the best person to maintain this particular page of content? And while documentation is something we still very much want everyone to be able to contribute to, there are certain parts of the site that are canonical. They need to be well-written and they need to be written by the right person. So having this structure of user task and also sections of the site gives us an opportunity to put some of that structure in place. So you might be wondering, like, how would we do that? Well, I mentioned earlier that by bringing in groups.drupal.org functionality into Drupal.org, we would essentially be bringing organic groups into Drupal.org. The organic groups that we'll most likely be starting with are the sections, which I just mentioned. We would be adding that functionality to projects, so suddenly projects would be able to have posts and they would be able to have documentation that was specific to their project. They might be able to have things like videos where somebody did a video tutorial related to their project. And all of that could be related back with navigation that ties it to the project. So that's a significant shift because it pulls a lot of that information directly to the point someone would want to consume it. I mentioned the user groups and really what we see user groups being are two different types of groups, the local user group that's about place, are you from Portland, are you from Spain, are you from Amsterdam. That local user group and being able to tie in that sense of place is really important. It's one of the things that I think groups.drupal.org probably does best. It's not as good for managing the events for those local user groups, but we're hoping to do some things about that as well. The other type of group that tends to exist out there is a discussion-based interest group. Good examples of this would be the accessibility topic group that lives out there or women in Drupal is another one that's a really good example. I would even go so far as to say that Drupal knitters or knitting in Drupal which is a heavy interest in our community. It's so big in our community. That's another good example of an interest group that we can support through that and it kind of talks a little bit to the diversity of our community as well. Organizations would actually become organic groups as well which means instead of being a node that was owned by a single individual you would be able to have several owners for the organization node. We would also be able to tie content like case studies and a few other things directly to that organization which I think is huge. It gives a little bit of control too for the organization because right now if you list an organization on your profile on Drupal.org we tie you to that organization page which can be a little bit of a problem when you have transition or secession within an organization, somebody leaves, somebody comes in. It doesn't make it nice and clean and there's no clear way to understand how to maintain it so we're excited about that. The last one I'm gonna mention is a content type that we're really excited about selfishly on the Drupal Association team. We need a way to communicate what we're working on and right now projects, they do a great job of showing you the last issue that was created or the last issue that was commented on but you get no sense of priority outside of the criticality rating and as we all know somebody selecting major or critical because they submitted it does not necessarily mean that that's gonna be the first thing you do. There may be a blocker in front of it that's normal that's preventing you from getting to it. There may be a difference of opinion about what major or critical means and ultimately your initiative leads tend to determine the order that they're going to work on things in and it's not always apparent. So initiatives has been talked about in the issue queues before as a potential content type. We're gonna definitely be implementing this in some form and basically what it'll allow us to do is have a prioritized list of related projects and issues that represent a body of work and because it's an organic group you'll be able to determine whether it's an open group that anyone can join and they can help you drag around the priority of those issues or if you wanna limit the number of people that can do that so that you can really stay focused on a particular roadmap of work that needs to be done. As I said, we're excited about this because it means I could take a lot of the stuff we've been doing with static pages and links to meta issues and meta issues with child issue after child issue after child issue. We get to put it all into kind of one common workflow. We're gonna be using some agile project management best practices and while we haven't decided on the labels you can assume that there will be something that shows you when an issue is in progress which isn't always clear right now. It will show you when something is in the backlog it's been prioritized but it hasn't been started yet. And it will show you things that are nice to haves that are sitting out there but maybe aren't in the current backlog and that's a minimum we wanna be able to show that in the initiative content type. Some nice to haves in there and may not be in the minimum viable product that goes out to start with but we hope to have at some point would be maybe burned down. So for instance if we have the core beta blockers which right now is an issue tag if it was an initiative we'd be able to have an automated way for showing that burned down. What you can do right now by integrating like five different systems and a special spreadsheet and it's a whole bunch of work for people who frankly would rather be working on core. So our hope is by having a couple tools that allow us to do project management in the open in a transparent community driven way that it'll kind of make us a little bit more nimble and it also shows best practices for how communities should work. Another key thing that we really need to do is make Drupal.org search usable. And really the main thing we have to do here is tweak some settings. Our solar configuration is pretty stock at the moment and we have some great examples to look to. I pulled in an example here from New York Public Library. One of the things that our content strategy is also going to address is for every content type we create there will be a display mode for search and that display mode for search will have the contextual information that is important to that content type. A blog post does not have the same teaser requirements as an issue in the issue queue or a project that holds code. They have very different data that should be showing on our search and right now they all look like a pretty basic Google result. And even Google doesn't do that anymore because they tend to show a whole lot more metadata about the search results that they have and so we're trying to get closer to that. Example we see here like the press release looks a little bit different from a page, looks a little bit different from a blog. And maybe this is even the best example. I managed to skip the second one I had. You guys get to see the scroll again, you love that, right? Display modes that are contextual. So this is the example I have where very different content types look different. So you see the first one here, the county service actually has a phone number. Well that's an entity field on that county service and it shows for the search result because that's the most important thing somebody needs when they come to that. They need a link to the service, a description of it and a phone number. But a site, by having the site label on it gives you a different sense of what am I gonna get whenever I click on that link. So this is an important change that we wanna make to Drupal.org search. That's part content strategy, part tweaking the settings to really get us to a better end result. So you may be asking yourself, how can you help? Right now at Drupal.org slash roadmap, we do have our major initiatives documented. We have links to pages that describe each of the initiatives and there are issue tags that have been created. Once again, the list that you see when you click on that issue tag are not gonna be prioritized just yet because we need to build that initiative content type. But it does have the list of things that we're working on and we're trying to keep that really out open in the public. We also send out notes to our advisor lists. We send out notes to the change notifications. All of our change notifications get emailed to people if they wanna subscribe for them. That information is all under Drupal.org slash roadmap. So if you wanna get involved, the best way is to get in there, be ready to give feedback and then be ready to move relatively quickly. Now that doesn't mean if you comment on something, we're gonna shift priority to that thing, but it does mean that if you comment on something we are working on, you're gonna get a pretty quick response because if we are working on it currently, we have a team that's doing it full time now and that kind of changes the dynamic of how quickly things can happen for Drupal.org and we're very excited about that because we're all community members and we all want to see a better tool for allowing us to do our collaboration and our work together. So I mostly wanna open this up to questions at this point. Feel free to ask clarifying questions. Feel free to give us feedback on what you feel is missing from the roadmap that you think needs to be there. I wanna leave some time to just hear from all of you. So the next 10 minutes are all yours. Thank you. Hey, David McKenna here. I'm honored to have some of the modules as ones that are being added to D.do. I was wondering who should I speak to about performance tuning those because I know there are some problems with some of the ones I maintain when they're taken to the scale of having millions of entities. Definitely. Are we thinking like the organic groups type thing? No, panelizer made a tag. Ah, yeah. Those, specifically. Neil is definitely the one that you wanna hit up. So if you have specific feedback, Neil is basically our solutions architect. He's had the most experience with Drupal.org and knows how, he knows where all the bodies are buried. So if you know of a particular body that's buried in a place that he doesn't know about, it would be good to contact him and let him know about it. Okay, thank you. No problem. Jimmy Hoffa of Drupal.org. Wait, wait, no, Jimmy Hoffa was the one buried. I don't want to bury Neil. That sounds like a bad idea. I was this project manager saying that. This is Matthew Tift. A lot of the stuff that you're talking about today is really exciting. I like the fact that you guys are trying to emulate some of these other tools like what they're doing with GitHub and Jira. And it really sounds like the tools that you're building could be very useful to lots of folks, especially now that GitHub was, or GitLab acquired Getorius. The free software community reacted pretty negatively to that, started looking at other projects like Calathea and some of these other open source tools. I was just wondering if you have any plans to be able to sort of offer, or think of this as a product or an open source project that other folks, like maybe a company could use to do hosting for their clients or an organization that wanted to actually use some of these tools like in their own workflow and then be able to contribute back that way. I definitely think we're gonna be using open source for all of this. And so we're gonna be looking for best possible solutions to bring in and incorporate. A good example would be, and I know Ryan's gonna talk to this a little bit later, but if we do inline editor, inline code editor, and inline review, the best tool is actually probably the open source project that GitHub is using, which is the ACE editor. So that would be a good example of us pulling something in that's already there. We're also looking for, in that code review processes, are there tools that we can incorporate it in that we can kind of add to our stack? And so we're using that, which means we can contribute back to that project as well. In terms of it being a finalized product where we can then offer it to others, there may be a little bit of a challenge there only because it's gonna be heavily integrated with our Drupal issue queue. And so there may be some other projects that would be a little bit hesitant to install an entire Drupal and project, an issue stack in order to achieve that. But we'd be open to it. And I think the possibility is, I mean, I would like to get to the point that we have a tool that meets the needs of the community for how they need to interact with each other. And in that process, we may find that we have something that can be extended beyond. But our first priority is definitely to the Drupal community and figuring out how to make it work best for that. Cool, thanks. I see Roy running out. Yes, Roy, part of the content working group. So there's a list of priorities. We know you've been working on new user engagement and profile improvements. Have you defined how you decide that this is now done-ish and is not a priority anymore? So the other thing gets bumped? That's a very good question. And we've started the process with the working groups to talk about how do we do reprioritization on a quarterly basis. Because I think what we should be constantly doing is looking at the things that we think are the most important and evaluating them against the current list. That's not to say we throw it out every three months, but we should be rolling things in and bumping the priority of things accordingly. So I would fully expect that new account creation won't be the name of the first initiative anymore. The first initiative going forward is gonna be one of the next ones on the list. Or it might be something new that we need to pull in. If I were to say what is the one that we're giving the most attention to right now, it would probably be Drupal CI. What is the one we want to give the most attention to after Drupal CI is done? I would say that would be the issue workflow. Parallel to that, I think we can be doing some of the content strategy implementation, so the sections and the initiatives. Okay, yeah, thanks. Yeah, other questions? Well, I wanna encourage you all to join us at the sprints on Friday. We will have a table set aside for folks that want to help and work on Drupal.org and catch up with someone for what we're doing. A big part of what we do during the sprints at Drupal Cons is enable others. It's kinda hard to do your agile list when also getting new volunteers involved, so we're really gonna be focused on enabling on Friday. So if you have the time and you wanna get involved, please join us. Also, all of these are being recorded, all the Drupal.org track sessions, so I'd love to see them get some reviews and ratings so we can get a sense of how successful it is. I feel it's been pretty successful because I get to hear things like the feedback being given from the floor, but I wanna hear it from others as well. So thank you very much. Have an awesome rest of your Drupal Con.