 So yeah, I actually want to ask a question in the room, especially of the folks who use the issue queue quite often. One of the things that we observe is that people use the issue queue in different ways depending on what they're doing. So one of the questions I wanted to put out there, just as sort of this crazy idea, is what if we had like a YouTube channel where people literally did screen capture of themselves working through issues? That would be awesome. Essentially using a tool like TriMai UI or something like that so that we were getting a sample of a whole bunch of people using the issue queues and walking us through what they see when they use it. I like that a lot. Yeah, so I mean it wouldn't take a huge amount of time if you're on a Mac. You could just use QuickTime Pro to capture the screen capture. But in usability testing, we often do what's called a think aloud study, which is basically you go through what you're doing, what you normally do when you visit a site, but you think aloud and tell us what you're looking at, what you're thinking while you're doing it, why you're making the choices that you're making. And one of the challenges in doing usability testing, for example, in a product like Drupal, is so many of us, especially when we're dealing with the issue queue, are experts. So it's really difficult to recruit people and really get people from all over the world to just show up at a lab one day and walk us through this process. But if everybody took the next time they worked through a bunch of issues and just did a screen capture on QuickTime, I'm sure we could come up with a YouTube channel pretty quickly and say upload it to here and then publicize it and then we have a whole bunch of data on how people are actually using the issue queue in their real lives. That would be excellent. I really like that a lot. I mean I took down a note for us to work through that. So I threw up on the screen real quick. This is what the issue queues look like by default right now. I do have Dredditor installed, so I get a couple little Dredditor features that have been added in, like hide irrelevant issues. So the fact that Dredditor took the time to create a hide irrelevant issues button is kind of significant because a fair number of our users are basically saying that closed issues are irrelevant. So why do we display them in the default view as an example? Recently closed as a label that you can go to makes a lot of sense, but having that be the default view seems a little bit strange. But as everyone can see, it's basically when was it last updated is the default sort. You can sort it by all the other things, but if someone were coming to just see all the open issues for a particular issue queue, and I'm using Drupal.org infrastructure as an example, they go to a default sort. One of the things that we played around with within the team, and as I said, there's plenty of issues out there about make issue queues more agile. We took the concept of the issue queue and said, okay, we have priority, we have status, and we have assigned. So it is much more meaningful by itself than what we currently see. Backlog would be anything unassigned or anything postponed. So basically saying that I'm not working on this right now because I've taken the time to postpone it. And then of course, you'd move everything that was fixed or closed off to another look. Now we only got as far as grouping this on a single view as a thought of kind of throwing it out for us to weigh in on the work. It was interesting when we put this on staging, it kind of fell down and so we haven't gotten back around to dealing with some of the queries that are causing it to not work. But when we put it on staging, what we immediately saw was data from the way that we manage our own queues. So Drupal.org infrastructure, we have several people on staff at Drupal Association who are constantly monitoring this queue. We still, when turning this on, had 140 that would have been considered active issues. The reality is we're not working on 140 things at once. And if any projects as they are, they're kind of kidding themselves. So what are the things that someone are actually working on? This would be really valuable information for anyone coming to a site, I'm sorry, to a project to evaluate it for use. So anything else to add to that Tatiana? Well, we can also show on this. Oh yeah. So this is something done by one of our volunteers. I think it was Luis Naiman who kind of suggested a similar interface just using Kanban style. So you will see he just like dialed up issues. This is what I get for taking over the controls because my computer is completely not set up to present right now. I apologize. And this uses some of those same concept but it uses the need to review, active, needs work. But it also grouped it into little cards as opposed to the table style, the default issue queues. Another one that would be good for this. Does anyone remember the URL for the localize initiative? And I think I have it off the top of my head. Rocket ship. Hey, not bad. Just like everything else in Drupal, I have learned to memorize URLs. So they were playing with this idea of listing everything as to do, to review, to be committed. I think this view has some similarities to like say what you would see in Jira's agile view. But the basic idea of being able to kind of group things into those areas. I do like the color coding in this. Kind of a nice way to address that as well. So in short, I mean all of the conversations about issue queues seem to come back to the question of how do we actually get our work done. Issues themselves in terms of the comment structure. There's probably some improvements we could do in that space as well. But the what is the most important thing and what is being worked on right now isn't something that we really display to our community very well in our projects. And you guys are going to have to help me out here because this has to become a conversation. I would love to hear from those of you who use the issue queues a lot. Kind of what are the things that are pain points? What are the things that you would see we need to change over time? Yeah, so I work a lot with JavaScript and so JavaScript as a component. But usually it's not really the JavaScript component that is assigned because it's a node module that has a problem. So I like the ability to filter on a component and a tag at the same time or a tag at the same time. But I mean that's just a wish list. It's not very important. But it does happen. So I did use Rocket ship to try to sort my own issues as well. Do you know about the user pain rating for bugs? It's basically you have five criteria that you can select and you get a score for your bug. And if a lot of people, you know, encounters this bug, it's going to rate higher than another. And you can, well, triage your issue based on that. So it was kind of successful. But then again, it's only useful for bugs, not for features. So I guess the question is you talked about Kanban, agile, but we don't really have a proper process for developing Drupal. Maybe contrary module do, but not Drupal core. So how could we, if we implement something new, how do we know to writing basically? And one of the things we had thought about for if we're rolling this out, we wouldn't roll it out and just replace the existing issue view. Because if we rolled it out and just replaced everything, then there'd be wailing and gnashing of teeth and very upset people. But what we could do, and we kind of tried to show this a little bit on this agile view that we threw up on one of the redesign sites. If we released it with the path that included beta, and then we interlinked it with the existing issue queue and said here, try beta and give us feedback. We could essentially allow for that feedback loop that said, oh, is this working? And we could also track statistics and see our analytics and over time we would see whether or not people were using the new queues more than the old queues. And at some point there could be a transition over and instead of having the beta path be the primary path, we have a path that includes the word old. And as we know, people would stop using it because no one wants to use the thing that's path as old. And so about issues, WebChick did some statistics on issues like the time an issue is open, that kind of thing. So is there a plan to publish statistics on issues that say, for example, how long the average issue stays open? Or how many people are involved in issues, overall, those kind of stuff? Some of it is published right now, it's drupal.org slash stats, and it's just a Google spreadsheet which we populate by running queries against database, basically. But there is some stuff there already, like how often issues gets response or comment not by its author, which is important. But then again, I mean, stats like how many time an issue gets from need review to need work, or from RTBC to need work, which is probably more important. Like those kind of things would help us, well, work better, because we know that do we put too much polish on patch, or we get away with doing less perfect patch and still get meaningful review and not spend too much time on it, basically. It's kind of interesting to figure out what is the most valuable metric for getting work done on issues. Right, and then there's the problem of the UX and UI issues that Danny was talking about yesterday. That we don't really, you know, there's no way to really work on those. So what can we do for them to use the issue queue in a better way, or use something else anyway? So it's partially for project maintainers, partially for designers, steamers, all of these people who want to help, but have this perception of, I don't code, how can I help with that? And we talked about the idea of having design maintainers just as much as module maintainers. And for module maintainers, for example, on their project page to have a spot that says how you can help. And literally that's something, you know, any module maintainer can say, I need help. That's the point of open source, is that you're not the only one doing this. So if we have something on the project page that says how you can help, we need help with UI design. Here's a list of all the UI design issues. You can contact me. So it comes to a lot of discussions that I think we've been having over the last year about the state of the issue queue. Is how do we make it relevant for people who aren't the hardcore developers who are in the issue queue all the time? And have figured out the 85 million band-aids for how they find their issues? If you're talking about wish list, then we have discussed yesterday there was a buff for mentors. And one of the main pain points for people organizing Friday's prints is that we actually have the same user interface for different kinds of contributors. And their needs are very different. For example, people who actively participate, they want issues to be split up for groups of their interest, like issues that they're working on, issues that they want to follow, but not necessarily work on. For mentors, it would be nice to see issues of their mentees and things like that. And another thing that was raised yesterday on that buff is that because of the character of the issue queue, it is very different of other types of content presented on Drupal.org. Maybe it does make sense to have it as a separate tool. Maybe having the same single sign-on, of course, but still. Yeah, we actually have talked about the idea of what if we spun off issues. One of the difficulties there would be figuring out how they could still relate back to projects. Because the bulk of what Drupal.org does is it provides the projects and issues. Certainly it has the documentation, but if we're narrowing it down to like four things that Drupal.org does primarily, it's users, projects, and delivering those projects to people. It's issues and it's documentation. So the question of do we spin it off, I think we'd have to weigh that against how much more difficult will it be to tie it back to those other things if we spin it off. I wanted to elaborate on something a bit different because you were talking about making priorities more visible to people who visit like a module or something. And so about making things visible, what are the plans to improve the project page? I don't know like visibility and measurements around the state of projects. Because I mean, it's always been a pain to select a project to do something and people get really, really confused about how to do that and which one to choose and all that kind of stuff. So what are the plans around that? Well, I can tell you that it's been prioritized as one of the things that we're going to focus on for the next year. It's in the user research that we just conducted between Austin and now and the personas that we developed out of that. There were quite a few use cases that basically pointed to the fact that the biggest pain point for someone who is learning Drupal, someone who's skilled at Drupal, someone who's an expert at Drupal, it doesn't really matter, but one of the biggest pain points is finding either the right module or finding a module that they want to come back to. Finding that module that maybe they followed and they want to come back around and be able to see, oh yeah, I wanted to try that, I remember reading about it on a blog post. So the two parts of that would be how should we display those modules in the search interface? What data should we pull out? Because we've got quite a few project page improvements that happen after the Drupal 7 upgrade in terms of adding additional statistics. The question is which of those statistics are the most valuable for someone in selecting a module? If we went purely based on crowdsourcing, we could say this is the module that's most installed because we have that data. That's the order we list them in right now. We don't necessarily, the information architecture of the page doesn't necessarily highlight that is the most important thing and that's why we're sorting them in that order. It's not like it's a big number that people can see as the most important thing. It's one of the things that displays in that. So that'd be something we could look at. Any other thoughts, questions? Like what are the things you guys want to see in the issue queues? Go ahead. I'm liking this, it's like user research to a small room. I would like a page where I can order the issues to work on. So put them in a certain order. So just collect issues I want to work on but not right now. That's kind of cool. So like pull them into your dashboard and then be able to order them within your dashboard to be the order that interests you. Yeah, for example. Or another method could be a way to pull the issues to your own site so you can order them on your own site. Right now, I tried with the RSS feeds but changed the search labels above. For example, priority version. But the RSS feeds still displayed the 50 last issues instead of what I searched for. Yeah, so the rocket ship module that was shown before. That's what the multilingual is using. Yeah, so you can put your own whatever issue into your own site and do whatever you want with it. I don't know what can you do with that. Alright, so basically the rocket ship, it's going to crawl an issue page that you give him and then save every issue into your own site and then you can do whatever you want with it. No, no, no. As a matter of fact, everything that you see over here, so if I go to click on the issue, this is the Drupal 8 multilingual initiative which is one of the better examples I've seen of it being used. Basically for any of those, you click on it and it takes you straight to Drupal.org and that specific issue. So it's really just a means to view it but not anything else. Again, it takes the tag, the also of the issue and some mid-time formation that you don't get into the RSS feed. Because it's scraping that back off the site. I would love for us not to need to scrape it. I would actually like the issue queues to just work. My question is actually not regarding the issues and problems that we have. We discussed that and there is an issue about how we can achieve something from what we want from the wish list. But at some point we get stuck and we don't know how to proceed without help from the AI people. Well, you can come on Friday and we'll sit next to you and we'll explain you all the things. That's actually a good point. Part of it is asking. There is a block on certain things so we can set up just about anybody to have a development environment and they can begin developing. That doesn't necessarily mean that they will understand all the places where all the specific integrations of that Drupal site. Any time you come and start working on a new project, it's going to take you a while to get up to speed. A lot of these things, it takes a while. You may not be able to make an immediate contribution but if you're really interested in it and you want to spend some time with us, then we can probably get you to the point that you can push it further. That's actually the one that Lewis had done right here. That's exactly the approach he took. He was like, hey, I want to affect this. Got him a dev environment and we started playing with it. The issue that we ran into here is it's a start. We could roll this out as a beta just the same as we rolled the other one out as beta. We're trying to figure out how best to get the feedback. Sure, go ahead. I like all this swim lane type of layouts that you have designed. You also have the one where you saw the active tasks and the backlog. I think that's a really good step but even before that, what is my issue in the issue queue is when I come there and I'm motivated and I want to contribute to some module or to core, when I come there, I would just want to kind of magically see a short list of different issues or options what I could work on. For example, a few weeks ago I was going on a hike. I wanted to buy this hydration pack. I went on a website and they had this really graphical kind of search engine or product selector, if you will. It asked my weight, how long the hike was going to be, what the weather was going to be like. After answering a few simple questions, it just showed me a selection of products that would match my needs. When you come to the issue queue, you could have some kind of issue selector which would be more user-friendly and graphical than just these drop-down filters that we have because I think it would really improve the quality of the search and the user experience. Kind of like issue facets or something like that, being able to do a faceted drill-down of a particular queue. Though, what you're talking about too, asks some questions around what are your preference. Yeah. Do you want to work on backend or front-end or site building or documentation? How much time do you have? Do you want to work on critical or minor issues and stuff like that? This is one of those interesting ones where I think an outside view into it is always valuable because we've been using the issue queues for so long we have a bias. So being able to get that look through a set of eyes that are willing to tweak it and make it something new, I would love to see more comps of what this could look like. Obviously, we might pick apart a little bit whether or not we have that data, but we can always look at whether we can start collecting that data. For instance, you were talking about front-end versus back-end. I'm not sure that people really use issue tags accurately enough to give you that data right now. But the front-end team does. The front-end team does, yeah. That's true. We can map a topic to a set of tags that we know will bring up relevant issues. Sounds like a topic page. It's just some mapping to do. You can say that louder. Sounds like a topic page, right, Boyan? Yeah. Are there any other ideas, more things that you're just dying to see in the issue queues? Please. Like I said, this is great. Getting to hear people actually give us direct feedback. The reason why I came to this session was very curious on how Triple wants to maintain the large size of tickets. There are huge sizes of tickets in some are critical and some are for the wish lists. So I was wondering for a certain module, you have 300, 400 issues. How do you present to the user which tickets are most important? So what I've seen here, the most fun I've seen here is which tickets are fixed. And I was wondering also if you considered to implement gamification to solving of tickets. Some tickets are easy to fix. You can earn points or something like that. And when you see tickets are fixed, you can also see that certain person, user has earned a lot of points for it. I don't know. So that's my question. Have you considered gamification? Yes? I think he definitely covered the idea that commits and tracking contributions which may not actually be a commit. It might be the comment that has the patch that eventually rolls into the commit. But being able to track that and tie that back to a credit system of some sort would be really valuable. What you're saying is the person who actually marks the issue as closed fixed, that could be another metric. So if you're a maintainer on a project and you move something to closed fixed, which I believe you can only do if you're a maintainer, correct? No, you can. That's true. But you can. Makes them fixed. See that's an interesting thing because I think our permissioning system doesn't even really allow for that gamification. Because as soon as we gamify marking issues as fixed, there could be some people who get a whole lot of points really quickly by fixing things that maybe shouldn't be. So we'd have to figure out how to make that. So Neil, you have said points do mean prizes. Oh, okay. Oliver said that. Never mind. All right. So a few things that are sort of swimming around. Again, in terms of gamification, we are talking about how to expand the metrics that we use to count what is actually a contribution. I resist the idea of calling it gamification. So you get points and badges and all of this other stuff, even though there's some of that language being used, because the issue queue is not a place for gamifying, frankly. The issue queue is a place to get work done. So the question is, can I quickly find what I have to do, figure out what I need to do to finish that, and then close this out so I can move on to the next thing? Or is there, and there's a difference between the stuff that I have to do in the couple of hours that I have, and I just want to move through a list of issues. And the stuff that I want to work on when I'm at a sprint, which tends to be bigger, requires more feedback, requires, like, being able to run over to that guy at the next table, or, you know, talk to someone else and say, help me work through this issue. So we have to understand the different types of issues that people work on and find a way to point out, for example, this is something you could do in 20 minutes. This is something that is going to take more work. So that's one area that we need to think of in the content. How do we sort of separate out those larger scale issues from these smaller ones that you can just pick off? And we're trying to do that with the meta header on issues, but it's hard to say that that's effective because we can't really pull that out and say, here are all the big sort of initiative type issues we're working on. I think we were talking earlier, like, the agile workflow, you have epics and you have stories. And that's what we're trying to recreate right now. We have meta, but it doesn't really equal epic because we don't track it that way. We don't see the aggregate. Yeah. And so that's one piece. Then in terms of what you're trying to get at, I think, with gamifying is this idea of motivation and satisfaction and increasing sort of the fun factor of writing code, which is its own other thing. And one thing we can think of is when we actually, so first of all, I think the biggest thing is we need to make it much easier to decide whether an issue is resolved or not. So those issues that should take 10 minutes, they should actually take 10 minutes, not 10 minutes after an hour of reading every comment. And then going in and marking it closed in this area that's entirely separate from everything else related to the issue. So this way of quickly scanning is something we have to try to prioritize. But then a very simple sort of UI issue is make it really easy to say, yes, this is fixed. And then let it disappear or let it like go into a little hidden filter somewhere. So at the end of a two hour session where you pick off maybe 10 or 20 issues, you can look and say, huh, yeah, I got that done today. So when we think about like, you know, so I would think about gamification that way is sort of like creating that satisfaction of a job well done. Like I was productive today, I did what I needed to do to maintain this module and maintain the commitment I made to the community. And then the other thing that I wanted to talk about is actually back to your point about choosing modules for a project. One thing that happens a lot in the design industry with assets, so image assets, font collections, all of these other things is we tend to group things like assets into categories based usually on the project. Like I'm using this set of fonts for this particular project, this light box for my Getty Images account is related to this particular thing. What if we could do that with modules? What if each like developer can flag a module and say yes, this is what I use all the time. Like, but your personal, what I'm saying is like your personal collection of modules. Like you can flag a module and say like I know that I'm going to need, you know, this is back to Drupal 6. I know I'm going to need CCK and views for example. And I'm going to need path auto and fences and like this collection of things that I download for every single project. And maybe in your collections, you can download a tar of all of those modules in one day. Or a make file. Or a make file. So that's another. Well, the gain is, I mean the gain is specifically for this learner to novice. So if we think about like, I mean, if we think about like most of the people in this room, you probably just type a bunch of stuff into Drush and it just goes. But when someone's just learning Drupal and they don't know that yet, you have to go to every single project page, download every single tar file and it will take you literally two or three hours just to do a basic site. But people don't know what distributions are and not every distribution has the configuration that you need. And not only that, as people gain mastery with Drupal, they start developing their own custom distribution on the side with a checklist of modules they always download. This is behavior we've seen over and over again. I disagree with you. Because distributions don't help build mastery. Having a collection of modules that is just given to you and say here install this and everything is fine is not helping you learn Drupal. It's helping you say, I need this distribution. But as you learn Drupal and you start flagging modules and saying, yes, okay, this one I've seen is good. I'm going to download it every time and find it useful. That is actually helping you build mastery. It also provides incentives for maintainers. If you know that there's a ton of people who have flagged your module as I use this in my daily work, then that can actually be brought back to the issue queue. You need to pay attention to this module. That can be set up with reminders and that kind of thing. Yes, remind me when this is done. That might not help every maintainer, but it might help the day reads of the world. The other thing we've touched on briefly is almost like a five star rating based thing as well. That ties in with that a little bit, almost being able to flag in common modules that you like. It does get, again, that touch idea of being able to find highest ranked modules and what could be useful for your site for newbies. I think it's interesting how the conversation of issue queues immediately gets us to module search. It always seems to come back up, which goes back to the stuff we saw in user research about module search being so important to so many people. Any more thoughts on issue queues? Like I said, we're filling in because the person who was going to be here didn't make it to Amsterdam. We decided to use it as an opportunity to get feedback on what you guys would like to see, because we have the ability to implement a lot of this stuff now much more quickly than in the past. Say again? I'd like to take a look at the older notes. Anybody else? No, it's alright. I actually kind of like that it's cold in here. It feels good. I've been sitting in a hot room half the day. These Dutch, they keep everything so hot. Is that everywhere, Pohang? Oh, okay. Alright, well going once. Going twice. Hey, thanks. Everyone who made it in here, thanks so much for coming and having the conversation. I appreciate it. I'm moving. Oh, wait, he's coming. Thank you. And now we'll stick around and take notes as well. I think what I am going to do though is go ahead and... I have a question. If you'd like to hear a little bit more about Git, we actually do have a conversation that we are firing up over in the Amsterdam suite where we're going to have one of our engineers who's been spending quite a bit of research time on the conversation of Git versus GitHub and what can we do. I've actually been presenting on it several times when talking about our key initiatives. And if you're curious, please do stop by because it starts at five o'clock and you can listen in. It's a lot of information to present because, believe me, there are a couple of years' worth of research on this at this point. Do you want it on the recording or would you like to just ask it separate? Go ahead. One idea for improvement for maintainers can be echo templates. So they can choose an answer from a list. If they need to... If they put an issue to fix, they can say no. Thank you for all your input. I hope this is fixed now. If not, feel free to reopen. canned responses on issues, yeah. They probably do it with a browser or JavaScript plugin, right? Yeah. It's not really important to me but it can be an idea. All right, cool. Thank you. I appreciate that. Okay, again, thanks everybody for coming in. Appreciate it.