 Welcome everyone, this is a session about content strategy for Drupal.org, and I will talk about why we needed to develop content strategy in the first place. What we did, what are our main findings and recommended changes for the site, how we're implementing those changes, and how you can help us do it, maybe, if you want to. There will be just a little bit of theory about what content strategy is, like one slide, not more. And I've done this session before at Los Angeles, so for people who are there, it's mostly the same. There will be some updates on the progress on implementation in the end. So, let's start with why. Drupal.org is 13 years old by now, and its visual look and size and feature set evolved over the years. You can see some of these steps on this journey. The current design is based on branding and design work done by Mark Bolton and Lisa Reichelt in 2008, which was a great work, and it was also done over six years ago. So, in the meantime, the website kept growing and changing, and at some point, it became obvious that the changes needed. Now, Drupal.org is not really a typical website. It is really one of the largest and oldest continuously operating Drupal websites in the world. And until recently, it was also mostly maintained and built by community volunteers. A few of them are in the room. Thank you for doing that. So, after years of organic growth, the amount of content we have is really huge. Not many people realize quite how huge it is. We have 1.2 million pieces of content. We have 29,000 projects, almost 800,000 issues, and over 300,000 foreign posts. The amount of different audiences we have is also impressive. From designers and developers to project managers, marketing professionals, technical writers, trainers, decision makers, all different kinds of people come to Drupal.org. And they also range widely in their level of experience, knowledge of Drupal, knowledge of Drupal ecosystem. In addition to all of that complexity, the tools website provides are also quite diverse and complex. In one way or another, we do provide tools similar to that of Stack Exchange, JIRA, GitHub, Wikipedia, Meetup.com, Drupal Showcase, Mozilla.org, et cetera. And all of that in one single website. So, when, again, just to reiterate, this is huge and complex. So when Drupal Association staff and Drupal.org content working group members started talking about the possible redesign, given the complexity of the task, we figured out that a simple visual refresh wouldn't really help much if we change a few colors and some fonts here and there. Like, it wouldn't really make much of a difference. What we really needed to do is almost deconstruct the website and rebuild it again to make it relevant for the next stage of Drupal journey. So where do you even start doing something big like that? Some people might have different ideas. We decided to start with user research. So we've done it last summer. It was performed by Drupal Association staff, a few community volunteers, and we had help from Whitney Hess, user experience coach. I hope you saw her keynote last DrupalCon and Los Angeles was really interested. If you didn't, you can watch online. So as a result of that project, we developed a set of user personas for the site. I won't talk too much about them. They all are published. So if you follow the URL, you can read in detail about them. So at that point, we knew sort of who our users are and their needs. How do we give them the content they need? To answer that question, we partnered up with forum one and we spent a few months figuring out content strategy for the website. Here are some of the pictures from our kickoff workshop in Portland, which was a lot of fun. This is the only slide about theory. So there are many different definitions of what content strategy is. One of the most popular is this one by Christina Halverson. Content strategy plans for the creation, publication and governance of useful and usable content. That's a big definition and it encompasses many, many different things. And really, every content strategy project is different based on what are the actual problems you're trying to solve for your particular website. So some people might expect me to talk right now about like messaging framework, voice and tone, style guide, that sort of thing. And I'm not going to do that. Because Drupal.org is so huge and has such long history and such huge amount of user generated content. For our project, we're mostly focused on things like how do we produce and store high quality content? What are the actual content types and fields we need? How do we organize this content and make sure it is findable? How it is governed? That sort of thing. So that will be mostly what I will be talking about today. So first, we looked at the existing content types and how they are used on the site right now. From the user research, we had a list of what we called areas of user activity, which are essentially big groups of tasks people perform on the website. And we mapped all of the existing content types to those areas and you can see what we got. You will notice that book page content type is quite heavily used all over the place. The same goes for forum pages. Same goes for user groups. At the same time, for some areas there are no sufficient tools for content types at all. For example, if you look under project management of search and discovery, those were the problems we found. Now if we take a deeper look at some of the overused content types, for example, book pages, book pages are really used for many, many different things. They're used for general documentation such as understanding Drupal, multilingual guide, et cetera. They're used for project specific documentation, how to use views or whatever module. They're used for tutorials and step by step how to guides. They're used for things what we call community instructions which is mostly getting involved guide. How to create your account, how to use IRC, how to upload a patch, that sort of thing. They're used for marketing content and sometimes they're even used to organize and try to communicate the status of the initiative people run which is really hard to do with the book page. If you look at forums, a similar thing. They're used for obviously support. They're used a lot for that. But also they're used for official news and announcements the ones you can see on the front page, for example, they all are forum posts. For community posts, for security advisors, not many people realize security advisors which you see are actually forum posts behind the scenes. They're also used for case status events, general group discussions and even Drupal services. We have places where people look for vendors to help with their projects and that sort of thing. If you look at user groups, they're also used quite heavily for many things. There are announcement-only groups, sort of lockdown groups such as core and governance cause people had no other place to use for announcements so they had to create these groups. They used for project-based groups so some people organize work around contributed projects such as rules or monopoly, for example, in a group on groups.drupal.org. Working groups and initiatives such as mobile and multilingual initiatives for Drupal core have groups. Obviously, there are local user groups, groups for city or region or country, et cetera and various interest groups for software and non-software interests. Some are very exciting, like knitting and stuff. So what we see overall is that a single content type is often used for too many different use cases and each one of those requires different layouts, different permission structure, different fields. At the same time, we see that a single use case is often met by multiple different content types in different locations, which makes it really, really hard for users, especially newcomers and learners, to know which is the right place for the thing they're trying to do. And in addition to all of that, there are some user needs which we uncover during user research for which we don't even have any specific content types right now. So looking at all of that, we got very excited obviously and we started brainstorming all the various wonderful content types we could create and like we had huge spreadsheets and they kept growing and at some point we started to worry that it's like too much. You don't actually need hundreds of content types to try and meet different use cases for different personas. So what we did next, we looked at how the content is organized and structured to see if there is any room for improvement and we did find a few things, obviously. So first of all, content on Drupal.org right now is organized by content type, not by persona or by user task or anything. So for issues to go here, for book pages over here, case studies are in this corner and forum posts are over here. The problem with that is that users don't really think in terms of forum pages or book pages. Instead, they might think, well, I want to know what is the status of this core initiative? Well, the answer can be on groups, the Drupal.org, it can be in the meta issues somewhere, it can be on a book page, it can be even on external website, which makes it really hard for people to find things because they don't know what is the right place to look for something. The next problem is that a piece of content on Drupal.org is generally only displayed in one place on the side. So when you look at something, you don't see all the other pieces of content related to this one, it's context. This makes it really hard to naturally discover other sections and parts of the site and relevant content for what you're looking at. So generally right now, Drupal.org users land on a page either via search or by following the very common habit in our community by memorizing the URL and actually typing it into a browser to get somewhere. Which is not ideal. So the third big problem is that primary ways of structuring content on Drupal.org are right now custom coded horizontal menus or book hierarchy. And both of them have limitations. The main problem of custom coded horizontal menus is obviously that they are custom coded and they are horizontal. Because they're custom coded, if you want to change your menu item, you actually need to make a commit to git and deploy a new version of module production just to change one menu item. Because they're horizontal, it also limits the number of menu items you can have and how long they can be until they start breaking things. The book hierarchy on the other hand creates books that include so many content sometimes that it's not really usable if you, as you can see in this example. This also is problematic because sometimes books include content oriented on absolutely different audiences. For example, Gettin' a Wall Guide is a good example of collection of stuff for different people. Lastly, we have very flat permission structure. Because there is no organization structure beside the content type, right now permission system is pretty flat. Either everyone can edit and create content of specific type or a group of people can based on user role. Assigning a number of people to a number of pages to maintain them is not really possible. And moreover, to limit access to some pages we have to do not typical solutions such as we have special input filter to log some pages from being editable by any person on the site, which is not ideal. So our findings can be summarized to two actionable items really. We need to separate content from structure. We need to have content types which are used only to create content and we need to use different means to bring structure to this content. And we need to structure content around user tasks. So instead of having five different places about a thing we would have one place about a thing with five different content types available depending on what is the type of content you're trying to create or find. So separating content from structure and content around user tasks. Now I will talk a bit about our plans how we can achieve this on Drupal.org. Separating content from structure. We will do this as I said by having a set of generic content types which will have specific clear use case for them. They will be used to create content and other means will bring structure around that content. So here you can see our planned new content model for Drupal.org. The green boxes are new content types which currently do not exist at all. Yellow boxes are content types which do exist but they will be changed slightly. Perhaps field change or display mode change things like that. In gray boxes are content types which exist and we're not going to touch them. They are sort of fine. So on the left you can see basic content types. They are the generic things which will be used for content creation where a simple use case for each. If you want to create static information you use page. If you want to create dynamic content with comments and discussion you use post. If you want to announce event you use event. If you want to document software you use documentation. In the middle you can see group content types. So those content types will use to bring structure to things. So basic content types can be created inside of all those groups. In some cases group content types also can be created inside of each other which is a little bit inception and I will talk about it later. On the right you can also see a list of helper content types. They are mostly not user generated. So we kind of separated them. And also entity types we have such as user profiles, commits, et cetera. Now let's talk a little bit more about group content types because they are sort of the most interesting ones. So projects as groups. This is not really a new idea. We talked about it a few years before. By turning projects into groups we'll give maintainers much better tools to manage their projects. They will be able to create things like posts, roadmaps, maybe announcements inside of a group. They will be able to announce sprints if they need to create official project documentation connected to this project. Other people will be able to follow the project and receive notifications about new content being created. How awesome is that? Another idea is organizations as groups. We do have organization pages on Drupal that are right now. They're fairly simple. By turning them into groups we again will give companies much better tools to manage their presence on the website. So perhaps they will have better layouts. They might be able to create some additional pieces of content inside the organization such as post announcement. Multiple people will be able to edit organization which will make it easier when some people leave the company and then no one can actually right now touch the page, et cetera. One of the biggest advantages though is that they will be able to manage people who are listed as a staff member members because right now essentially any user on Drupal or can claim they work for any company which is not ideal. The next example are initiatives. This is a completely new content type we are thinking about. The main idea behind it is to give tools to community members to manage large initiatives. So they will be able to create say events, posts and pages inside of the initiative and they will be able to relate some other content types to the initiatives such as projects and issues. And the relationship will go both ways. So one initiative can span multiple projects and one project can be related to multiple initiatives. This will give leads of those initiatives ability to actually show what the work is and what the progress is. Here are 20 issues which is the scope of the initiative. Here are the five we're working on right now. Here are the five our next priority that sort of thing. Right now issue queues don't really let us do it easily. It's sort of just a list of issues. You can't drag and drop them around. So those were some of the examples of group content types. Our second recommendation was to structure content around user tasks. This means we'll create sections on the site around user activity. We took the areas of user activity I mentioned earlier and we combined them with the current group of site map and things we already have. And we got this set of potential sections. You will see the circles have different size. They're sort of relative to the size of the section. So some of them will be fairly small and simple and some of them will be really huge and complicated. Each section will have a purpose and an audience defined and each section will have primary owner and a set of roles for users who can create or edit content inside of the section. And sometimes it will mean that any user on the site can create any content in particular section which is fine if that's what we wanna do. So these sections will make up the top level of Drupal.org site map and essentially every piece of content on the site will be inside of one of these. The only content which will really live outside of everything will be things like terms of service, privacy policy, site-wide contact form and that's about it. Now we have so many sections I can't really talk about all of them otherwise it will take too much time. I will give a few examples just to show you sort of what we're imagining to see inside of a section. So for example, why Drupal? This will be a section for people who evaluate Drupal. Essentially this will be a set of high quality marketing materials. Right now we don't really have good marketing content on the website. The one we do have is in book pages and it's not really too exciting or engaging for that matter. So this section would have content about Drupal, about history, about features, technical marketing materials, high quality case studies, potentially official Drupal blog, that sort of thing. Another example is community. So community right now we do have a page which is called, which has URL community and it's sort of just static page of text. We want to create an actual section which will be a place to find and talk to Drupal community. It will include things like listing of users, listing of organizations. And we mean all organizations. So service providers, hosting providers, trainer providers, as well as end users or really any company which has some relation to Drupal and wants to create an organization page. This section will also include local and interest user groups which means we will migrate them from groups that Drupal.org into the main website. This gives us ability to connect it more tightly to the rest of the content we have and also lessen burden of maintenance a bit because we will have one less separate website to maintain in addition to other advantages. The other thing which can be included here is community showcase. So a place for people to show off Drupal websites that they build, things like that. Contribute section. This section will highlight all the ways you can contribute to the project and how to get started doing so. Initiatives, the content type I mentioned early I will leave here. So people will be able to see what are all the active initiatives right now, what's going on, how you can get involved and start helping with some of those. Mostly current content for this section lives in getting involved guides. So essentially what we wanna do is take this content and present it in much more engaging way than just a set of book pages. I think that's enough examples. I can talk more about sections if anyone interested after the talk, but now a little bit about how we actually are building this. So behind the scenes, each section will be an organic group. Now I wanna say right away they will not look or work exactly like groups on groups.ruple.org right now. That is the Drupal 6 site. They will be much better. In most cases, nothing will really show to the end user that particular section of the site is an organic group if they don't need to know about it. And building sections as groups gives us all the things we talked about, the things we need. So various types of content can be created inside of a section. We can have maintainers and editors for a section. We can have notifications on content changes and content can be added to multiple sections if needed. Obviously all of the things I talked about today is very big undertaking and it won't be done in like a week or even two weeks. So we already started. And I will give a little update on our progress on the actual implementation of all of these changes. So first of all, we obviously presented our findings and collected some feedback from the community. We did presentations for working groups. We had a session at DrupalCon Los Angeles. Everything I talked about is published in the issue queues. I will give a set of links to issues if you wanna read more. We also published blog posts on the association website, tweets, et cetera. To visualize all the recommendations at least for ourselves and make it easier to talk about these things. So we built sort of a future state site map for Drupal.org, which is like a huge Google drawing. This screenshot probably not really is readable, but it's a huge thing. And it's obviously not final yet. We are going to verify some of our ideas about locations and titles for things by doing things like cart sorting exercises, for example. So it might change. Another work we were doing is sort of translating this high level ideas about content strategy into what are the actual things we need to build. And we are doing this by writing a set of user stories, really a lot of them. This is a screenshot from one of our numerous spreadsheets. So you can see on the very left sort of a big user story which describes the whole section by Drupal. What we've done is we built all the content strategy recommendations into a set of those big user stories so that we could prioritize them with the working groups and say, here are the sections we are going to build first and this will come next. Then we break those big user stories into smaller ones based on different user personas or different types of activity happening in the section. And then we break them even smaller into sort of individual tasks people perform so that we can actually talk about the features we need to build to support all those scenarios. And this is ongoing work obviously to write it all down for all the section takes some time so we're just going slowly one by one depending on the priority of the sections. In parallel with that we were sort of preparing the plumbing for this whole thing. So we identified the minimal set of modules needed to enable this structural change on the website. Then we built integration server which is a complete copy of production infrastructure so that we could actually test it heavily before we deploy anything. We've done lots of performance testing to make sure we won't terribly slow the website and things like that and results were positive so we actually deployed initial set of modules on Drupal.org already. So we do have organic groups on Drupal.org and we do have section content type so we can start actually building new sections. And the first two sections will be focusing on why Drupal and documentation. Our communications team, well mainly our content strategist Bradley is now really focusing on why Drupal. So he's working on things like messaging framework, what are the actual messages we want to tell people in that section as well as wireframe and some of the possible pages which will live inside of it. At the same time we started working on documentation section and we started by working with the stakeholders. In this case they are documentation working group. So we wanted to really make sure whatever goals, priorities and ideas they have will match really well to what we are building. So we've done sort of an online workshop with documentation working group members for like about four hours. When we talked through each user story to get agreement on what exactly that means, what will be the steps people will take to achieve certain goals. And screenshot here again, it's a huge wall of post-its which were created in the Google drawing because all over the place we can't really be in the same room. So it's a very huge Google drawing. Yeah, screenshot can't really show all the beauty of it but I will give you URL if you wanna see. So right now the team in the association is working through actual implementation details for what are the features we need to be able to support those user stories for documentation section. And the huge part of work for the documentation section specifically will be content audit and migration. We have right now 12,000 documentation pages on Drupal.org and we have about four staff people. I think I'm imagining four maybe less who can actually work on this. So it will take us really, really long time. If you wanna help us this Friday you can come to Sprints and we will be doing audits of the current documentation on Drupal.org. It will start at 11 a.m. room 114. So if you wanna help with content strategy this is the best place to do it right now. Now while I still have a little voice left I wanna say thanks to various people who helped us during this whole thing. Obviously content working with members like George over here and Roy, Jeff, our Marcom team, Forum One, Courtney, McKellar, Christina, all the other working groups who supported us and staff members and community members who provided us feedback, which was really helpful. As I said, here are some links you can see in the slides later. Those are the actual issues about everything I talked about today essentially. I think that's it. Thank you. So if anyone has any questions there's a mic over there so feel free to. Hello, I have two questions. One is just out of curiosity, 1.2 million pages. How on earth did you start your content audit or to find the different types of content? Well, we kind of did database queries to get numbers actually. We didn't look at every single page obviously and it's really, I mean, you can imagine how long it will take us. So what we do instead, we will do it section by section. So right now we're working on documentation so we will do the audit of the documentation pages only. It's 12,000 so it's a little less. Next we'll work on something else. We'll take whatever is relevant for that new section and we'll do audit there because I mean, we will just be locked in a room doing audit for weeks if we just wanted to do it, which is not really realistic. I think the other question I've got is just out of curiosity. I've been involved with sort of personas and content strategy work and then also using personalization to actually look and check your hypotheses that people are certain types of people, novices or people that you identify as being experts and looking at certain things. Are you sort of thinking about hooking that in at some point, using things like Lyft so you can actually look at what your personas are and sort of see what's happening on Drupal.org? Yeah, that would be really interesting. I'm thinking about some ways to at least identify those people because there's no field on user profile to say, yes, I'm an expert or I'm a master and it's also hard because it changes over time but perhaps some sort of survey or something to at least be able to see, we actually have 50% of masters or something would be really helpful. We don't have anything right now on Drupal.org to do that but hopefully in future. Thank you. You're welcome. Any more questions? I thought I explained everything so good. So you were talking about the project grouping, if you will, right? And I saw that there was documentation in that subgroup. Maybe it wasn't quite following but is documentation gonna be a little bit more accessible from, say, project pages? Yes, definitely. Yes, okay, definitely. I guess because managing projects has something that has been relatively very difficult and how I can talk to you later but I just was curious like, are there also any forms for support for projects as well or is that gonna be something completely different? We haven't thought about that yet because support section, once we did that prioritization, support section was kind of lower down so we didn't really do much thinking about it. Perhaps in the future we might add Q&A content type and that can be available in the project so you can have sort of section for Q&A about this project specifically if you want to. Okay, any more questions? I guess I explained it well. Thank you very much for coming. Thank you.