 Okay, so are we actually recording now, Jason? Is this it? Okay, so we're on. All right, well thank you so much for coming. It's marvelous to see you here. So this is the session on UX case love and hate in the issue queue garden. Actually, the first thing I wanna do is change the title. So, because having done the work of thinking about this stuff and going through what is it we're trying to say exactly, the garden didn't seem quite big enough so we kind of expanded and came up with this new title, living and working in issue queue city. And it just lends itself to more metaphors which I want to fully exploit and have fun with as we go through it. So, first thing is introduction to me and Thomas. Okay, well, Thomas was in Sweden. He couldn't make it, it's too far away. So, I'm gonna introduce him anyway. He sends his love. Sorry I can't be there in person, but I'm there in spirit, he certainly is. He's also here in mind because I've got his thoughts and some of his words in video recording here in the PowerPoint. So we've done our best to get him here in a virtual way. So, Thomas is a site builder, passionate about open source, especially Drupal. And he's also an experienced actor. He's got a lot of skill, a lot of talent when it comes to the issues and so on. We have some very good conversations together. This is one of the kinds of projects we do. So, his words that he wants to share with you are, it's the whole user experience that matters not isolated features and details, which makes sense. It's really, we don't wanna get lost in little things. We wanna think about what is the entire experience about. Now, this isn't a session about UX entirely. We used to be in the UX track when we first proposed this, but in thinking about it more and thinking about what could be done with this, we decided it would be better in this track because we actually wanna talk about the community UX. So, it's kind of accusing the two things together. So, that's what we're saying, it's the community. So, to rephrase what Thomas just said, it's the community UX that matters. My Michael Pira, also known as user advocate on Twitter and user space advocate on Drupal. I'm a UX strategist and a developer. I've been working with usability, user interface stuff and developing for over 20 years. I used to do things in the graphics areas to design and build graphics applications. I've done UX design for calls into management systems, for real-time network monitoring systems, lots of different things. And I've been sort of taking this slow arc around to web around to Drupal and sort of trying to bring all those kinds of things into this kind of context, into this field. So, that's what I'm trying to bring into the Drupal context. So, my phrase for the day is I learn quickly, eventually. And what I mean by that is that I like to postpone that sense of believing that I know something, postpone it for as long as possible because that extra space allows me to ask more questions, collect more information, get more facts about things and not jump to conclusions and most of all avoid assumptions because that kills problem solving. So, if this, to use an urban transport metaphor in the issue queue of the city, if that streetcar was the issue queue, I would be the guy on the bike. I'm not really in the issue queue, I don't really do much there. So, you might ask why the heck am I speaking about it today? And it's because I think it's still valuable to have an outside in perspective, especially looking at it in terms of user experience because everybody starts on the outside. So, I cherish my issue queue virginity as it were. And when I run into things that I see in the issue queue that I don't understand, that to me is valid information so I want to use that. But in the meantime, of course, we've got Thomas Therese on the inside so the fact that we can collaborate means that we get the best of both worlds, I think. So, outside in perspective it's valuable, I think. Now, these streetcars, they tend to run in tracks to me are really a great metaphor for assumptions because they guide you, they sort of take you someplace and it's hard to get out of them. So, when you're riding a bicycle beside a streetcar, you're very careful, you don't get caught inside those tracks and go flying. Same way when I'm doing analysis of a situation, I don't want to get caught in someone's assumptions and end up going down a path that isn't going to lead to a solution. I have to stay outside to get to a solution so I need to avoid those assumptions. So, what I do to avoid assumptions is just simply ask lots of questions and I reserve the right to ask stupid questions because those are the ones that really dig up assumptions and sometimes I drive Thomas Matt with my stupid questions. And if you follow the tracks, you end up where they go and not necessarily to a place that you want to be. So, staying on the outside allows me to think outside the tracks and think of where we can go in terms of solutions. So, that's just my technique that I'm sharing with you, okay? Now, this is me trying to get US strategy into the issue of Q and I haven't found a way yet. The moment of insight hasn't happened yet. I was speaking to Gabor about this, remember at lunchtime, is there a place for this kind of conversation? Gabor hasn't seen it either. So, I think that's the problem. I think we need something like that in the community and I'll speak more about that later. So, there's Thomas on the inside digging your way and he's been around inside the issue of Q for a while, you know, making comments, digging around and planting seeds of conversations, blossoming ideas and I've been listening to him a lot lately talking about these things, talking about his experiences doing that. So, I'm kind of again on the outside, guy with a clipboard observing Thomas, writing things down and most of that, because he speaks so articulate about these things, I don't have to do a lot of work. I can just simply record it and present it here for you if that's what I'm gonna do. But I also have my own ideas about the issue Q and about the Drupal answer project as well, which I'll also chip in as a UX strategist. So, why review the issue Q? That's the first fundamental question, it's worth asking and I'm gonna let Thomas answer that first. The issue Q is what rhymes with the community forward and the whole group of people forward. It's where the magic happens. I like that word magic for some reason. I think it's magic. I think what we do in the community is magic and it's astounding. So, another way to, I would put it, is that it is where things happen, it is about where the brain of Drupal is. So, I see it as the IQ, the issue Q is the IQ. So, I wanna boost the Drupal IQ. That's why we're having this presentation here and this is starting this discussion. So, what we wanna do is basically hold up a mirror to the community and say, we wanna draw your attention to these things. That's what we're doing in this presentation. However, it's a moving target. And just 12 days ago, this was announced by the Drupal Association and it is a post about massive changes to the issue page in the issue Q. So, first we thought that was gonna be a problem but, oh my God, we've done all this research and we've done all these ideas and now it's all blown away. I almost canceled my plane ticket. But, we looked at it, Thomas looked at it, you know, quite a bit and said, no, what we're saying here is still gonna stand. So, we'll ride with that. Just going into the past a little bit, two years ago, plus, there was an initiative about the redesigning the issue Q, trying to make it better, led by Lisa Michael from the UK. You probably all remember. And I wanted to acknowledge that because there was some really good ideas brought up there and this core conversation that she had in Chicago, this is one of the slides from there and she's highlighting the values of the community. That second point we respect for, to me, is a particularly useful or meaningful dimension of these values and I want to bring that up again throughout here. The question is, yes, of course, we wanna respect each other, but the question I wanna pose is, are we actually respecting ourselves enough? And I'll explain what I mean by that later. So, Prairie Initiative dug up lots of good ideas about how to make things better in the issue Q. That's great. I won't go into all of them. Summarize like that. The last one is the one that strikes me as most interesting where they were talking about, we should behave online in the same way that we do here at DrupalCon in this kind of natural fashion. That, to me, suggests an image like this. If there was a garden, it might look like this, where people are interacting naturally in real-time, clear speech, and it's sunny. To me, that's a very nice image. Wouldn't it be nice if the issue Q felt like that? In fact, this is what we're dealing with. This is what it really is. Is it like the matrix, right? It's like when you see the code instead of seeing the illusion. So the real question is, when you come to this place, what is your experience? What's it like for you? And I think that probably will fall into two extremes. We made the bits in a little bit. Two extremes are if you're really experienced in the issue Q and you really know your way around it, I think it probably looks like this. So it's difficult for the outsider like me, but some people are probably in there having a lot of fun and being very capable of doing difficult things. And for someone like me who's inexperienced, I would say it looks more like this. That's my experience. How many people here spend a lot of time in the issue Q? How many have tried and not stuck around long? So we've got two kinds of experiences there. Okay, for any user in the issue Q, there is that question. I was talking about respect. What does that mean really, if we respect ourselves? The question is, to what degree is our time being used well? So Thomas has a thing to say about that and he relates it to the actual cost in dollars. But how much time are people wasting in that? I would say with the amount of work being done in the issue Q, we're not talking small number of dollars here. We're not talking probably thousands, tens of thousands of hours every year. Sorry, I didn't mean to interrupt on this like that. I was trying to make it louder. I forgot that it stops when you do that. Okay, so he's talking about the fact that it probably is costing money. If people are having bad experience, it means people are not being as productive as they could be. It means they're basically wasting time and therefore it's costing money. Make that observation. So not everything is bad news. Thomas also has a list of favorite improvements that have taken place over the past few years. And let's just quickly go through that list. At the top of the list, there's the follow button. So before the follow button, and I have a vague memory of seeing this, before the follow button, if you wanted to keep in touch with a particular issue that was being discussed, the only way you could do it was to actually enter a comment. It didn't mean you necessarily had something to say, but you had to enter a comment. That was the ticket for admission. So what evolved as a practice was people would enter a comment that simply said subscribe, subscribing. And then what would happen is that we'd kick out an email to everybody, say, someone's so subscribing, right? And then that happens. So how many emails you got every day of all those issues with the only content was subscribed? I'm sure that some people, like Cheeks and Gaboor and others, they probably got something like 100, 200 emails a day on issues only containing the words subscribe. So is it true, Gaboor? Did that happen? Yeah, okay. So it's astounding. But anyway, Lisa raised this somewhat tongue-in-cheek saying, we really should do something about this. And I think that discussion is very, we should have did lead to the birth of the follow button where if you want to stay in touch and be on the mailing list, all you have to do is press it. You didn't have to spam anybody. So great improvement. Edit summary. For me, it's hard to understand and to imagine a time when that edit button didn't exist because it seems so natural. Why wouldn't it exist? Why didn't it exist? So if you wanted to change the description of your summary, you had to enter a comment. It seems very complicated. So welcome improvement, I'm sure, for many people, the semi-wizzy week. So again, if you wanted things to be more presentable in your comment or in the summary itself, you had to basically write the markup by hand, which would be a pain if you had bullet points, for example. There's something about bullet points when you mark those up, it just feels really good pain. But anyway, pressing a button seems a lot so much easier. Image embed, I remember seeing this and I couldn't understand. I was really baffled by this, reading through these conversations and then someone describing something off of it, don't know whatever, and there's a link. And then you go to that, and you go polar sticking to another page. It's like, that's the funny way to do it. Why would you do it that way? I didn't realize it wasn't because no one actually had fixed the problem. It wasn't by design, it just wasn't there yet. So it is there now. And you can simply drop the picture in the context of the conversation, which seems absolutely obvious, doesn't it? And the test spot, interesting machinery, I'm living on Drupal.org that it installs, and I guess the patch tests it against certain tests and then reports on it. Really handy, a little R2D2 thing, excellent. So those are the improved ones. Now, I guess I'm interested in statistics. The Drupal Association provided us with some numbers and we've just done a little examination of comments per month, rising steadily for almost 10 years. That's obviously due to a lot of factors, growth, number of projects. But what's interesting about that is that you see it tends to level off at the end there and it's quite a distinctive change in the pattern. So you have to ask what happened. Well, the follow-up problem happened, which suggests that so much of that rise in the number of comments per month was actually just something noise. This one I like, this diagram, is it shows the user ID and the number of comments they've made by users. So user number one, whatever that is, is on the left. User one million will come up on the right and number of comments is on the YX. It's astounding. I mean, when I saw those, I just couldn't believe it because it's tens of thousands. So anybody wanna guess who the top three are? Come on, guess. What? And it over 35,000 and there's trees. Hats off to everybody that shows up on this graph because it just, to me, it's such a vivid illustration of the effort that people put into making this community and making Drupal what it is. I don't actually know who Vian is. But who's Vian? But above 30,000, so interesting. I don't know. Thomas, where's Thomas and me? Well, Thomas is coming in at just over 1,000. I'm sweeping the floor. The 1,000 is an interesting number because if you do a cut-off there, who has commented more than 1,000 times, the percentage is less than half a percent. That's amazing. So you can see how it's skewed completely. It wouldn't be interesting, though, if somehow more people were able to participate. I mean, oh, it's just comments. I mean, comments aren't everything, but I think they were pretty good metrics in terms of the ability to participate in the community. Projects for months, going up steadily, steadily and suddenly, it beeps. Guess what happened? Guesses. Good one. Very good. But it goes to this new plateau. So everybody puts the project up all of a sudden and then it's settled in at a higher level. Very interesting. Again, map that against the comments per month. Even with that huge spike or increase in the number of projects, the comments still tapered off at the top because presumably the follow-up button really did have a big effect. It just shows you how one improvement like that can change quite a lot. So I want to talk about chaos theory because when I see numbers like this of things like throughput, things that are going through a system like this, I think it's relevant to look at this mechanism, which is a clear glass tube with liquid running through it. This is kind of a scientific experiment to demonstrate the concept. And the idea is that black line running through the middle is ink. And it's an inkjet that's flowing through as the liquid is going through at a slow rate. It's just a straightforward black line. But as you increase the volume and the rate of flow, it changes. So it gets a bit wobbly. And then it gets bumpy. And then it becomes turbulent. It's like chaos. And that's simply from one dimension of change, just simply throughput, simply traffic. It causes a complete change in the pattern of behavior, the organization of the content of that pipe. And that, frankly, is something we should be careful of because we're facing something like that potentially because we have a similar system of pipe is the issue here. There's traffic flowing through it at larger amounts. And if it gets sort of clogged to a certain point, not clogged, but sort of gets baffled to a certain degree, it will become completely failed and completely break down. That's something we don't want to happen. Engineers use turbulence. They use this principle to design systems, like heating systems, for dissipating energy. So they actually introduce turbulence just so that energy transfer can take place and into the environment. But we're a volunteer organization. The last thing we want is our energy to be dissipated into the environment. So that's why we need to be careful about that. So we're a volunteer, but it is work. And so I think it's useful to think about the issue here as actually a workplace, a virtual workplace. It's not like people get money for it. It's not like they travel to a particular place. But they sort of do. It is that they do travel to this virtual place. So we're used to these downtown urban scenarios where you go to your office tower and that's where you do your stuff. But we kind of do the same thing except we go to different project pages. So if you want to have a discussion, have a meeting around something which is of a concern to you, you have to find the meeting place. So you would go to a particular project page which is like going to a particular building and then you would end up in a situation like this. You go on the lobby and end up in a situation like this. And then you look into the conversation. And then you study it and you think, is this the conversation I want to be in? Are they stating things that mean something to me? And maybe they do and maybe you participate and maybe you just consume some information and move on. But these are meeting places. These issues are all meeting places and there is some kind of cost that it takes for every user, every participant to get to those meeting places. So the question is how much cost? How much effort does it take to get to the right meeting place to have the right conversation with the right people at the right time? And there is an effort involved. So this is one that I actually visited last week. It was a good conversation. It was talking about exactly what I wanted to know about but it didn't have the results I wanted, unfortunately. It was ended up being postponed. Or if it isn't the meeting you want and they start one of your own. And that's the marvelous thing about virtual space. You can just carve off another room and then start there. But as you do that, as you carve off more rooms, of course I'm going to switch metaphors now. The population, the traffic grows and then it becomes more difficult because you're sort of introducing more noise value just by setting up a new conversation. That's potentially a big problem. So as a UX strategist, when I see traffic jams, I look for causes. What is it? The obstacles on the road. There's two that we want to talk about here. There is ambiguity in guesswork. Those are the things that Thomas is describing that we'll go into. And then there's a lack of UX strategy. Like I said, there's no place to put that stuff. We'll go into that afterwards. Let's talk about guesswork. Epic game for you. The problem with guesswork is it's not very efficient communication. I'm going to prove it to you. I've got three characters in mind. I want you to picture them in your own mind and see how close you get to what I'm thinking about. So I've got Mary in a house coat, Lucy in a baby carriage, and a man holding knives. Anybody from Drupal Camp 2008 that saw this already don't see anything. Okay, so, Mary in a house coat. Picture Mary in your head. What you look like, okay? This is what I'm thinking. Did anybody guess Mary is a painting on a wall? All right, another chance. Lucy in a baby carriage. Picture Lucy in your mind's eye. Did anybody guess Lucy's a dog? Were you there in 2008? Yeah, you see more, I don't know, maybe the Toronto thing, but you see more and more dogs in baby carriages these days. I don't know why. Okay, good, we got one. Okay, man holding knives. Picture that. Did anybody picture a small figurine in a kitchen shop with knives stuck to a knife holder? I would never have that in my kitchen. Okay, so thinking about guesswork, we know how inefficient it is. It introduces noise, introduces energy dissipation. Where does it happen in the issue queue? Let's look at Thomas' list. Where are we losing energy? Let's look at the workflows. I changed, it's not workflows, it's workarounds. Let's look at the workarounds. Duplicate issues. Of course, if you can't find the conversation that you're looking for, it's very easy to start a new one. So therefore, it's very easy to start duplicate issues. Thank you, Kapoor, you're marvelous. And how's that done? Well, it's done simply by labeling something or setting the status to close and marking it as a duplicate. So in this case, we have a lot of conversation taking place. It goes quite a ways down. All of a sudden, Gretel's comes along and he marks it as a duplicate and he puts the idea of the other node where the original conversation is, where the conversation should be happening. So of course, it's gonna stop here. It should go to the other place. If we go to the other place, there isn't a backwards reference to that duplicate. So it's just one way. Where are we losing energy? Both status only, there's no linkage, no actual linkage between the two issues. Manual and hour cups, so that's gonna take time. It's not obvious what's going on, especially to new people and it's certainly open to interpretation. What does it mean to say something? And here's an interesting fact. Right now, today, 15% of core issues are marked as duplicates and that doesn't include the ones that are still open. So that's one in seven. So that's how high the noise rate is. The next problem that needs to be solved is there's no way of showing dependencies between issues. So the workaround is to use the postponed status and to mark something as postponed and sort of write, almost anecdotally, the little story. Again, Gregor's, I don't know what Gregor's came up with. Postponed this because it's dependent on that. So what's the problem? Again, there's no structure to this, no structural logic. It means the user has to manually keep track of this. So supposing you have this situation, you're working on a project or an issue with XYZ and it's dependent on one, two, three. The only way you get another one, two, three is ready for you is you keep checking. So how much time does that take? And then do the numbers. How many people have to do that? So, energy loss. I can't show parent-child relationship, so the use of follow-up has been invented to indicate that something is kind of a child issue coming this morning from another parent issue. Again, it's done manually in the comment or in the issue summary. So it's just sort of storytelling, really. It's nothing structural. And this one's interesting. An inadequate tool set for people using it for regular users. And we've got a little video here to show you some of the use of Dreditor. It's the workaround. I've never hit a Dreditor, so you tell me it's only about a speed scale. But here's a little demo, in case you don't know. Normally, what you can do, you can use this patch by doing like that and it'll get the patch like that. But what finds today is a safety thing. If you wanna make a comment about something, you can just highlight a line like that. If you can say, then you click on paste. You see here, it automatically pastes in that part. That part function, I selected with my comment. So I know it's a bit of a longer video there, but it's such interesting, cool technology. It's such a great idea. But what's the problem? The problem is that not everybody knows about it. It requires installation. It's like a separate thing. So it's not what it's about, it's a great idea. It's just not in the issue queue proper. So it takes a little bit extra energy to get there. And then the last one is to kind of show the status of several issues involved with a milestone. So in other words, you can't really group them in an organized way. So the work around it is meta-issue. One time I did comment on something. Someone pointed out that it was a meta-issue. And you know, I've been speaking to Google for a long time, and it's socially unordinary. I still don't really fully understand it, but I guess not, nothing about it. So if it's that's the grouping mechanism, then maybe that's not where the conversation should happen. Oh, sure, I don't know. So up at the top, there's the labeling. It's just tacking onto the title at the beginning. And then there's the group of things that it's referring to. But the problem is that after a while, it disappears because it doesn't get updated very much. So it kind of falls off the bottom. No one's ever heard it again. There's no structural connections to define those things. So if you're down in one of those sub-issues, you wouldn't know about the peers. You wouldn't know about the parent. So what is, and I like this. Really, I can't really talk about this tomorrow. I hope I don't scoop you too much. I mean, it's 10 people pointing out what you're thinking for, okay. We're in a war of blobs versus chunks. I love this quote. You're all on team chunk. We cannot let the blobs win. So what she's referring to is lack of structure. So everything she's gonna talk about tomorrow, about content and how to really do content for the future, I think applies here as well. We've got too many blobs. So a couple more external workarounds. And it kind of shows you the, almost desperation that people must be in just to get through this task of, say, building D8, where an entirely separate site has been created. It's just to get some sense of management of the issues that matter to them. And this is no core. So this whole core mentoring website that was put together, which has some extra sort of loving care around these particular topics and so on, in such a way that it's easier for that direct sort of team of people to just simply get a grasp on the issues that are important and just work with them. And ultimately they will lead to the issue of the queue proper. But then the other one, Gabor's for the Multilingual Initiative. It's a nice website. It's got lots of great things. It's got news. It's got training videos. And it's got these focus issues and so on. And again, it ultimately leads you back to the issue queue. So the only problem with this is that, you know, they, you know, well, it does take some extra effort to find there is a bit of fragmentation because it's now in multiple places. But all those improvements that they made on those separate sites are isolated there. They're not actually in the issue queue. So that's a bit of a loss. So how can we conserve the energy, Thomas? That for you to make any sense and use of the issue queue, you have a long list of things you need to learn exactly how they work. Because you stumble on them all the time if you spend time in the issue queues. There's nothing that's logic about it. And there are many variants of those work events as there are people trying to use them and not buy them. Because people do things differently when they have a choice. So what he's talking about is, you know, the blobbiness, the vagueness, the ambiguity, the guesswork that's involved when we don't have the structure. Right, so the solution would be, but if you have a feature that says, okay, this is the duplicate of this issue and you select duplicate and pops up a little box where you type in the issue number of that issue. There's only one way of doing it and everyone's gonna be happy. Because everyone's gonna know exactly how that works and if the handle is automatic in the back end, job done. So the idea is actually, it's sort of reintroducing the concept of guidance and if you will, rails to make the path go where you want it to go, right? So it's kind of the opposite to what I was saying, but now that we know where we want to go and what I mean, how do we know that? Because the work grounds exist. We know the kind of usage patterns that the community wants because these work grounds exist. It's called cow paths. When people go off the paved path because they want to go to take the shortcut, it ends up becoming a trail like that. That's what we're looking at with work grounds. And then ultimately the rallying client for UX design is pave the cow paths because that's where people really do go. So that's the recommendation that that kind of activity, the intelligence that the community has already established there through the invention of these work grounds needs to be raised, needs to be formalized. I'm gonna take a break. Okay, nobody wants their time wasted. I just have to tell them about that. You don't want to waste your time. So that's the respecting again. So to what extent are we respecting ourselves, respecting each other when we work with these kind of work around each other's solutions instead of really having a solution that we need. So again, all this raises that. How much time do we waste? And he points it to the fact that UX strategy, the bit that I can't find anywhere on Drupal.org, is simply not taken seriously enough. So let's look at that. What is UX strategy? So the real nature of the problem around the issue here is why I'm concerned is one of mass transit, is a mass transit problem. How do we get people on mass to the meetings they're trying to get to efficiently and quickly? So that's what the UX strategy should try to accomplish. So if this is Drupal.org, then this is us. We're the intelligence. And we all have reasons for being there individually, collectively. And really, if we have reasons for being there, we have some intent. So the question is, what is that intent? What is the business intent? So what I mean by business is not about strictly money making, it's not about increasing the rate of profits, it's about what is it of value that you want to bring to the world? What is your stock and trade? And you may be a non-profit organization. You still have a business to help your clientele. Or you may be in the education field, and you still have a business to disseminate information, right? And so there is a business intent to Drupal.org to the larger community. There's a business intent to everybody involved as well. So on the home page, that's one particular intent. On a project page, there'll be another one as well. And on the issue queue page. And on the issue page itself that was just radically changed by the Drupal organization. So all of these, this is like four sample pages underneath Drupal.org. And they all have different intents. For example, provide information, provide function, provide feedback, provide labor. They're quite different things, yet it's all on one side. So the business intent of the whole thing is actually a cluster of things that all work together. So that's why I say a page, a web page is a unit of business intent. And we don't have to think about this. There's more discussion now happening around that. What is a web page like Krell's core conversation? Is it a CMS? Or is it a publishing tool? Sorry, a web publishing tool. And I think it's useful to not think about it in terms of web publishing. Don't think about it in terms of making something that looks like things that you just reprinted. It's really what was your intent behind having it. And that's where we can incorporate the newer emphasis on structured content. Because that content, the rules around that content can be structured around the intent itself. What should be there? The only way you can answer that is, well, what's the purpose of that page? You can still have the concept of page. It's just not anything like printed page anymore. But it's exactly what all that stuff is about. In the first place, which I'm trying to accomplish this, get at this location. That all still holds together. If you flip it around, look at it from the user point of view, use it to bring different mindsets to these locations. So the language changes slightly. So someone coming to the top to Google.org is maybe looking through information. Someone coming to a module page, looking for functionality. Someone that's coming to the issue queue page has feedback to offer. And someone coming to an issue page proper has the ability to help out and pitch in, submit a page, et cetera. So these are task objectives. So when you put this together, the whole point behind UX strategy is that you marry the business intent with user's task objectives. That's all UX strategy is. That's all we need to do. So when I approach these problems of user-based design and UX design, I always ask these questions, oh, sorry, I forgot this slide. People come at it through different entrances and you have to have those entrances built to suit their needs, built to suit their objectives in their community. So in that case, we've got, it's actually a children's toy store in Madrid. It's just sort of so cute. So you've got an adult entrance and you've got this shorter child entrance. So I always ask these questions. Who is the user? What are the task objectives? And how much do those task objectives or how do those task objectives match our business intent? Where can we get those matches to take place? That's the entire exercise right here of UX problem solving. So let's look at some more numbers. And again, it's about the time that we're potentially wasting. It's time that we are wasting, time that we can potentially save. And how much time people do have to spend on doing it. It's a limited time. I mean, it's larger volunteers, it's got to be limited, it's not going to go forever. There's almost a million people with accounts of people at work right now. If we save a million people, or this many people, 10 minutes across a year, that's pretty modest. Look at how it adds up. It adds up to 18 years, 24 hours a day, seven days a week, that's time that could be used for productive activity as opposed to just trying to get to the meeting space, the meeting place where they didn't have that conversation, right? So that's a pretty compelling number, I suppose, I can say. Now, here's where the follow button was announced. But look at what it says, six years. It took six years after the idea was thought of for the follow button to actually take form. How much time was lost in that six years if you look at those numbers? And why? That, to me, is not us respecting ourselves. That is us completely disrespecting our time. Let's say it's 25,000 hours a year. And take that time to 100 dollars an hour. That's two and a half million dollars right there. So where are we gonna find the money? Well, if you do the math, there's gonna be money out there. Somehow, how do you actually turn that concept that there's potentially millions of dollars of people's time being thrown away into something which can actually take shape and actually get these workarounds formalized, get those compounds paved, and get people more productive. So what I'm thinking is we know that the figures are there, the numbers are there. We know that the risk is real, but this could actually continue to increase and then fundamentally it could break down because it's just unusable on the issue queue. So we have a choice. Do we wanna reduce the time and effort that it takes to have meaningful meetings in the issue queue? Yes or no? Do we wanna spend the limited time that we have on more productive things as opposed to commuting, so to speak, to these meeting places? Do we wanna achieve the objective that we're identified by the query initiative over two years ago? The last comment I saw on the initiative, by the way, was March 2011, but it basically stopped. Do we wanna do that? Or maybe it's just an idea. Maybe we can send ourselves a message. So if you agree that maybe if the Drupal Association fix the issue page itself, if it's their job, and I'm just maybe guessing this is how we can solve it, but if they can do that, maybe they can also help out and actually allocate some resources to getting these compounds paved. So I'm gonna say tweet it out, spread it around, try and get the idea spread. Let's see if we can start a dialogue with the Drupal Association. Maybe they don't have the money right now, but maybe if enough people say, please, this is a solvable problem, can we do it? Can we somehow use our own organization, our decision-making body, to focus the manager on this and stay at our time. And if we can do that, and we are already as an astounding organization, as an astounding community, then maybe we can do even more astounding things. Why do I not? Because I don't understand what you're saying. Another thing, and I didn't put this in here, but another idea, which may or may not have some value, is if you look at, say, the tagging that takes place, if you're looking, you know, tags are ways of solving and finding things, right? But if you look at how the tagging takes place, you look at UX, and you know, it's got a whole bunch of suggestions, you know, with UX in it, and it's absolutely impossible to make a decision there, either, right? It's another block. Which tag would I use? So, again, it's energy loss. My thinking is that if we didn't just have it completely free like that, if we actually put something intentional, there's intention to get in at some top level, so it's an easy decision, and then you let the community intelligence kick in and say, oh, well, that's clearly UX, and that's all you have to decide. Just one tag for that level, or that, you know, core, or whatever, right? And then I think if you build the right taxonomy and the right structure, things will simply filter down to the right place, just like coins and one of those coins floating machines, right? It's all the dimes and the pennies and the nickel are going to show up in the right columns. But that's a different approach. It's not free tagging. It's a very structured tagging, but just on a gut and see if that's effective. The worst thing you can have if you go tagging systems is basically tag pollution. Tag, attack, taxonomy is like a well. If it's dirty, if it's polluted, it's a stage, and we're just going to have normal conversations with people, I really do appreciate you coming. It's been fun to work on this.