 So I'm going to be going over our strategic roadmap today, and as I get started I want to give a little bit of context setting for where we're coming from. This year has been an incredible year of change for the Drupal Association. Besides hiring a CTO, we've been busy hiring an engineering team. We've been doing tons of infrastructure improvements. We've been removing lots and lots of technical debt from a website that is essentially a 13-year-old website that's, to our knowledge, the longest continuously running Drupal website. It's huge in its complexity. It's been upgraded in place every time, which there's very few Drupal websites that have done that. They usually do a migration path at some point. That's just really a huge amount of technical debt to work through, and also to understand because there's a lot of complexity there that we've had to get our team up to speed off. We've had a lot of quick wins that we've focused on. I'm going to go over a few of those. I'm going to talk a little bit about the user research study that we did starting back at DrupalCon Austin that went through the summer and kind of the outcome from it. Also the working group ideas, ideation, and prioritization process that we went through that helped us decide on the initiatives for this coming year. So first, growing a Drupal.org team, if you can believe it, October 2013 we had two staff, both were contract that were maintaining Drupal.org with the community. And that was it in terms of full-time effort on Drupal.org. All the other effort was completely volunteer driven. We hired a technology manager for the Drupal Association in October of last year. He also did some work on association.drupal.org and on the DrupalCon sites to help kind of support that. And then we started going fully into a hiring mode. Starting with an infrastructure lead, Rudy Gagar, and hiring in some technical support for Drupal.org. Liz has been key in actually responding to a lot of the support requests that come in on Drupal.org and helping make sure that we triage what's coming in and attack the right things. So then I started, my first day was actually the end of March. And as you can see, we very quickly ramped up the team. We now go to 11.5. That's 1.5 louder than 10, and yes, that is a reference to SpinalTab. So I want to really quickly reiterate the thanks to the supporting partners. Without these people, we don't have funds. These companies have all contributed at a very high level to make sure that Drupal as a product is successful. They've helped us buy the servers in hardware, obviously the dedicated engineering team. They're helping us increase Drupal adoption through marketing Drupal. And they're just making a lot happen for the community. So again, thank you. I want to talk a little bit about some of those wins that this team that we've been building have been able to accomplish. And this is while getting used to the new environment, while learning about the system. We've launched a CDN. So we now deliver from the edge all around the world. We've launched APIs. We have a Rust API that's available for Drupal.org at this point. If you're interested, please check it out. We launched semantic versioning and removed some other Drupal 8 release blockers, which was really critical to getting a Drupal 8 beta out the door. We've been doing a lot of work to improve our quest to reduce spam on Drupal.org and the subsites. I know that sounds like not a very glamorous thing, but it's actually something that's really important to making sure that Drupal.org stays very stable. It's also not something that's very glamorous. So it doesn't tend to be something that volunteers are going to jump in and like dig into the deeper aspects of. So it's been really important to have paid staff to jump in and take on those tasks that really, it's hard to jump in as a volunteer and do it a few hours a week. It's something where you need to have kind of dedicated people that are focused on it at all times. We've also been doing some cool things in terms of trying to improve the new user experience. We've done some bakery customizations. We've shifted it so that when you create a account on a subsite, such as a Drupal.con site, it creates it only on Drupal.org. We've been increasing our use of mollum on some of our subsites, which has allowed us to do a little bit better job of spam detection on, say, like a Drupal.con site or sites like the association.drupal.org. And we're really changing the steps behind what it means to trust a user. And part of that is I'm going to go into it in a little bit more detail whenever I talk about our account creation initiative. So some other big wins that we've had, we've launched a lot of sites. Drupal.con Austin, Drupal.con Amsterdam, Drupal Jobs. For those of you who aren't familiar with that, we now have a job board that is available to the community. So if you're an employer looking for someone to hire or if you're looking to be hired, please go to Drupal Jobs, give it a look. We've launched Drupal.con Latin America. We have a Drupal store that is now available so that you can buy Drupal gear online. We've upgraded quite a few sites, too. API.drupal.org is on Drupal 7 now. Localize.drupal.org we're in the process of. And groups.drupal.org we're in the planning stages with. And I'll talk about that in a little bit more detail as well. Some of the other wins is we've really worked to become more enterprise in the way that we support Drupal. And particularly Drupal.org. We've done a really good job of documenting what we have, which really, there wasn't a comprehensive list of, this is the sites that make up the Drupal ecosystem. We've enabled change notifications within the team. So we're actually sending out a weekly notification on Thursdays around noon Pacific, where we basically tell everybody what we're planning to change the following week. And that's been really important to making Drupal.org more stable, making sure that people know what's coming next. On our team we've introduced an agile project management process. We're using a kind of a combination of Scrum and Kanban for the different teams to make sure that we are addressing what we need to address and also being very iterative in our approach to building Drupal.org. As part of that, we've introduced a product planning and lifecycle. It's really about looking at all the sub-sites of Drupal.org and figuring out where they're at in their lifecycle. Are they something that is just being introduced? Are they growing? Are they mature? Are they something that we actually need to start looking at retiring? And that's been really important because there's actually a lot to the Drupal ecosystem for us to keep track of. We started tracking time, which I know sounds like a small thing, but it allows us to do a better job of reporting back to the community where we're spending our time. We just started that in the October timeframe. And we've really tried to improve the way we support Drupal.org. There's less open issues. Answers to those issues are happening more quickly. We've also opened up two new channels for support. If you don't have a Drupal.org account so you can't submit to the issue queues, or if you're having a problem logging into your Drupal.org account, you can email help at Drupal.org. And that goes through our Zendesk account. We are also responding to support requests on Twitter. So it's really kind of changed the way that we're able to be responsive to the Drupal community. When I talked about that inventory of here's everything that exists in the Drupal world, we've really tried to break down here are all the sites that we're supporting. And as you can see, the Drupal ecosystem, all the sub-sites that make up Drupal.org is pretty extensive. If you look at the, in addition to that, if you look at the community supported things, so these are things that the team don't directly touch, but are built off of the systems that run in the Drupal.org ecosphere. We have to be really careful when we make changes, we could be affecting something that is downstream. And so we want to be aware of that. And we also want to give notifications of that. So we've worked hard to make sure that we know what we have and also how it might affect others. So I want to go a little bit into the user research that we started in the June timeframe with DrupalCon Austin. We had Whitney Hesse come in as a consultant and she worked with us, the content working group, the software working group, and the infrastructure working group. We did some onsite workshops to kind of talk through what is it that we want to do with Drupal.org? What are the objectives for Drupal.org? We conducted over 30 user interviews, many of them were in person at DrupalCon Austin. Part of them were remote over Google Hangouts or conference calls in the following weeks. The participants included people who were kind of all over the spectrum. We're working right now on actually pulling together some survey information that we're going to be including in the early next year. And we hope to get a little bit more comprehensive global input because we definitely got North America, South America, and Europe covered. We would love to get some more input from our users in Asia and our users in Africa because we think that there's that global impact of Drupal is huge. Out of that user research, we really came to an approach looking at personas that says that the primary persona, the way people come to Drupal.org, is in a state of increasing skills. So you come into Drupal.org as a newcomer. You progress to a learner. You progress from there to skilled. And at this point, you're usually making some of your income off of Drupal. You then can progress to expert or master. And as you can see by the pyramid, basically, there's a larger number of newcomers. And it increasingly or decreasingly represents the number of users in our community as you get closer and closer to the top. So there's much fewer masters than there are newcomers to Drupal. Some of the key things that we're going to be focusing on are that kind of learner, skilled, and expert. These are the 3% that we have published on Drupal.org. Learners really are trying to get through the website. And it's easy to go from newcomer to learner, but it's much harder to go from learner to skilled. Because learners are coming into Drupal.org with very little language to help them describe their experience. We have a lot of jargon. We have a lot of new terms that they have to pick up on whenever they start using Drupal. At Skilled, they're really getting to the point that they can do a lot with Drupal. One of the biggest pain points for skilled users is that frustration of finding a module. So they're trying to find the right thing to help them build a solution for their customer or for their organization. And that's an area where they can do a lot, but they definitely have some pain points that are directly around that. How do I build what's next? When you get to the level of experts, this is where we start seeing a lot of code contribution. And they really understand the Drupal system well. They can build modules. They can contribute. Many of the experts are in that space where they're beginning to look at contributing to core. And we really wanna support that effort by the expert. If we were looking at the most important transition on Drupal.org, it's that transition from learner to skilled, because if we can grow learners into skilled Drupal users, we're increasing the size and impact of the Drupal community. And we see that as one of the key areas to focus on. I think whenever you look at the initiatives that we have, that's the area that we've really spent the most effort with. We're certainly doing things for experts and masters. We're certainly adding content for newcomers. But in terms of features on Drupal.org, we're gonna be focused on moving people from learner to skilled. Josh, I have a question really quick. Sure. Is localized Drupal.org supported by the Drupal Association? I'll go into that in a little bit more detail a little bit later on. But the short answer is we host it. We certainly push the code to it. So whenever there's a code deployment, that goes through our team. But most of the work is actually at this point done by volunteers in the community. And one of my asks today is going to be getting in contact with the people who are a part of the localized project because they need some help in doing the upgrade from Drupal 6 to Drupal 7 and removing some blockers there. And it localizes critical to the eventual Drupal 8 release because localizes how we translate Drupal into other languages so that people can use Drupal in their native language. Perfect. I think that answered the question. Thank you. Excellent. So one of the reasons why we're building for learners is we don't really need to build for masters. We don't need to build from the top of the pyramid because they already know how to work around all the issues on Drupal.org. And when I say issues, I don't mean issues in the issue queue. I mean issues as in all the little problems on Drupal.org that we've all gotten used to over the years. We're certainly gonna be getting rid of those. But whenever we're looking at the biggest bang for our buckets, definitely helping that learner become skilled. We are going to have newcomer content that is focused on kind of the marketing of Drupal. This is gonna be for the people in the organization that can make the decision to move to Drupal, whether that be the CEO or the developer or the designer that's saying, hey, this is the direction we should go. We should move to open source because it's the right thing to do. And so when we work for newcomers, when we build things for newcomers, it's usually gonna be from a marketing bent and it's gonna be giving them the tools to convince others that Drupal is the right way to go. So all of that user research had to be turned into a plan. And this is where I'm really gonna go into kind of the details of how we made the decisions of what comes next. So first of all, we have the working groups. For those of you who are not familiar with the working group structure, we have working groups that are focused on Drupal.org. And those are the Drupal.org content working group, the Drupal.org software working group, and the Drupal.org infrastructure working group. Each of these working groups are a mixture of volunteers and staff that are focused on helping decide the future of Drupal.org. They're collecting all the information from the community and they're processing that and they're turning it into something that's actionable for the team to execute on. We've done ideation, particularly with the software working group for several years now. We've come back with a lot of themes year over year that were pretty much the same. The same features were being requested year after year. And really what we were seeing is that it was difficult to get volunteers to jump in and tackle these really meaty problems that we're going to take weeks of implementation because whenever you're donating time to Drupal.org, you just don't have months to give. You have 10 hours here or maybe two weeks there, but it's not a sustained six month effort. So we knew we were going to have to bring in either contractors or staff to do some of this work. And the working groups were aware of that. It was really about getting that next step going where we had someone to help coordinate that. And that's why building up the engineering team has been so critical. Out of the working groups, we really came up with this notion that there are three major objectives for Drupal.org. And this came out of a lot of the Austin user research workshop work that we did and then some honing that we did in the July timeframe. But the three objectives, which are all ranked number one on this slide, that's a, I just caught a typo. So I'm very happy about that. Be the home of the Drupal community. Actually, these all should be ranked number one. Be the home of the Drupal community. The central source of relevant information, answers, collaboration, education, and talent. So really being where the community comes to do all of those things. We want to provide a learnable efficient tool set that helps coordinate the advancement of the Drupal ecosystem. So making it easy to jump in and use Drupal, making it easy to jump in and contribute to Drupal. That's one of the big areas there. We also want to encourage people to develop themselves. Their Drupal proficiency, their careers, and build human connections over time. And I think this one really ties into a lot of the profile work I'll be talking about in just a few minutes. So when we looked at all the long list of things that we could do, we really had to spend some time prioritizing our efforts. There are over 16 production Drupal websites in that Drupal.org ecosystem. There's nearly as many production services that are integrated between those sites. Things like search, updates.drupal.org, our FTP subsystem, like all of those things contribute to that larger ecosystem of sites and are all services that the community are using. Between all those systems, we push over 20 terabytes of data per month through Drupal.org. And that's a really phenomenal number to think about. 20 terabytes, that's how much collaboration and community is happening in that space. And that's pretty significant. It also costs a bit of money and that's where, again, having the Drupal Association be able to pay those bills thanks to the support of sponsors and members, that's been one of the key bits that we've had, those supporting partners are critical. With so many things to work on, it's easy for us to lose focus on a particular set of things that need our attention. And this is where the prioritizing the efforts, it's not saying that we're not going to take care of the support things that pop up that are critical to keeping the site running. But we are going to say, here are the initiatives that this team can focus on and that's what we're gonna stay focused on. Because if we try to do everything, we won't do anything as well as we need to. And that was a real, we heard that time and again, as we were going through the prioritization process from folks, they were like, this is so good to be able to say, these are the things we're gonna focus on. And because we can't focus on everything, those volunteer teams that can jump in and help focus for a short time on something that maybe isn't in our wheelhouse right now, those are so critical because that still moves for those areas. Having the 11.5 staff helps, but it's the volunteers that are going to get those smaller initiatives, those community initiatives moving forward. And working groups, one of the big things that we've said over and over is they're helping us keep the focus. They're helping us stay focused on the things that we said we were going to do and keeping us accountable. So first we prioritized by objectives. And next we prioritized by the persona and revenue. And you're seeing kind of a little bit of a chart up there where we started scoring all the various projects across our objectives. And this is a tool we've been using that's been really, really helpful. It's a tool to get to consensus where consensus is hard to get to. And out of that with the software working group, the software working group took requests from the content working group, from the infrastructure working group, from our tools teams that have been set up that report to the software working group. Also from the documentation, the documentation working group, the technology working group, which are working groups that report directly up to Drees as a part of that governance structure. Took requests from all of them and then we prioritized them across our matrix. And we really came up with a top 10 list that looks something like this. But we weren't done yet. Because what we realized is as we went through the user research and the personas, we ended up with a little bit of a different spin on here's a set of prioritization to focus on. There was a lot of overlap between the two though and that was something exciting to see because it meant that essentially the same things were important to most people. After we got done looking at that overlap, it allowed us to take and basically break all of our work down into four areas that we were going to focus on. We have things that will help us continue to fund Drupal.org. We have sustaining support and maintenance. We have community initiatives and then we have board and working group priorities. And so by having those four areas that we're going to kind of outline here are the projects that we can actually tackle on those areas. So in terms of funding more great work, we're gonna spend some time continuing to improve Drupal jobs. We're doing work to make sure that the supporting partners benefits that we offer are the best that they possibly can be so that our supporting partners continue to give at that level. We're gonna be doing work on the DrupalCon websites because it's critical for us to have that big community gathering several times a year. And that's work that we have to do to make sure that that happens. We're gonna spend a little bit of time on Drupal Store but we've actually made the choice to keep that as simple as possible so that it just provides the gear that people wanna be able to pick up that says Drupal on it so that they can help support Drupal but we're not gonna be spending a lot of time building a store because that's not our key focus at the moment. We also have an opportunity going forward to do more with advertising and marketing on Drupal.org to make sure that we're basically making it a self-sustaining system. Long term, we wanna make sure that Drupal.org is healthy and well-funded and one of the ways that we can do that is by diversifying where the funds come from. So we spend a little bit of time on funding Drupal.org and then the next area which is a much bigger chunk of our time is the sustaining support and maintenance. Now this is how we keep Drupal.org performant and secure. We're all about making sure that our uptime is great, that page response is great. We're supporting the old test spots infrastructure so every time there's a major sprint at a big Drupal event, we're spinning up more test spots so it can handle the load. We're doing support for our users which I talked about a little bit earlier with Liz jumping in the queues and Tatiana and Neil and others being able to respond to the issue queues and email support more quickly. We've improved our automated testing infrastructure so we now have a lot of behavior-driven design, a behavior-driven design approach for using Behat, we're using Mink to make sure that we have reliable deployment processes. We've also been doing a lot to maximize hardware. I'm very excited that we have some new database servers that are gonna be coming online soon that should give us this huge performance boost in the area of database performance. Very beastly machines that we're installing over at the open source labs in Corvallis as a part of our infrastructure to make sure that it's as performant as it can be. Part of the sustaining support maintenance is really about that infrastructure, that baseline that we put everything on because whether it's being used by our own staff or by volunteers who are jumping in to contribute to development, that work is kind of critical to keeping us moving forward. The next area that I wanna talk a little bit about is community initiatives and these are areas where we're not going to focus staff but we will support with staff if we can find community members who will jump in and help out. We have a great team working on localize.drupal.org. They're moving it forward in a really positive way. People like Gabor and Sebastian who are jumping in and making sure that localize.drupal.org is getting ready for an upgrade to Drupal 7 that it has all the blockers out of the way from Drupal 8 standpoint so that we know that we've got the ability to localize Drupal 8. We also have some great support in test bots. We've got a team that are looking at next generation test bots right now. I just got an update on it yesterday. It's so exciting the work that they're doing. Really getting that test bot infrastructure to a repeatable process so that Drupal code can be tested whenever it's submitted on Drupal.org. They're doing such a great job on that. My team doesn't have to spend a lot of time focusing on it but we're there so that whenever it gets ready to start being implemented we can jump in and spin up the servers and do that infrastructure support at that level. So that's been, those are two really good examples where the community initiative is just taking and running with it. Another good example is the two factor authentication. There's several people from the security working group that are working on this right now. That team is looking at two factor authentication for Drupal.org trying to make it more secure for particularly administrative users of Drupal.org because the level of access that they have, we wanna make sure that it's as secure as possible. Some areas where we don't necessarily have someone in the community running the initiative just yet is around QA and support system. That came up in our user research. That came up in our software working group prioritization. The issue that we run into there is we don't have a great way forward with it so we would love to get some community involvement. Some people who would be willing to kind of lead that initiative and run with it. So a QA and support system, if that's something that you believe really strongly that Drupal.org should provide, please contact me. I would love to get you connected with the working groups and get that initiative started at this point. And an initiative that we'll start up at a later time is the reviews and ratings for projects. As you'll see in our initiatives that the staff has focused on, we really wanna improve search of projects. And at some point we're going to have a rating system that are maybe a huge community to wish to rate and calculate where a project should rank. And that's gonna be a huge community push coming up. We're definitely looking to set the program right now to get some people who volunteer for that. So I'm gonna go into a little bit of detail about the things that the engineering team that we've built up is going to be focused on over the next few months. These seven initiatives are the ones that we will spend the majority of our time on and really focus on. And more about this can be found on Drupal.org slash roadmap. I'm gonna mention that URL several more times because it's really where I want people to go to keep track of the initiatives that we're working on and so that they can also get involved in commenting on the issues and helping those issues move forward towards completion as quickly as possible. So let me dive into each of these in a little bit more detail. First of all, better account creation and login. So it's never a priority to have great login until it breaks and an example of login and account creation breaking is when you get overwhelmed by spam. Back in July, we had a pretty significant spammer attack. The team jumped in, we figured out some solutions. We got rid of the spam that was showing up. I believe the July one was related to association.drupal.org. We were able to get the spam off of there. The content wasn't there anymore. We thought we had it under control and then in September, we saw it happen again and this time it was associated with a Drupal consite. And the reality is, in neither case, was it a case where there was oversight where we failed to look for something. It was a case where it was just something that had never really been tackled comprehensively as a part of a Drupal.org process. So as we were doing Drupal jobs and we knew we needed to be able to launch it with a really solid workflow that would prevent spam, we started looking at this better account creation and log in process and this workflow flow that we're looking at establishing is gonna make it a lot easier on newcomers who are coming to the site and learners who are maybe just getting started with Drupal. We don't want spammers to love us. We want spammers to hate how hard it is to create content on Drupal.org. And we want users, real people that we trust to love how easy it is to create content on Drupal.org. And that's a process that's important, but more importantly is that we start engaging users and this user engagement workflow that we're gonna be putting together is really gonna be about getting people who have signed up for an account at some point, getting them information about Drupal on a regular basis and also making it really easy to move to the next stage where they're contributing content, maybe commenting on issues, maybe contributing their first code and then rewarding them for that process. We think this is really important to improving Drupal.org. It's also a key area for us to approach from a security standpoint because if it's easy for a spammer to create an account, it's easy for anybody that we might not want to have an account to jump in and create Havoc. So this user engagement process is gonna allow us to identify the people that are potential contributors and really help engage them and move them up that path. A little bit is organization and user profile improvements. I wanna give a little shout out to Danny Ordon and actually the screenshots that you see here where we've got some comps are based on Danny's work and then they were tweaked a little bit for the DrupalCon Amsterdam presentation. They were given a little bit of a kind of combined UI by Kevin O'Leary. And the thing that you'll see in all of these is that we really are moving towards giving better credit to contributors in our community. These are some of the things that we heard in user research. We heard that we wanted to know what contributor, what contributor knows about a particular area. Where is their expertise? We don't wanna know how long they've been around. We wanna know how connected they are with other members of the community. We wanna show the community our own skills and expertise on our profiles. And we want to show the community too when they can trust an answer that is being provided as a part of an issue queue or when they can trust a code that is being submitted as a part of an issue queue. And one of the ways that you get to that trust is by showing people the history of things that you've done well. And this really ties to the idea of improving these profiles both for users and the organizations that they belong to so that we can give them the proper credit about how they're helping to grow Drupal and make it move forward. This is a slide that kind of shows a sample company. A little shout out to Lullabot here. They're one of our supporting partners and they're also a great company to work with. They have a lot to offer. A lot of our companies that are involved in Drupal have a lot to offer. And we don't do a really good job of highlighting those contributions. So what we'd like to get to is the idea that we have some shared iconography that shows the things that they're involved in that gives them point totals. We're kind of building on the idea that there's a lot of different ways to contribute whether that be through providing training or whether that be through providing funds directly to the Drupal Association to help fund Drupal.org hosting and staff that are working. Whether that be contributing code, all of those are valid contributions that we want to bubble up in these organization profiles. We also want to bubble those up in the user profiles. And in fact, the user profiles, this is the key area that makes an open source project successful. It shows the things that they've done to make the community grow. And whether that's code contribution or in the case of Danny, like an example is she's done a lot of UX and design contribution and we want to be able to highlight that as a valuable thing as well. And so we're excited about some of these changes. These may not be the exact way that these pages will lay out in the end, but it's a little bit of an idea of what we want to move towards. Organizations are key to our growth. Individuals that power the big organizations that are in the small organizations that represent the Drupal community, they're the ones that are helping us move Drupal core forward and they're the ones who are giving us contributed modules that are key to building solutions on Drupal. So we really want to highlight that. And what we're looking at is ways to tie organizations and their users to each other and allowing a user to contribute, a maintainer to give credit to that contribution and for the user giving the contribution to be able to give credit to the organizations. So it kind of ties together that web of the three touch points that represent a major contribution. Another initiative for this coming year is gonna be responsive redesign of Drupal.org. Now there's two parts to this. One area is the work that was done at Zegged and the Dev Days and also more recently the QAN testing that occurred at Bad Camp and that was all around the responsive blue cheese theme that is being used on Drupal.org is the main theme. We are really close. We have a code review process that we're going through right now. We're hoping to be able to launch that by the end of the year and we will have initially responsive version of Drupal.org. We're very excited about this. The ability to get to this great content on mobile devices, on tablets. That's step one and then step two is a more comprehensive redesign that is being led by the Drupal.org content working group. It started with the user research where we got our user personas. We're in the process right now of finalizing a content strategy selection. We're selecting a vendor to help us with that process and they're gonna be helping us with the content strategy really figuring out what content types we're missing on Drupal.org and also an improvement of the information architecture because I'm sure all of you out there have at one time or another had that moment where you're like I know I've seen it on Drupal but I don't know how to find it. I'm just gonna go search in Google. There's just not a good path to get to certain content on Drupal.org and we wanna improve that with an overall information architecture overhaul. And we're gonna be working on with the content working group is establishing a design library and a design system that is a pattern that can be used across all the Drupal.org sites and that set of patterns will really make it easier to use Drupal.org and we see that as a key area that we need to improve in the coming months. Responsive also because we live in a community that frankly we need to go bigger as well as go smaller because a lot of our developers are sitting there with two maybe three monitors they're doing their work. When they're in the issue queues we need to give them full advantage of the real estate but maybe when they're on a mobile device and they're looking for just enough information there we give them a little bit different experience. So we need to be responsive across the spectrum the really big screens all the way down to the really small screens and we see that as kind of a huge next step and where we take the responsive redesign. Another one that is out there that has actually seen a lot of traction since DrupalCon Amsterdam is the work that we wanna do towards the get an issue workflow. It's a concept called issue workspaces. Ryan Aslet from our team did a great presentation remotely to DrupalCon Amsterdam with some key contributors in this area and there was a lot of excited response to it. So I'm gonna go into it in a little bit more detail so folks can get a sense of what it is and see if they wanna jump into the conversation and help contribute. A lot of people have compared our get situation right now to this epic battle with GitHub and I don't really see it that way but just for fun we had Lee who's on our marketing team she's our content writer. She has OctoKitty and DrupalCon fighting with lightsabers on a cloud and I think that sums up our get an issue workflow needs is that we need to battle this out with lightsabers. Not really. The conversation though has always fallen back to this idea of we need pull requests or we need to fix get or we just need to migrate and none of that is particularly simple. Many of the contributors on Drupal.org don't feel that pull requests is implemented on GitHub would work for the current workflow that we have in the issue queues. They recognize that a better workflow would help build proficiency in new contributors and they all recognize that it works kinda but it could be a whole lot better. Our options, our status quo it's not really an option. Moving to GitHub, switching to a new internal software tool or we could modernize the Drupal.org workflow and we've heard this over and over again and there's if you go to Drupal.org slash roadmap we've actually linked to some of these conversations that have happened before. They're great conversations. They all kind of get to this stuck point of yeah, but and I think we found a way that allows us to get past that. We have to integrate with GitHub at some point but just migrating to GitHub would be a huge project. User accounts right now would not be compatible. They wouldn't directly tie between the two. The workflow change would also slow down Drupal 8 development which is something that none of us wanna see happen. So we need to look at figuring out ways to do the integrations directly with Drupal.org and one of the big bits that we have on Drupal.org that a lot of other open source projects don't have that's kind of our secret sauce is we have the canonical repositories for all of our modules and themes on Drupal.org and we provide updates.drupal.org which allows every Drupal site to kind of call home and see if there's a new version available and that particular feature is kind of our secret sauce that makes Drupal really successful. There's many other ingredients to that secret sauce but that's one of the key ingredients that I think makes Drupal.org particularly successful. We can do an improvement. We can fundamentally change the way our issue queues work now that we have a dedicated team to spend some time implementing this. The approach that we are suggesting that we've done a lot of work and research around is a concept called issue workspaces. It uses a new feature that's gonna require us to upgrade our version of get to a little bit newer version that has a new feature called get namespaces. Get namespaces are very similar to the idea of per issue repositories and it's gonna allow us to do issue queues that have kind of full get integration. So right now our patch process relies on someone going through a get process outside of our issue queues to create a patch file. They then upload that patch file to the issue queues and then a maintainer can download that patch file and apply it to their get branch and work from there. We'd really like to simplify that whole process so that maintainers and contributors are working from get to get rather than working from get to patch to get. And to do that we're gonna have to make some changes to the issue queues that allow that integration to happen but once we do it's gonna open up a lot of possibilities such as inline editing and other great features that I think is gonna increase the total number of potential contributors to Drupal.org. So we're very excited about this. We're doing the kind of preliminary study on what tweaks and upgrades we need to do to get the blockers out of the way so that we can begin full force work on this area. A couple of big bonuses to this approach is it's not gonna break the current patch process. We can basically create a commit on the backside whenever somebody uploads a patch. And that means that people who have a workflow that they're very familiar with and that's how they've contributed for years. We don't have to change that. But what it does do is it allows us to give better tools for particularly people who don't want to use that old process or who are used to the simpler processes of like say the GitHub process or running their own private repositories. It's also more easily integrated with our user and organization credits that we wanna implement. So when we were talking about the profiles and be able to say that a contributor gave something we'll have that integrated into the issue queues so that we're storing that real time and we're able to give that credit pretty much real time as soon as the maintainer says yes, this was helpful we can pass that back to that person's user profile and we can pass that on to an organization profile and let it change those metrics that we're using to display how much and how frequently someone is involved in the community. A little example of what this might look like is you basically trigger the creation of an issue workspace. Someone might see some text cleanup they wanna do they can do it with an inline edit that person then pulls it back into what they were working on. They kind of work through going back and forth. You guys didn't need to see my calendar, apologies. Going back and forth with other people who are going to help out with this particular project. Maybe code gets committed in that doesn't get accepted. Maybe some additional inline edits are made but when it gets down to the end we wanna make it so that basically that maintainer can push a button and it brings in that contribution with the whole chain of credits to the people that were involved and then commits it into the branch that was involved. This is a real life example of a progression instead of it being get polls and rebasing head and that sort of thing this was all done with patch files but this example shows a workflow that could work that would move us towards something that could be done directly in the get space which we think will kind of accelerate the process at which developers can work. It'll make it a lot more efficient. It also makes it a lot cleaner and easier on maintainers to pull things in whenever they see that it's ready to go. It's worth noting that every time one of these things has a commit to that issue workspace we're also running that commit against test bots getting back results on that as appropriate so that we can see oh yeah this doesn't break or cause regressions to the code that's being contributed. So it's a really exciting way to approach what has been the great get problem up till now. One of our other initiatives is gonna be making Drupal.org search more usable and related to that and it's one of the other initiatives on the list is improving the tools to find and select projects. So we've heard in user research that people really want to find the information quick. They wanna see what modules may be available to build a particular feature. They wanna figure out if the module is worth using. Is it maintained? Is it going through, has it been abandoned? Is one of the things that people would love to be able to see as it relates to modules? We need to be able to show that information more readily on Drupal.org. And it's not rocket surgery. We can do this. We can do a better solar settings or maybe look at some alternative search engine systems like Elasta search. We can do search displays that show just what you need and really kind of hone in on just the right information at just the right time so that Drupal.org search is usable as opposed to always having to go to Google. We can add facets that are a little bit more contextual that are more performant than the filters that we have on the module search pages right now. We can also make organizations and users searchable. And I think this is something that people have been dying to have for a long time, because maybe you know somebody's Drupal.org username, but you cannot track them down on Drupal.org because there's no great way to search for a user unless you know the hidden search page. And that's something I think we can really make better. It ties into all the other initiatives that we're working on in terms of making it easier to contribute, making it easier to see who's contributed and making it easier to select the right stuff to build the project that you need. Around selecting projects, one of the things we've heard over and over again is that notion of ratings. And while we have not gotten to the point that we can say definitively, we haven't had enough community input to say definitively where it's whether it's five star or whether it's just flag favorite modules. There are ways for us to go through and rate our database and really help bubble up information about which modules are the right module for your purpose. Right now, we do sort modules whenever you get the search results on the module search page or on the theme search page. We sort them by, are they the most used? So if they've been calling back to updates.drupal.org, we rank them accordingly. But there's so much more information that might be valuable and that's not particularly useful for like maybe edge cases where it's not as frequently used case for a Drupal site, but it's certainly something that Drupal does really well and we don't bubble up the information that needs to be there. Good example is there are way more sites that use Drupal as a publishing system than sites that use Drupal as a commerce system but Drupal is an excellent commerce system. So being able to bubble up the modules that are actually being really well maintained, if somebody does a search that's tied to a commerce related term and being able to show that so that people can select the right module, that's a key thing that we can do with Drupal.org. There's been initiatives about this before. There was the Prairie Initiative. We've got improved project pages out of that and the project listings are a little bit better as well. There was the Projects Quality Initiative and there's some things that we have the data now from these previous initiatives that are being pulled into some of the project pages. We just aren't necessarily using it as a part of our search results. And there was also an initiative about highlighting projects that follow best practices. And I think these all, I mean, they go back years. We have examples of issues and conversations that have gone back to Drupal.org version four where people have been asking for those sorts of things but we haven't had the people to jump in and knock out these fairly significant engineering tasks. And now we have a staff to jump in and do this and so we're really excited to tackle this in the coming months. Another area where we're gonna have initiative is a upgrade of groups.drupal.org. It's still on Drupal 6. And this is one of the tools that is used by the community to find events, to join local user groups. It's a way a lot of people communicate around initiatives and ideas without really creating an issue to start that process. It gets a lot less traffic than Drupal.org in terms of total traffic. But if we upgrade it and we improve it, we can actually make it kind of a hub for some of the ongoing work in the community. And that's something that we see as being critical. We still need to decide a path for the migration. We're working right now to set up some times for meetings with maintainers and community to figure out what path for migration is gonna be best. And we also, while we're doing that migration, we're gonna take the opportunity to make it much more integrated with Drupal.org. So if you've gone to a DrupalCon and we know that because it's on your Drupal.org profile, we can pass that information onto your groups.drupal.org profile and maybe deliver information to you that is contextual because of that. If we know that you are a member of the Drupal Association, we can pass that on to your Drupal.org profile. If we know you've contributed to the following modules, we can pass that on to your groups.drupal.org profile or link back to your Drupal.org profile as appropriate so that people can see, oh, this person, they have a lot of clout and a lot of respect because they've done all of these great contributions. So maybe that lends credence to the words that they're saying over in the groups.drupal.org space. So being able to tie together that information about contribution, about credit, about commitment to the community and tying all that in between groups.drupal.org and drupal.org. So obviously this is a huge list of things. I've gone over a lot but if you want to go into a little bit more detail on all of these, you can go to drupal.org slash roadmap. This will link you to each of the initiatives. We have an issue tag that we're applying to issues that are tied to an initiative. You can go in there, begin looking at the initiatives, track on the issues that follow the issues that are of interest to you. Please join in and help contribute to this because we need the feedback. We need to know that we're going down the right path with some of these decisions. And we want to move as quickly as we can and the best way we can do that is by having people contribute in the issues right now. So I want to make a quick call out. I know that Lauren is going to talk about how there's a couple surveys coming to you. The 2014 Drupal Community Survey, which I believe is going to be available through the end of the year. If you get an opportunity, you're going to get the email if you attended this webcast. Please fill that out. That's really important information for us. It helps us rate how well we're doing with developers. It helps us make sure that we're building the right tools for you. It gives us a lot of great feedback about the state of the Drupal community. So please take a moment and fill out that survey. It's huge for us. And I also want to do one more shout out for the things that are coming up. We've got DrupalCon Latin America. That's just around the bend in February. We've got the Global Training Days that are this weekend. So if you get an opportunity and you know somebody who needs to participate in the Global Training Days, please have them do so. And we're going to try to increase the number of webcasts related to Drupal.org in the coming months. So be on the lookout for Drupal.org webcasts, but we're also doing a lot of great community webcasts and a lot of webcasts that are focused on ways that companies and organizations that are using Drupal are doing it in really exciting and new ways. So please take a look at the webcast and see what's coming up next. Great, thanks, Josh. I have one quick question before we finish up. Okay. Will you be publishing lessons learned from enhancing Drupal.org that Drupal administrators can use? For example, enhanced account creation and login? Definitely. Everything that we do in that space, we tend to have issues created on Drupal.org that are kind of our community conversation going back and forth on what we're doing and how we're doing it. So there will definitely be information there. And then we're also working right now on our own documentation as it relates to what we have on Drupal.org and we've got a sub-site that we're setting up that's gonna have our change notifications and upcoming changes and also documentation of how things are configured and we're gonna be doing that on infrastructure.drupal.org in the coming year. So we're gonna have a sub-site that's basically dedicated to explaining how we've done what we've done. Some of that information is already on Drupal.org so it's definitely something that you can dig into, but as we are doing these new changes, we're definitely gonna be doing it out in the open in the public so that others can learn from it. Great, thanks so much. I think that is all of our questions that we have today. I just wanted to thank Josh so much for taking us through a really great experience and showing us what's gonna come down the pike for Drupal.org and all of the wonderful things that our tech team are doing in the office. So much appreciated. Obviously we can't do it without them and our volunteers. So thank you. Just as a last minute reminder, we encourage you to look into our organization and individual memberships. These also help fund our scholarships, grants and servers and you can find out more information at association.drupal.org slash membership and often there are promotions within that to sometimes get a free training or extra perks. So keep an eye out for that as well. Just as a reminder, additionally, there'll be a survey at the end of this webcast, just four or five questions about the actual webcast so we can improve the experience for everyone and also this will be recorded and sent out to you via email in a couple of days. So if you miss something or you know that someone wants to also listen in, we'll have that recorded for you as well. So thank you everyone for joining us and we hope we will hear from you on another webcast. Thanks Josh. Thanks Lauren.