 I think I've given everybody about enough time to finish up their lunches and meals. It seems like people have trickled into everywhere. I'm going to go ahead and get started. I'm Ryan Aslet. I'm the infrastructure QA engineer with the Drupal Association and presenting today on what our strategic roadmap is for 2015 and what we're going to be doing with Drupal.org and all of its subsites. First of all, a little bit of background on where we're coming from in 2014. Drupal.org has historically been maintained by mostly volunteers. As a consequence of that, the community has driven most of the initiatives of how Drupal.org should work and what sort of functions and features Drupal.org has. And it's reached the point where we need to do more with Drupal.org and can't necessarily rely on solely the community to get these things accomplished. And so the Drupal Association staffed up our tech team. So there's now 11 of us working on Drupal.org and all of its subsites. So we started with two full-time staff members. That was Neil Drum and Tatiana, if you're familiar with them. And they kept things going for a long time, but it was hard for them to develop new initiatives or take on new things that would improve the way we work with Drupal and our access to things and et cetera. So here's a little growth chart that shows where we've been. So Neil and Tatiana there have been holding down the fort for the last three years. And then we have Brendan, came on staff. He's our technical coordinator internally. Gets us all our laptops and keeps everything running inside. And then we hired Rudy, Basic, and Liz. Liz helps manage the community. Basic is one of our infrastructure gurus. He kind of keeps all the servers running, keeps everything going on the back end. And then in March, we hired Josh, who is our CTO. And he's kind of set the direction and the pace for what we're going to be working on and how we're doing things, followed by Oliver Davies, who is a developer. So he's doing a lot of work on Drupal con sites and on Drupal.org itself, of the various features that we've been working on. Archie came on staff as another member of the infrastructure team. So he's helping Rudy. And then myself, I joined as well, and I'm also on the infrastructure team. So we try to keep all the servers running, keep all the backups going, make sure that everything is accessible and everything is always available. That's how we want, we don't want Drupal.org to be down. So that's one of our goals. And then recently in September, we hired Jacob and Emily, who they've been working on the con sites. They helped build Drupal.con Latin America. They also put together a new site, events.drupal.org, which will be housing Oliver con sites in the future. And then finally we hired Tim, who is a project manager, and he's helping us keep everything in line and figure out what we're doing next and keeps us on track. So since we added an engineering team, lots of things have been happening at a kind of a much more rapid pace than they have in the past. I don't know if you've noticed in your interactions with Drupal.org, if you've seen some of the things that have happened, but we wanted to change Drupal to run semantic versioning. So we wanted 8.0.0 and to break the really huge release cycle. And we had to do a lot of things on the infrastructure side as far as Git and all the database back end to support that. So we've added that. We removed some Drupal 8 beta release blockers, things that were stopping the core committers from being able to proceed with Drupal 8. We added, we took over the test spots. The test spots were managed by community, and oftentimes it would break, and there were some issues with them. So now we manage them and we're kind of on the hook for all the test spots. A new thing that's happened recently is we've imported a feature from Dredditor, which is how to give commit credit to users as your, as users add patches to things. We've now got this feature that shows who participated in the issue, whether they put comments or patches in. That's been deployed as well. Our old user profiles were still an artifact of Drupal 6, where they were kind of stored as a profile field, and we've converted those all to entities and fields. We recently deployed the blue cheese as a responsive theme. So I don't know if you've noticed and looked at Drupal.org on a web phone or a tablet, but it should be a lot easier to navigate on various devices. We've improved the new user experience, and as new people come into Drupal.org, there was a lot of kind of outdated best practices, as far as like logging in and then going to your email to get a validation and then coming back, and oftentimes we would lose people through that process of trying to accomplish what they wanted to do. So now we have a much clearer workflow between Drupal.org and all the subsites. So if you register in a conference site or if you register in groups, it'll take you back to Drupal.org and we have kind of a more unified user process. And as I mentioned before, we've launched events.drupal.org, so all of our Drupal cons now instead of being individual Drupal sites can all run as subsites of one large site, which will keep code maintenance down and give us a lot of options that way. And then finally, we launched Drupal jobs. So Drupal jobs is the place where you can find talent. If you need people, there's hundreds of people in the database that are looking for work, and we've also got hundreds of jobs listed of people who are looking to find talent. So that supports the Drupal association as well. Other things, we added a CDN. Everything used to come directly to Drupal.org servers, and now we have the Edgecast as our CDN, so that's offloaded a lot of work from our internal servers, particularly updates. I'm not sure if you guys are aware, but when you turn on updates and it tells you that your site is out of date or you need to upgrade this module or there's some security features that have come out since then, every Drupal site in the world that has that turned on is hitting Drupal.org every five minutes or every hour asking us for updates. So it's a really heavy amount of traffic that we get for that, and the CDN has helped a lot with that. There's a new REST API that allows you to access issue queues and nodes and users and find data that comes back as JSON, and there's details on Drupal.org on how to leverage that. Some people have already started to build tools like Kanban boards and project management tools to rather than scrape the data off of Drupal.org, they can actually find the data they're looking for. We implemented a change notification policy because sometimes things would change and people would not know that those changes were coming or really wanted to know when they were coming from. Internally, we've introduced scrum project management and we have a much better product planning and lifecycle, so now that we have a team, we have a good way of organizing that team, so we have organized what we're going to be working on in the future. We have new database servers. The database server that ran Drupal.org was seven years old and didn't quite have enough horsepower to run everything that we wanted to now, and our new database server is a machine, it is awesome. The page load time should be a lot, lots faster now that we have that in place, so all of our metrics have shown that we've dropped 300 milliseconds off every request, so happy about that. And we are performing a lot more support, so there's a lot less reliance on community getting around to answering questions about the infrastructure, and now we can, if someone has a problem pushing to get, we can immediately respond and be like, oh, I'm sorry, let's help you fix that. So those are just some of the wins that we've had since we introduced our engineering team. So just to give you an idea of the scale of all the things that we're responsible for, we move about 20 terabytes of data a month, like just that much volume in and out. Yeah, it's pretty huge. In fact, this slide is really dense, but it kind of gives you an idea. Every one of those blue squares is a server, is a site. QA.Drupal.org updates infrastructure, all the code browsing, all the APIs, the association site, all the Drupal con sites, the Drupal store, the job site, the security site, I mean, there's this many sites in the Drupal ecosystem on Drupal.org, and these are all within our responsibility. And it's running on a lot of machines. We've got four web nodes, a couple of file servers, four database servers, a couple of load balancers, solar search servers, and then an entire infrastructure of development stuff inside that allows us to stage and develop changes to Drupal.org. So it's a lot of machinery and a lot of moving parts. The red stuff is all things that people would perceive as core to Drupal.org, but are actually community supported and community developed. So things like Drush and Simple Test Me and Dread Editor, et cetera. Okay, so with all of the history of how long we've been around and all of the things that we want to accomplish and all the things that people have asked for for years, like, oh, why don't we have this or why don't we have that? It'd be great if Drupal.org did this. We kind of had to go through all of that and prioritize what we were going to do and say, well, something's got to come first. So how do we do that? We started with user research. We decided to go to the community and during Drupal con Amsterdam, Drupal con Austin, we interviewed 30 different users of all different spectrums from developers to site builders to end customers to kind of find out what they needed from Drupal.org and what were the features and functions and kind of to figure out who our audience was, to figure out... And so we came up with these user personas to kind of put people in categories that are using this site to give us an idea of who we're currently serving and who we need to serve better. So we've got learners. Well, we've got newcomers. People they've heard about Drupal. They've run a Google search and land on Drupal.org which is a surprisingly large number of traffic comes from a search for just the word Drupal. Learners are people who they know what Drupal is. They've started to install sites but they're not customizing too much. They're just kind of getting their feet wet. Skilled, these are people who... They've got an understanding of Drupal. They're fluent in Drupal-specific terminology. They know what a view is. They know what content types are. They're often engaged in the community but not totally, they're not necessarily going to camps yet or Drupal cons. And our experts, these are the people who really understand Drupal. They are the ones that are hanging out in IRC. They're the ones that are answering questions when people ask. They've got a deep understanding of Drupal. And they actively contribute back. They're building modules. They're submitting patches. And then finally we have masters. And these are the people that have been around the Drupal ecosystem since the beginning or have really dove themselves in really deep and they're committing to core. They understand everything that's going on. They've been to all the cons. They're the Drupal rock stars to put it in that terminology. So when we evaluated this skills pyramid what we found is that we were having, we were pretty much serving the masters pretty well. They knew their way around the way everything worked. The experts weren't having too hard of a time figuring things out. But the place where we needed to improve is getting people from newcomers to learners or learners to skilled or skilled to expert. It was really the bottom half of the pyramid that when you first started working with Drupal.org it was probably easier to collide with information that was outdated or you didn't know where to look for what you were looking for or it was just organized in such a way that made it harder for those people. So we definitely need to increase the number of successful developers that use Drupal. And so that's where we decided to put some of our focus. So with that research in hand then we wanted to turn it into a plan. So some of the goals that we wanted to accomplish with this was we wanted to make sure that we continue to fund Drupal.org and pay for all of this because the association has to get its funding from somewhere. We need to make sure that everyone has support and has all the maintenance and keep all the servers running. We want to drive everything from community initiatives where people have put in time and effort over the years and they're good at it and we need to leverage as much as we can out of that. And then finally the board and the working group priorities help us kind of set our direction. So the working groups, they were established in early 2013. They had, there's a content working group and the Drupal software tools working group and documentation working group and I'm sure some other working groups that I'm not sure of. They ran an ideation process which was like, well, what do we want to fix? What do we want to make better? How do we want to improve Drupal.org? And every year we kept coming up with the same themes and the same things kind of kept happening and we're like, well, these are the things we should work on. So we set out some objectives. What did we want it to be? We wanted it to be the home of the Drupal community, the central source of relevant info where everyone comes to collaborate and this is where all the talent is. We want Drupal.org to be the place where everybody goes for Drupal information. We're trying to keep it from being spread all over the web in different places and different spots so no one knows where to go. We want it to be centralized. We want to provide all the tools everyone needs to advance within the Drupal ecosystem. We want to provide all the documentation and all the code and all the tutorials and videos and opportunities to advance and we want to encourage people to develop themselves and their Drupal proficiency and also build their own career. So we set up key performance indicators to say, well, okay, how do we measure this? And some of this stuff is like, well, some things we know like page response time and test spot response time and up time and how engaged are our users to let us know are we making things better. We keep up with the issue queues and make sure that our issue response time is minimal if someone's having a problem with Git. We try and get back with them within 24 hours. We were improving our testing. We've got a BDD infrastructure for Drupal.org that makes sure that new deployments keep from breaking. Well, we keep bad things out of production with the tests. I'm not sure what the development and employment bullet is for and we also want to maximize our hardware. We're running out of the open source labs out of Oregon and we run some stuff on Amazon Web Services and we use the Edgecast CDN. So we want to make sure that we get in the most out of what we've got and we've got a lot. So there's a lot of opportunities for keeping our performance going there. Sure. Well, it's a combination of Edgecast and now we're also looking at Fastly for FTP because that was another piece of the infrastructure that we're looking to improve is when you download modules with Drush or when you download them off the website, it's using kind of an antiquated system that's only mirrored to three spots. So based off of all of that input from what we want to improve and what the community's asked for and the kind of things that we're targeting, we've got seven key strategic initiatives that we're going to work on in 2015. So these are the main things. So new user engagement. So with new users, we want to fix the account creation and login process. We're pretty far down this path and are almost finished with this, actually. So it should end up that we have one unified login across all Drupal subsites and it'll be really nice that we have that and we won't have to worry so much about someone's logged in here but not there and they don't have an account here and there. And that'll also facilitate things like if people want to sign up for a con and they want to buy a ticket for the Drupal con but they don't have an account yet and they create the account and then they forget about it because they have to login to their email and we're just making that user workflow and user experience a lot better. We're introducing organization and user profile improvements. So the user profiles used to be just kind of a list of a bunch of things and we've organized them and made them look a lot better. I don't know if you've seen them but now there's pictures of mentors on there that used to be links and all in all it really shows a lot more how much you participate in the Drupal community if you've seen your profiles. But the introduction of organizations is a new thing as well and this kind of falls on from Dries' keynotes and direction which is that we want to give organizations more credit. Traditionally, individuals have been the only people allowed to have accounts on Drupal.org and that was so that organizations didn't take credit for the individual's contribution but now we're going to have both and people will be able to have credit for stuff that they do but then also put that on the organizations page to say this organization sponsored this module this organization paid for me to work on this patch and that way orgs get credit as well as users and hopefully help sustain the ecosystem because not everybody can work in their spare time on this sort of thing to contribute to the community. We're working on a content strategy for Drupal.org. One of the things you may have noticed is that everything is node slash number in the URL which doesn't give the user any indication of where they're at whether they're on a forum or an issue queue whether they're reading documentation. So even just the URL structure is something we're working on and figuring out okay well do we need forum posts should we move this to some other type of content type what type of content do we actually want to have and so rather than take the well we've got the content that's evolved over the years into what it is now we want to kind of reassess that and come up with a actual here's what would work best for the community to help the newcomers, to help the experts and to help the skilled people grow their career and along with that we'll come and redesign including like a design strategy and so that we can have reusable modules of design to be able to introduce new initiatives without too much work to build new content types or new displays. We're going to work on the issue workflow with Git as I'm sure you're aware the patch based workflow is a relic of the CVS era and we're still on it even though we have Git in the background and a lot of people have asked for well how about pull requests or how about something of that nature and we're working on it we've got a plan for that and so we're going to change the way that code gets added and worked on on Drupal.org we're going to make search usable does anybody use the search on Drupal.org or do you go to Google and type site Drupal.org right? yes yes and so we're going to make it much more usable we're going to make it so that it's valuable and along with the search kind of tied to that is finding modules because when you look at the number six the improved tools to find and select projects when you look at a module there's some signals that we that you know the longer you've been around the Drupal ecosystem the more you know oh I'm going to look at how many times it's been installed or oh I'm going to look at what the maintainer is or I'm going to look at you know whatever there's a whole bunch of signals that you kind of learn over time to figure out how to evaluate modules and when we think about us hosting all of the Drupal modules in one place we're really like an app store for the Drupal ecosystem and so we need to get a better process in place for getting new modules into the ecosystem as well as being able to quickly and easily evaluate the quality and usability of those modules so that people can find what they're looking for to extend their sites and finally we're going to update Drupal groups it's still running on Drupal six and we're going to yeah pull in some of its functionality make it Drupal seven and kind of give it a little bit of a refresh so those are the seven strategic initiatives on the Drupal or Roadmap that's hopefully what you can look forward to in 2015 we're working on it pretty quick so some little bit more details on the account creation login so why do we focus on this well the workflow is hard for newcomers we need to engage our users and encourage them to contribute Spammers really love how easy it is to get started with Drupal.org we get 10,000 accounts a month that are just sleeper accounts that Spammers are automatically generating they're hard to stop because they're just account creation and the roles and permissions in Drupal.org we want to change to reflect people's position in the community so we're adding a new role progression that allows people to become confirmed and community members that allow them to trust other users we're basically making a web of trust out of the roles and permissions plus this account creation is kind of the key to security for Drupal.org which back in March we had a breach I'm sure you're aware of March 2013 a long time ago so we've been focused on sealing up all the possibilities of making sure that that doesn't happen so we've simplified the registration process we've added a lot more spam prevention systems in place to prevent account creations prevent people from marketing their SEO on Drupal which has pretty high page rank so we're a pretty big target we're tracking engagement so we're trying to figure out who's using the site how are they using the site and how much of the site do they use and using that as a metric to kind of decide we're doing these things to improve the engagement, did it work so this is one of the things we have added our new user role progression so people when they first create an account they're just authenticated but I don't know if anyone's created an account in a long time but I've seen that not a spammer role that people are asking for we have a honeypot module that was often trapping people stopping them from promoting their first question saying oh sorry and it kind of makes people feel not welcome if they're just trying to ask a question and they get shut down so we want to make sure new users are welcome so we have this confirmed option that we're going to be rolling out to the community to be able to confirm other users so there's anybody in IRC that's been around the community a long time could just automatically confirm a new user if they have a problem so kind of spreads the load out and then of course we reworded everything that was worded by volunteers at one point by some really savvy and sharp wordsmiths so these are just some of the ideas that were attached for possible user profile improvements of how like people can actually see what you've done and how you've contributed and who you work for and organization pages didn't know that animation was there so for the improved profiles these are the things we heard in user research of like why people wanted their profiles improved so when you look at someone's page you want to know who they are in the community because hey you should do X and Y and Z it's nice to be able to go to their page and say oh this guy's credible he really knows what he's talking about he's been around for 13 years working on this which is what leads into knowing whether they have expertise in the area you're asking about or they know what they're doing it also helps to know how long they've been a member plus it makes it easier to find other members of the community if like you go to someone's page and they list four other people as mentors you're like well who are these people then maybe you'll see them at a con and be like oh I've seen your page before and you kind of know a little bit more about them and finally just having a page it's kind of like a resume you know to allow people to come and look at your Drupal.org page and say yeah here's my profile here's what I'm doing with Drupal.org I can help your company I can help your clients this is what I know so you can trust their answers and code so some of the improvements that we've already got organization pages we've focused on organization pages this isn't how they look now I need to update this slide and that was another profile thing so organizations they're the key to our growth so both providers and customer organizations so we've got some media companies that build a lot of Drupal sites and we've also got major clients that have a Drupal site on staff like government agencies and other large organizations so we're looking for both Drupal shops as well as customer organizations we want to highlight their contributions we want to turn their contributions into successful case studies to demonstrate to everybody else what you can do with Drupal as they help support modules and themes we want the rest of the world to know and we want to incentivize organizations to help do that to help tend the comments because we've got this great product that's been built out of community effort after 13, 14, 15 years and it's reaching the point that it's so huge that we need all all the time that companies can give us to keep running and keep it going and keep it having momentum so we want to incentivize those companies to participate we want to incentivize companies to send people to Drupal cons and incentivize companies to do things and this is one of the ways that we're going to do it is with organization pages so our content strategy and redesign being responsive is more than just the theme we want the content that people are looking for in the places where they would look for it so we have new content types we're coming up with a better content governance model so there's a lot of content on Drupal.org that there's documentation pages that are out of date there's information that's inaccurate sometimes because we don't really have a gatekeeper of who can post what it's pretty wikipedia free form anybody can add and additionally we're going to add a design system to that so that we can leverage leverage those design pieces the get workflow so how many of you submitting patches to issue queues c1 anybody else work with the issue queues very much this is the initiative that I'm going to be help driving so it's the way that the code is written and the way that code is built on Drupal.org is like I said before it's a kind of an antiquated patch workflow and so we want to move more towards something similar to what github has with pull requests such that we can use leverage the power of get to be able to move change forward on Drupal.org so we've got our canonical project repository and every time an issue gets created we'll start an issue workspace repository so this is instead of like here's my patch there will be a whole it'll almost be like a fork for that entire issue that'll be integrated with the test bots as it is now and there'll still be the issue queue conversation that goes on so additionally contributors will have their own repos which are versions of that issue workspace and we're going to add inline editing to the workflow which will allow users to I mean often times the patch gets submitted and everything's fine but you need to change some spacing and you need to change some vocabulary it'll be a lot easier people can just change that inline rather than clone the whole repo, make another patch and submit it well sort of the I'm going to get into that a little bit it's actually a function of get that it's called issue namespaces it's called get namespaces it allows you to have a whole other set of branches and tags internally to get that is not part of the like if you just clone the base repository you won't see those but if you clone the namespace for that issue you will see those and so it allows kind of another workspace where people can work and not interfere with like wherever the core mainline is happening so it's similar to a pull request but the workspace is created on Drupal.org and then you'll clone that and so instead of forking the module locally you'll do it on Drupal.org kind of like you do with GitHub where you fork and it creates it, it'll do the same thing so one of the things that we heard and why are we doing this instead of moving over to GitHub or something similar well the core contributors didn't feel like the pull requests implemented on GitHub would work for the current workflow so core definitely has a much more collaborative community-based workflow that doesn't would not translate to GitHub but they also know that the workflow that they're used to doesn't help new users come in and there's a 14 step process to make a patch and then another 16 step process to change that patch and add an inner diff so you have to learn about 30 things to be able to even contribute which we want to want to change that, it works now, people have built Drupal on it but we want to make it better so our options were keep everything the same which no one's really happy with or we could move to GitHub or we could switch to a new internal software tool like GitLab or Fabricator or something like that and host it internally or we can modernize our current Drupal network workflow so pull requests not something new, people have been asking for it for years, this is one of those things that comes up again and again so when you look at the slides online this gives a lot of links to all the different places where people have talked about this and options and reasons why but the main thing that we kept coming back to of why not to move to GitHub is that pull requests versus issues there's a fundamental difference in the data model between pull requests and issues with the pull request you have a code delta this is what code we're going to change and then you can discuss that one change if that change isn't adequate or needs to be modified then you have to fork the pull request and then another conversation starts up in another place and if that's not quite right there's another pull request and so the conversation gets forked along with the thing that you're trying to accomplish and so on Drupal.org we don't want that, we want to keep it to where all the conversation happens in the same place and we can keep multiple code deltas associated with one issue workspace so none of those options that we were talking about is moving to get number easy like we can't just move to GitHub with other interdependencies on the inside as far as updates go and other packaging scripts and downloading new modules just moving everything to GitHub would be a lot, a lot, a lot of work plus it would require people to learn some new tools if they aren't using GitHub even though a lot of people are but then somebody might say we're on an island because we're not in GitHub but this is such a hard problem that WordPress hasn't, you know, they're still on Subversion they don't want to rock there about either so it's just migrating as a huge problem so go ahead I'm sure you've considered it but was there another way of using the GitHub API to get what you need in in other words behind the scenes and forth and forth but using the API you fixed that would that, as an alternative to making a whole system? Well, yeah, we had considered that but it again then adds another external dependency to the whole system now we have to rely on GitHub always being there and always working in order for our stuff to work and additionally the integrating with the API part it's just as much, I mean it really only saves us the we still have to have all of the interface on our side that does all the same functionality but then just makes the calls to their API as an alternative to our our function so it ended up being kind of a wash we did look at that so the way that we can do this on Drupal.org is with issue workspaces so this is a modernized version of the current workflow which maintains a collaborative data model that we currently want to maintain so it's not a new idea in fact when they were talking about the great Git migration from CVS years ago this was always part of the plan they were saying we want to have work issue repository and work on code on an issue by issue basis so we're going to update the issue queues to support a pull request like workflow as well as adding inline editing which as I said before will be a huge boom to people that need to make just small changes to things as an initial bonus we can keep the patch based workflow in place because that's what we really want to do is everybody's used to something we don't want to just throw it out and say here's your new tool and everyone has to adapt immediately and be completely disruptive we're going to change this such that you can still submit a patch and in the background it will create an issue work space with a commit on it and other people can come and clone it and pull and you can keep adding patches and it will still work so that's kind of a win as far as like process workflow continuity we don't have to disrupt everybody so this is an example of an actual issue that happened on Drupal Core a number of years ago and here's kind of how it would look like so it starts off Dominer created an issue work space and this is kind of in the future like he would create an issue work space clone it and push that change to his branch on that issue work space so he's got a work space called 1740419 and then Xjam sees his changes and says oh hey you know we can clean this up this patch is good but we just need some other you know change the word in here add some spacing there and so she would use the inline editor instead of submitting another patch like she did before and he pulls her changes says oh okay great that works I'll pull that and I'm going to add some more commands and keep changing things because this doesn't quite work the way I want it to and then this is where currently we have to do patch re-rolls so patch re-rolls would go away because you could just merge back in from head so that you can be like well this thing I'm working on it's out of date let me catch it up so he would work on that work space and then Damian comes along and says oh I want to work on this now so I'm going to pull off the latest and he makes some more commits and those numbers and parentheses are like the actual commit message numbers yes the the question was what about unit testing for the for those patches as people add commits to their repos and then push them back up to the issue workspace that'll trigger the new Drupal CI infrastructure to run test against it which is going to be a lot more robust and have a lot more options as far as I want to change which databases runs on I want to change which PHP options are set those are the kind of things we're looking to expand in the testing infrastructure so that you'll have the ability to kind of move test what you want to test and make sure it works the way you want them to so in this example Dolaner likes Damian's changes and pulled them back in his and moved forward and then Dostro came along and was like oh I have some ideas on how this will work so he pulls the patch or he clones the latest issue workspace adds another commit to it Dolaner comes back to the issue says you know I don't think I want those changes so I don't have to worry about it, I don't have to look at which patch is the latest or what I'll just keep working on my own branch in the issue queue so he added some more patches and then Jay Hodgson comes along and says oh well this needs some documentation edits so let me fix the documentation out of this patch so she can use the inline editor to make the change to the documentation and then Dolaner pulls it back in takes her suggestions pulls him back into his his local branch of the workspace and then when he's done with it he'll say okay I think this is our TDC this is time to push this up to the community and then as Bob takes it he can say okay let's merge all these let's squash all these commits together to make one nice merge commit to say here is this change that's going to affect Drupal Core and he'll merge it and push it back into head and so that's kind of how the new get workflow will work there's we've got a lot to do on that that's probably where we're aiming to have that like implemented so any questions about the get workflow I'm not seeing any hands great so we want to make another initiative is we want to make search usable so our search, yeah like you said pretty much everybody uses Drupal uses Google to search Drupal to find what they need on Drupal and so people want to find what they want to find they want to figure out whether a module is worth using they want to know what modules are available they want to be able to find documentation they want to be able to find a solution to their problems so it's not rocket surgery we can fix this pretty easily we're going to improve the way we have solar setup we're going to improve the way the display modes work so when search results come back from solar it has the relevant information you're looking for in a condensed package we're going to have better facets and this comes back to the content strategy of like when you get a module back what are the pieces of information you might be looking for without a module I mean maybe you just want to filter by D8 modules and that's you know those sorts of things should be available on search and then we also want to make organizations and users show up in search so if someone searches for views you should also respond with Merlin and Chaos profile because he built views for example or anyone who's been maintaining it and in addition with search we also want to improve how people find and select projects so like I was mentioning before this is how you can find out the quality of a project and this is a problem that's kind of universal to the web like I have a lot of products which one's the best one to choose I have a lot of restaurants to go to and I have some in the App Store which one's the best one to choose so there's a lot of design patterns out there that we can follow and emulate and some of those are you know ratings and reviews health metrics things like oh there hasn't been any commitment on this module for two years yet there's been 20 new issues that no one's responding to those sorts of metrics that let us know that this module looks like it's not going to be maintained because and we'll be surfacing that information in a much easier way as opposed to just kind of happen to know what to check for we'll be able to have project comparisons so make it easier to say well which twitter block module do I want which one is going to integrate with the API or which one is going to be just their JavaScript version I just want to be able to reference case studies on project pages so every time a module is used to do something really impressive we want to be able to say oh and this site used it so whenever there's a case study that says these are modules we use to build we want to give credit to the module maintainers that hey you help make NBC.com possible you help make Tesla possible so better tagging and classifications of projects that's again back to our content strategy and our taxonomy of how we'll find projects and modules on Drupal.org and finally Drupal groups so there's some things we heard from user research they want to find out when Drupal events are happening and connecting with other members of the community and making those local user groups and they want to find news and updates from the local groups and they want to know where's the next Drupal user meetup so groups is where a lot of the community happens we want to keep that momentum rolling we want to keep groups is kind of like our meetup.org for Drupal so we want to enhance what's there upgraded to Drupal 7 so we have a lot less maintenance burden and keep its value and expand its value for us so what's next the Drupal.org roadmap we're keeping updates there we're tagging issues in the issue queues with specific tags for what we're working on we're always welcome to volunteer assistance if people have ideas on how these things could work there's pretty much all of these have a community based input phase where we're like okay this is what we think we want to do and we put it out to the community and the community can come back and be like well did you think of this or did you think of that and it's awesome because we have you know hundreds of thousands of people who know what they're doing in our community and so it's great to be able to have that sort of feedback so we appreciate anything that you would want to contribute anyhow is there any questions about Drupal.org and our infrastructure sure you mentioned that you're using a scrum methodology what is the decision making process exactly for example the changes where the organization has a profile and they get credit for what they do the algorithm that's used in edge cases where is it the credit for the individual did it or for the organization or both who makes those decisions it doesn't necessarily come up in our scrums our scrums are really just a daily check in to say who's working on what so but the decision making process on those sort of things we have tech team meetings once a week where we'll have something like that where people are stuck on well this has an impact on how the actual functionality works and so we've got some people who are product owners and managers like Tatiana is the product owner of Drupal.org so she kind of has the final decision authority based off of her knowledge of the community and how things should work of if it comes down to who should get credit on this a user and organization I think there are just some judgment calls internally that people make on those sorts of things but at the same time we definitely put that out to the community any time that has a judgment call we're like okay here's what we think it should do does everyone agree and there's usually an opportunity for the community to get involved and say well actually I don't because if this edge case affects me so that's usually how the process works where is the space for the community input it's in the Drupal.org issue keys so we've got we maintain that as our place as we're working on stuff we put it back in because we don't want to just develop things in a vacuum because we know that the community has built what's there now and it's great and we're just going to drive it forward from there and we definitely want to build something the community doesn't want so we always want community feedback anybody else have any other questions about the future of Drupal.org I see no hands so thanks