 Okay, welcome everybody. This is Tooling for Core Initiatives. I'm Gabor Hoichi. I'm one of the initiative leads for Drupal 8. And this will hopefully be an actual core conversations where you will hopefully come up and discuss the problems that I pose. I don't have solutions for the problems. I have problems. So I will try to outline those as best as I can and then we'll see where do we get from here. So I don't really know what kind of next actions we'll be able to derive from this conversation. But the methodology that I use for preparing this talk is I've asked all the core initiative leads and lead teams in Drupal 8 to give me their top tools that worked for them and the top things that didn't work for them and things that they would love to see on Drupal.org or in any way to help their initiative succeed. And I try to collect them in the framework that makes sense for what we do. So when I was thinking about this talk I actually realized that I will talk a lot about tools but I want to put it into a framework of managing a project in general. And this looks like very much a project you would do for our client if you would follow all the steps for a standard project. They would usually have a great idea to implement and then you would hash out a plan for what you wanted to implement. So you would have a higher level plan of where you want to go, why you want to do it at all, what kind of priorities you have that you want to achieve. And then you would break that plan down to actionable items. So in agile terms you would have ethics that you break down to user stories, for example. And you would estimate those things, how long would they take, and then you would have a backlog of issues with priorities that you want to work on and dependencies between them. And then you would take some of these issues into sprints and work on them so you could get closer to resolution and you would work on your most important things. And you would test those things and pair program and whatever other nice things you want to use there. And then you would need to report of course for the client and you would need to figure out what you did and if you did what you wanted to do. So you would do progress reporting and then you would reflect on what you did and whether you did it right and what you want to improve and go back to either part of the cycle to take on new stores for the next sprint or replan or do other important things there. So at least this is my experience from several other projects outside of the Drupal community where you have control over what comes in and the team that you're working with and the output and you have a client to report to, et cetera. And that sounds very formal but when I look through all the stuff that we do in Drupal Core now, we go through all these steps, although we might not realize we are going through all these steps we actually do and we do a very poor job of doing a lot of these things. So what I think what we excel at is part of the sprints step. So we have tools to work on stuff but a lot of the times we don't really consider the framework of why we are doing it, where do we want to go, how do we tell people what we did and just reflect on if we are doing the right thing and if we want to move elsewhere, et cetera. So we have a lot of randomness in our process and there are multiple reasons for that. As Greg always says, we are this big project but we don't have any resources to allocate for our work so we can't really plan at all. So we want to do all the enterprise stuff but we don't really have all the resources for that to do. We are also very of control so we don't really like to have a project manager that tells us what to do. So I think it was really, for me, it was really interesting to see that we've set up, we've set up initiative calls every two weeks. We have an initiative phone call with the initiative leads and we brought on some project managers to help us and then we were, at least my experience, maybe I might not talk for every initiative lead but my experience is we were very resistant to actually listen to what the project managers were trying us to do. It's like, oh, I don't have time for planning this out and I don't have time for estimating this and I don't have time for figuring out my dependencies and then I think as we went, we understood that we are actually managing such a big project that we would need to do that and we were growing ourselves into actually accepting that that's what we need to do. And the other problem is we have our issue queue as the primary tool and I think the issue queue is very good to focus on what we do in the now. So what we wanna do now. But it's not very good at figuring out why we do it. What's the output that we are looking for and what is preceding it and what is following it. So putting it into context and just making it work in the whole process. So we have the issue queue as the primary tool and everything that we did in our initiatives evolved through our issue queues and trying to augment the issue queue with different tools to help our initiatives grow. And the reason we need to use the issue queue is because to get a comment in Drupal Core, it's only gonna happen if it has a core issue and the reviewers for the core issue will only review it if it has discussion that proves that it was discussed and there were multiple options explored and the right option was proven to work and it will only have discussion if you post patches on the issue. So we have the whole process mapped out from patch to commit that we'll only work if we have an issue for it. So if we do it at other places then there's no visibility of what we are doing. So we kind of are putting ourselves in the issue queue and the whole process drives us to do that. And the issue queue experience probably for us who work here every day is very cool because we have all this information of what's going on but somebody coming in and they wanna see what's going on in Drupal 8 Multilingual, it's just a whole bunch of things that they can't make out, it's like, what the hell? So this is the list of the sprint tasks for Drupal 8 Multilingual that I took yesterday and it's just a whole bunch of stuff. So it's kind of hard to tell what's actually going on here and who's doing it and why they are doing it and there are things marking stuff by importance but then we have normal tasks that we are actively working on as critical tasks so it's kind of hard to tell what's going on at all here. But we do augment the issue queue with a lot of tools. So when I've asked for initiatives, what do they do? I've got a lot of good answers. So we'll walk through some of these and we'll see which one we're successful and which one we're not. So for planning, we do a lot of real-time planning so we get together at Sprints. We have this DrupalCon, we have actually three days of sprinting before the sessions and three days of sprinting after the sessions. So we have six days in total by the side of the session days for sprinting, which is a lot and we use whiteboards and we use all kinds of discussion tools there. When we are not together, we use Google Hangouts and Skype to just figure out stuff. I think what we do are usually a poor job is making notes of what we do there and if we have meetings then set out goals of why we do the meeting at all and what we want to get out of it. And then we have some semi-real-time solutions where I've heard the views team and also the Spark team that I'm working with and the entity team used Google Docs to map out different issues and problems and just break down things into smaller pieces and then figure out priorities. And we also use Etherpad to make notes, which is very similar to Google Docs. It's a real-time text editing thing if you use Google Docs documents as well. And that's somewhat more useful because we are already making notes. What we don't do often is share those notes with people because they are very rough, so it's not very accessible to those who are not at the meeting, but at least for these we have notes and then we can refer back to them. My gripe with Etherpad is I don't, I lose Etherpad URLs very quickly. I don't have tools for saving Etherpad URLs, I should have, so I often lose those notes. We also have wide-net discussions on groups.dople.org which is more open to the community. So Google Docs and Etherpad, if you know there's a meeting and there's a link to the Google Doc, you will go there and you will be able to read and write. But if you don't know, you will not be included. We also do wide-open discussions on groups.dople.org. Of course the tool has, so it's good because there's a lot of people seeing it. It's not very good for us because it's very easy to go off topic and want to go on branch discussions and all kinds of problems and we don't have tools on groups.dople.org to break out that discussions into smaller pieces. So that's what we found there as an issue. And then we are trying to report what we planned, right? So often we write up our discussions from personal meetings and Google Docs and we post them on groups.dople.org or on Drupal Planet, or we push the list of issues into a meta issue or we post on Drees' blog announcements for major things. I think we should do a lot more of this and we also don't do a very good job of referring back to our plans when we do stuff. So we don't really put stuff into context of why we planned that, at least my impression. And then we have those plans set down and we need to break them down and that's where the issue queues come in pretty heavily. So we use meta issues to track some of these plans which connect larger pieces into the actual issues that we want to work on and we also use them for reporting. We post back updates to what's happening. The usual problem is there is not a lot of good meta information in most meta issues so it's just the list of a bunch of related issues and then you still need to figure out what it means and why anybody did that. And then we are very good at handling the issues themselves so we made up a very elaborate system of tags and different category systems for maintaining our issues and we do manual, parent, sub and related issue management. There's a Drupal sub and upgrade coming up on Drupal.org that includes more formal support for parents and sub issues and related issues. But tagging is the non-plus ultra of issue management on Drupal.org. And I thought we are not doing an estimation. Obviously we can't really estimate how long something will take because we don't know who's gonna do it and we don't know who's gonna argue about it for months. So we can't really estimate in the sense of actual project estimation. What we do instead is we are trying to guide people onto issues that are likely fitting for them. So what we do is we use tags like novice, challenging, medium and we do actual meta issues which are in itself complex. So we try to indicate the challenging level of issues and then try to educate people about what these levels mean. But we can't really estimate in the sense of this will take two weeks or two months because we have no idea whatsoever. And then we have priority tracking which also is pretty interesting because there's a global priority on issues which is not always used appropriately. And then many teams use Google Docs to manage their priority issues. For example, the Spark team used to use Google Docs with the magic Drupal.org JSON stuff where it pulled in all the data from Drupal.org for the issue and then we can add additional priority information for our personal priorities in Spark that we would of course not post on Drupal.org because that would feed people out. Many initiatives use a sprint tag. So they tag their own issues with their own tags and also the sprint tag which means they are currently focusing on those issues. So that's in the current priority of their work independent of whether they are major or minor or normal issues globally. And there's also personal priorities. So we have the stalking cryo tag and we have favorite of Dries and we have Greg who would love to have a personal tag but he's very abusing a personal tag. He told me, you said you would love to use a personal priority tag on Drupal.org. There's at least two people having personal priority tags, but you don't want to use it. So if anybody, if everybody would start to use personal priority tags then there would be a disaster, right? Priority of chicks, priority of white-shared, priority of yeah, there would be, not good. There's two people which is fine. I mean, there's no problem with that, I think. And then, yeah, so that's all the tools that we use for breakdown. And then we took from all of those issues what we want to actually work on and put them into sprints. And there's some initiatives that are structured that they use the sprint tag and others just use their last issues on Drupal.org or they use Google Docs to track what they are currently working on. There are quite a few initiatives using sandboxes for different things where they focus their work, that their current work and when they feel like it's ready for public consumption they push to the Drupal.org issue queue so they focus their current work in their sandbox. It's good because they can make a very good progress there, it's not that good because it doesn't really have visibility for the rest of the community. But they don't necessarily need to use issues which is great, they can just push into get and use all kinds of branches and have fun. And then there's at least two third party tools that help with these sprints, the core office hours tool and the rocket ship tool. Have anybody heard about core office hours? Anybody? Yeah, okay, that's good. Rocket ship. Yeah, that's insiders, that's cool. So core office hours is like this. So as I've said, we live on issues. So this is based off of issues. So you pull in an issue and then you can add a lot of other meta information on top and assign to people based on different tasks that are involved in the issue and then mentor those people on those tasks on those issues. So this acknowledges that an issue is not really one thing, it's multiple things that you need to do and then multiple people to do multiple things and then helps manage all that stuff and is used for for mentoring people on these things. And some successful initiatives use core mentoring to get in issues that are useful for people who are not necessarily very experienced, indrable and can come in and help with different things. And there's a rocket ship which the multilingual initiative uses and the entity initiative is also somewhat using is also issue-based, same thing, but it's just a visual and focused way of listing the issue information. It's not really acting on issues in any way. So this is the focus board for the multilingual initiative is lists all the issues which are tagged with the 8MIN sprint and it lists them out and to do to review to be committed and done under these. And you can see the priorities of them who it is assigned to and this is essentially the list of stuff that we are currently working on. And when it's going to be committed, we very actively pastor for our committers to actually commit them very fast because we hate when anything is on the right column that looks bad. So we built these two tools because the Drupal.org issue queue as you've seen is not very friendly for those coming in who are not really involved yet and they have a very hard time figuring out what to do. So, but these two tools approach the same problem from very different perspectives. So the core mentoring tool wants to break down the tasks into even smaller pieces and then pair people up to do them and help mentor them and go through it. And the multilingual initiative rocket ship tool is to show what's our current focus and what we currently working on and then the same tool is also used to have lists of related issues so you can have overviews of what are the important things. So we also have a tab of content property issues which are very important for us and that's also a board of issues for a specific topic. So this is also a informational, communicational tool for us to communicate with those coming in as what's going on right now and what are the important things we are currently working on. And then we are also using all kinds of discussion tools outside of issue queues to talk about these things. So we use Google Hangouts, we use regular phone calls, we use Skype, we use ARC, we use groups.drup events to announce these things and then we use Google Calendar too if we have recurring events to get people know about them. At least I've got multiple people complaining to me when I did not put stuff into shared Google counters because they never know when events are based on other things. So we use a lot of other tools to communicate outside of issue queues that are again, not necessarily pushed back to the issue queues. And then when we are done with stuff in the issue queues we usually want to report about them but that again, I don't think we do a very stellar job about them. So we have meta issues which are collections of related issues and we sometimes update them with progress. I think I've seen more often cases when we don't update them, we forget about them. We created meta issues so we know what are the issues but then we don't come back to them. We have some unified ways of letting the community know about what's going on. We have the core initiatives page which Shannon and some other people very heroically update when they have time but it's human based so there's a lot of effort going there and if those humans have other priorities in their life obviously it will not necessarily update understandably. And we do occasionally Drupal Planet posts and very occasionally Drees posts about progress on his blog as well. And then, so what I found in my initiative for reporting is that we can tell what's going on right now and we can drive people in but we don't really, we really miss a lot of other things that we can use to tell the world about what we do. So I built a whole system around integrating all the things that we have and try to move away from issue Q as our primary tool to a full on reporting and team management system essentially so that we can communicate what we are planning to do. We can communicate the breakdown of the different topic areas that we are working on so that we can communicate what spin we are working on which is both important for us and important for anybody else who's looking at what we are doing. We can hopefully report of what we are working on which we don't even do very well in the Multilingual Initiative and reflection in terms of all the meeting notes that we have and all the findings that we find in these meetings and posting about them. So what I built around rocket ship is a whole system of stuff which I think improves on the experience a lot. And this is unfortunately was not really possible to do on Drupal.org so I built a whole independent site for this which actually was built very easily so these are mostly just blocks and nodes. So what this is about is just a summary of the initiative and what we do so we have a visual summary of the main things that we are focused on and the short summary of our initiative. We have events of what's going to happen when you can find us on IRC when there's in-person meetings. I have pictures of buddies who are involved, actual flesh and blood. And we have news about what we did and what we are about to do and we have a Twitter feed for all the updates. So you can just come here and have a sense of the team working on this when you can connect with us why we are doing this, what we want to achieve, where we are going and what's happening right now. And it's very easy, I mean it was very easy to do this because the first column is a static node. The second column, the team is also a static image. The meetings is a block that I regularly updates. The latest news is an aggregator thing and the Twitter feed is full HTML block JavaScript. I have a news page which is aggregator module. It aggregates from all the blogs of all the people working on the initiative, tagged for the initiative. I have a videos page where I put up the videos of my sessions and other people's sessions about the initiative. So you can watch Francesco Placela's interview in modules and reveled or my back camp session about the initiative. We have the focus issues page which you've seen earlier is what we are currently working on. And then we have focus pages for novice issues, for issues that need screenshots, for issues that are challenging, et cetera. And we have topic pages for topical issue summaries like content property issues. And then we have meetings and sprints with the Google calendar and information of what's going on when. And we have a team page of even more pictures and names of actual, user names of actual people working on the initiative. So you can find who you can work with. And then we have a contact form to contact us if you really want to but nobody ever used that page. So it didn't prove to be really well. So I think, so in summary, what I've found is we are very focused on issues as a primary tool because that's the only way we can get something into core. So we need to work with issues right now. We can augment them with different things. So what we really needed to get people into our initiative was to have times when we can meet with people. So meetings and information about that. We have people actually working on the initiative visibility of them so you can talk to them. And then the plans of what we are actually working on so you know what you can work on. And we wanted to integrate all this into here so if somebody comes in and wants to know what's the goals, what's going on right now, who I can talk to when then they can see the whole spectrum. I think what we do a very poor job here is reporting because our latest news is both upcoming stuff and plans and all kinds of things. So we don't really do very good job of reporting what we do even. But I think this is a much more integrated experience of a tool set for an initiative that helps people on board and helps people get engaged and get involved and keep being involved in the community. There was a proposal on Drupal.org for something similar called Topic Pages and it was part of the Prairie Initiative. And they worked very hard on this. They did great designs and then they've sat ready for implementation and it's ready for implementation for I think two years now. So if anybody wants to jump on it then there's some great designs for this. So what this focus is on is to have a similar experience on Drupal.org for teams where you can see who's on this team, what are they doing and all their activity and all their topics and related topics integrated all together. So this is not really integrating events or plans or anything else unless you actually put static content in here. But it's more like a lively, like a Facebook wall for your team, essentially. So there were very great plans to do some of this on Drupal.org, unfortunately it didn't happen. And I think the reason that both the core Office RS team and myself went with an off Drupal.org solution was that we have our own goals with our own stuff and diverting instead of our own goals to Drupal.org was not really an option because we had our own goals to reach. So we have deadlines with Drupal.org that we need to reach. So we need to have a very fast solution that our site was ready in less than a week. So that's all the information I gathered from the initiative leads. And in short, my conclusion is we really do a good job of what we do in the now with our issues. We have a fantastic tagging system. We have this great tool for onboarding people with the core Office RS site. What we do a poor job of is to have a planning system that we can refer back to and that people understand what we are doing, why we are doing it. And then reporting system that's output from this is to why we did this and what we did and then cycling that back all together. And if you look at that, it's really a full on project management experience where you like need to go from A to Z and do all that. And we are, as Greg said, pretty much way beyond the point where it was feasible to do for a few people. So it's really a big team system that we need to build and maintain. So that's my overview. And I would like to open this up for discussions. I don't have solutions for the problems I've set. Be first. Yes. So, I mean, it's obvious we need better project management tools. And obviously this is new for us since we've only just recently realized we need project management at all. But do you have an opinion about the sort of buy it or build it question? Because historically our track record of doing major improvements to Drupal.org is not the best. And we've done okay doing very, very large projects and we've done okay doing very, very small projects. And it's stuff in between that we've done almost nothing of really when it comes right down to it. And so on the one hand, it's very difficult to imagine a world in which we'll ever get better at that, especially without more Drupal.org dedicated staff of which we really only have one. And that's drum on the infrastructure side. But on the other hand, there's a lot to be said about this is our home and we own it, right? And this is we build what we need. We eat our own dog food and all of that. And if we go off onto another place, what would that place be? And what happens when they sell themselves to Yahoo and Yahoo shuts them down and things like this? Yeah. And I was sort of wondering what your feelings are about that. So I think that there was probably multiple things. So yes, we don't have the project management tools. And yes, we figured that we need them. And yes, we already built this big project modules that we don't well maintain because we don't have enough people working on it, which is painful. And Drum does a great job of doing what he can but he's one person, not 10 people. So that's understandable. But I think he's doing a very great job. So I think we just got to a point where we are getting more and more companies to dedicate people to Drupal Core development. And Drupal Core is already very, so they use Drupal Core, but a lot of companies didn't realize that they are better off if they dedicate people to that. And I think Drupal.org is one step further. It's a meta level. And we are not yet there to even have the right amount of people working on Drupal Core paid to or finance to work on it. So we would need to reach a level where we have the kind of dedication where sponsors or companies realize that if they finance people to work on the tools, that's even bigger because that helps scale Drupal to a level where even more people will work for them. Yeah, it's interesting because we really do need to, I mean, we find it hard enough just funding core development. But now we need to come up with a whole organization for this meta stuff too, right? And there's so much of the meta stuff. It's not just our tools on Drupal.org, but I mean, like the so-called what? The training gap or whatever, right? The ability to bring in new core developers and I mean, you guys have done very well with core mentoring and that's good, but there's more of that that needs to be done too. I mean, one sprint three times a year isn't enough and shows what I know. And not to mention two online every week, of course. But I mean, there's a ton of this meta stuff that it seems like we're only beginning to talk about and it's already like, we should have been talking about it like five years ago. So it's like we're already so far behind that it seems like so many of these issues are already gotten so big that it's like almost unapproachable. Yeah, I think we, so as I've started to talk, I think we just realized it ourselves. So I think it would, so my experience. Sorry, I didn't mean to crush everybody's spirits there. So my experience. Although it is what I do best. So my experience from our discussions earlier is we as our initiative leads were very resistant to all the project management stuff at the start, like a year and a half ago or a year ago. So we just grew into, okay, we really need this stuff. So now we are like, oh, we're screwed. So I wasn't, I mean, I was kind of late to the game too. We didn't get on the scrim calls until last October. So September, I guess it was, but I love the project management and I find it very helpful. Sorry, that's not what I'm, that's not what I'm standing here. So what I was, the thing that concerns me is I think that we as initiative leads, as core developers, we know what we need from Drupal.org that it doesn't do. And it can be, it's time consuming to try to communicate that to other people. And it's, and we don't like you said, we don't have the time to help fix this problem the right way on Drupal.org ourselves because we already have other priorities that are more time sensitive and that are critical to Drupal's future. And I mean, even recently, they're working on the issue queue upgrade, the Drupal 7 upgrade and they had, there's a new version of Drupal.org issues that's there. And on the one hand, I was very worried about that. I'm like, oh, I really want to help review and test this. This is going to be very important. It's going to affect work that I do every day. And so there was an email thread and there's a dev site and I never got back to it and tested them and gave them feedback just because there's so much of other stuff taking up my time. And so I, you know, I don't have an answer for this but I don't know that you have an answer for it. It's like, what can we do so that we have a way for people who are busy to give the feedback about what they're busy about to people who have, or with or without funding, who are going to actually do the work to build these tools. Other than you, and I don't know how you do everything that you do. I mean, he's like, this guy is like a project manager and he built that website. And like he still has like a whole job with responsibilities in the job that are, it's amazing. So anyway, I don't know how to solve that. So yeah, so just trying to get feedback for this session was very hard. It's like, please tell me your pains. Just write down your pains please, please, please. So even just getting out the pains of people was hard. So I think like having this session is a step, right? So we just try to organize our pains and what we do and what's not working for us. And on the other hand, I think we are doing a lot of that feedback-wise. So I think we are better at planning out improvements than actually making them happen. So we have this nice plan that's nice. There's also Michael Kiara, user advocate, had a session yesterday on IssueQ's UX and he had great proposals for IssueQ improvement. And the room of this size, it's like how many seats there, like 600 or, I don't know. I don't know. And he had 10 people attending the session. It was the same time as my mom. I know. It's not personally new. I'm just saying that. No, I don't know. So that was the level of interest in the meta level of improving our workplace, the IssueQ. Yeah, so that was an interesting session. They had good insights into the IssueQ and how we improve our workplace. It's online now. And so I think, so they made plans and these are plans and they're good plans. But then we don't, so as with the core initiatives, we have great plans, but we also need to rally people to actually implement them. So it's not enough to put up great pictures. I'm also looking forward to the Vammy improvements to Drupal.org that Dries showed in the keynote, because he also showed distribution marketing improvements a year ago and that didn't happen either. So like showing shiny pictures and making up plans is not making it happen, unfortunately. I think part of that is for your casual low level user or your casual low level contributor, an IssueQ is fine. They've got an issue, they work on it, they're done. The initiative leads are working at a level that most people aren't yet, but Drupal does need to be doing more of, so we're kind of a leading edge where the meta discussion is more important than the actual implementation discussion. And we currently, our meta discussion tools are crap. Yes. So I think having a way for us to have good meta discussion tools of architecture, of design, of things like that, that is optimized for that kind of discussion, I think is probably the biggest spank of the buck individual improvement we could make, or one of. And part of that is also cultural. I know in a lot of the early postings we had back on groups.drupal.org for a couple of the initiatives, just figuring out how to present a discussion in a way that turned into a discussion and a conclusion, rather than into a bike shed. We got that wrong a lot. And that's partly tools and partly cultural and partly just how you write something in the first place. And we. It's my session. I'm presenting opposite you. Again. Again. Don't play it in for this. I didn't control the schedule. I think a lot of that can help us to just add that extra layer there for that, for tools that can optimize for that level of discussion will help. I also think on the project management side, there's a big difference between the way your project manage a project where you know what your resources are and a project where you don't. And I know early on when we started adding project managers to the initiative process, we were trying to set up kind of the sort of project management you would have when you knew what your resources were. And I know in my case, I did push back on that because I don't know what my resources are. I don't have control over that. Don't ask me for dates. I can't say when Dries is gonna commit something, much less when something's gonna get written. More recently, we've had project managers who are doing more follow up to help keep track of the various people who are working on things and keep track of them and poke them. And that's been very helpful. That's been a lot more useful. So a lot of those figuring out how does one project manage volunteers, which is a very different animal than one project managing staff. Definitely. So I think for the tools for meta discussions, I don't think, so hopefully we shouldn't be in the business of building those tools. So we use Hangouts, we use Skype, we use Imperson Space, we use a lot of things that are appropriate for the case. And there are very advanced tools that we shouldn't be building for ourselves. So I think what we should do is we should have better communication of what's happening in those areas and what were the conclusions. So that if you get into the next stage, there's something to refer back to. Because right now, my meetings are on IRC, I post an IRC log, but you still need to read the whole thing to get it. And John's meetings are on Hangouts, the mobile initiative, you need to watch the whole thing to understand what was discussed. So, and I don't think anybody does either, reading the IRC log or watching the video, unless there's really important stuff to refer back to. So we need to have a system where we have conclusions extracted and communicated, which we don't do. And that's much easier, I think, if we have the conclusions. It just needs discipline from us. Yeah. Yeah. A lot of our discussions are asynchronous. Yes. We're in the whole other layer of problem. Yes. And I don't have a solution for that problem. Yep. Agreed. So first thing, no new contributors do not find the issue queue usable at all. Yeah. No, no. Casual contributors do not find the issue queue helpful. It's very difficult for casual contributors, even not complete newbies. People, no one knows what to work on. Yeah. That's not true. An issue, once you get to an issue, an issue is self-contained, they're predictive, then there's way too much metadata to track. And individual issues are still problematic for people else. So one of the problems with working with issues themselves is there are missing a lot of context. For example, the instructions for how to complete a task that needs to be done. So if something needs to have a review, or if it needs a screenshot added, or if it needs a test added, we have instructions for those, but they are not incorporated into the issue. There was a... This was at our conversation tomorrow in which in both of my core conversations, Larry was in the audience in my head and he's not gonna be there. And also, a lot of the time, something we're not very good at is documenting on the issue, not only the procedural things that we need to do, but also the technical aspects of what's involved in the issue. People will just file issues and say, do this without providing the context architecturally to explain the change that we're trying to have someone make. So that's another problem here. Yeah. And then... Oh, this was the thing that I thought was helpful with regard to dates and project management. I found that the happy medium is to instead of giving specific date for things, make do or planning around phases of the release cycle, because that is a schedule that we have and adhere to for some value of shrinking and expanding at least. And so in views, we found that to be really useful to say these are our milestones and to organize and prioritize our work. We certainly can't commit to a specific date because who knows what's gonna happen, but we can say that this is done or it's not done by this time and so these things that can be done later we're going to do those later. So I agree that the issue queue is difficult for new contributors. I am a casual contributor, have been for four years or so and I don't particularly have a problem with the issue queue, so I tend to agree with Krell more there, but I do have difficulties following the meta discussions. Just very recently, I've tried to get up to speed on what's going on with the web services initiative and I found some good blog posts and I found some good groups.drupal.org discussions but linking all of that, knowing where to go for that is pretty difficult, but I do want to see- I think it's true for any initiative. Yeah, yeah, yeah. It's certainly true for mine. So I want to make a positive suggestion, a very simple proposal by expanding something that I think we do pretty darn well right now, which is change notices. If I want to figure out how to implement the new routing or something, I can find a change notice and get right in on that, but for something that's not done yet, that's where I get stuck. So maybe we could follow an idea of change notice driven development, where we write what we hope our change notice would be as early as possible, post that in a different place, and that becomes our roadmap for what needs to do. Yeah, that's for an issue summary. Yeah, yeah. I mean- It should be an amen to that. It's an acceptance test, but it's an acceptance test driven toward what we ultimately produce for API changes, which is a change notice. It's essentially writing down what's our target, what we want to achieve. I think that idea of change notice driven development is a great idea, and it echoes what I intended to talk about, which is defining the rules and parameters for initiatives. I know something Larry has talked a lot about is that as an initiative lead, he knows he has some level of authority over the concept of web services, but the level of authority and the ability to make a decision and have that decision stick is very squishy. There aren't rules around when is an architectural decision set in stone. So if you make that change notice ahead of time for what the goal of Whiskey as an entire initiative is, at what point can you say, all right, we have consensus and agreement around what the large goal is, and now you get into the implementation. And I think until Core gets some clear rules on what exactly can an initiative lead do and what level of authority does the initiative lead have, I think the tools will still be secondary as long as our deeper cultural mental models are squishy without a clear mental model of what initiatives are supposed to do. The tools can't help us. Yeah, we've been actually talking about that a lot in the initiative calls is what our authority initiative leads have. And whether that's a be-all and end-all, if I say something that's gonna be like that. And we've both had hard arguments in the initiatives and we've both had hard arguments with recent other core committers about what the initiative leads decided. So I don't think we've found either way that we have an authority in that realm. So I think we all had our fair shares of fights in both ways. And that's just because we are, so growing back down to we are very of control of having a boss that says what we do because we are all volunteers that wanna work for a goal and we want to feel ownership around what we do and if it's somebody else telling us what we do and we are not part of the decision, then we usually don't feel like that we have ownership about the problem and then it's not fun. Sure, so are there things we can as a community do to make sure we keep that level of collaboration so people feel like they have a level of ownership over their work and on top of that layer a clear roadmap for how we get from rough discussion and sprint rooms to commits. I think the individual issue is complete when we're talking about a bug fix patch and there's consensus around the fact that this is a clear bug and the bug needs to be fixed. Like the mental model for that is agreed upon. The mental model for how do we decide upon entity level translation versus field level translation. The mental model for how do we get from that conceptual need to an actual completed chunk of code. That mental model I don't think we have agreement on and until we get that like the tools, the tools we come up with will be just as messy as our mental model. Yeah, yeah, I don't have any solutions for that. Hey, I thought I'd just say something. If you don't know me, I'm Neil Drum. So I'm one of the two people at the association working on Drupal.org. Yes. Also, Tatiana is on staff. So it's not just one person, it's two-ish people. Can we multiply you by 10 or something? We're gonna start planning for next year, sometime this year, which is a new thing for us as far as like staff and budgets and things like that. It's pretty good. So yeah, I hope our staff expands. Of course, I can't comment on whether it will happen or not, that's a good question over a board member or executive director. And yeah, I think a lot of the criticism here is fair. We've gotten some big stuff done and some small stuff done, and I think change noses are probably the most recent example of the mid-sized project that we got launched. And yeah, stuff's been stalled a bit with the Drupal 7 upgrade, but I think second half of this year are potentially set up for getting moving on Drupal.org improvements. Since the upgrade will be done, and a lot of the tools involved like project module are becoming more standard Drupal code. Project issue module, we have less magic in it and hopefully more people want to work on it because of that. But yeah, I have a lot of answers at this point because I can't really comment. I don't really know what we'll have for staff or volunteers for the rest of this year. Yeah, so that's what I was about to say is that we should accept that big changes to Drupal.org are initiatives and they need initiative lead teams that manage the goals and that get volunteers excited and plan it out and get the ownership and then implement it and test it and deploy it because the association is not a cash cow that will hire 200 people to work on Drupal.org. So we need to have the same solutions. We just need to acknowledge that and get that into our process. Yeah, yeah, maybe Drupal.org governance will help. That's a new kind of process that Drees has been leading along with all the other Drupal governance stuff. So some of this could be a good test case for that. It's, we're having our first governance meetings like of the actual people who will be on the committees, I think on Friday. So it's gonna take a few months before it actually is a useful process or like productive process. And yeah, we're not gonna be able to solve a lot of these problems because they're not technology problems there. Yeah, project management. It's our process, yeah. Yeah, that's coming with the Drupal 7 upgrade. Drupal 7 upgrade, yeah. It's already there. And yeah, I didn't do it. A volunteer showed up and did it. I don't know their name off hand. Andre. Yeah, give forward at hug then. Yeah. And yeah, any other, I don't really have anything else I can think of to say right now. But yeah, find me at the conference. One of your, how the new issue page looks. So you are sprinting on Drupal.org still on Friday. And so if people wanna get involved in improving these tools, then. Yeah, and I'll be at the extended sprints as well. On the weekend. So if anybody wants to involve in actually implementing tool improvements, then Neil Drum will sprint on Friday, Saturday and Sunday. So we have a sprint here in the building on Friday, I believe. And Saturday and Sunday, we are sprinting in the Acre offices. You can, if you Google for extended sprints in Portland, you will find the information. So plus one's the idea of change, notice driven development. I do like that concept. And just to write to an extent, issues that have a good issue summary are a lot easier to get through. I found some of my most successful issues are the ones where I start with an issue summary that's as long as a blog post that lays out the complete logic. But those take an hour and a half to write. Yes. But they might save you two weeks. Yeah, but the catch I found there, that works if that's written initially. Updated issue summaries part way through, I find are like a quarter as useful. And I'm not sure if that's a social problem or a technical problem or both, but they do that. Comment one is the issue summary. You know, that cojoins existence and that the issue summary. You may not know how up to date it actually is, is a problem. And that makes issue summaries less useful than they could be. So that's another, I think there actually is some talk of that getting, Neil, is that getting improved in D7 as well? I think I saw something about that. Okay. So I thought I saw something in the last blog post about that. At least the issue summary will show the latest files. So you don't need to look at the latest files, the latest patch. So we'll have the summary and the latest patch for the issue. So you have. Focus up, so it's not like stand down look. Right. Yeah. We'll find what the latest batches will be there. So I guess at least for the time being, you know, issue summaries are great and useful and do help. If you do them at the beginning, when you do them halfway through, they are substantially less useful. So do them early and let's fix the, that second half so that they are still useful later. Okay. Kathy, you have a full page of notes there. I was just writing down everybody's good ideas. That's good. So I thought this idea of the change notice driven development perplexes me because somebody said that it's similar to a well-written issue summary. Yes. And often you can use the issue summary as your first draft of your change notice when you go to write it, if it's a good one. And I'm thinking to myself, why is it tempting to be like, oh, what a brilliant idea. Why would we do change notice driven things? And I thought maybe it's because we have fewer change notices than we have issues. Not every issue gets a change notice. So perhaps people are thinking that we would have change notices for the most important things, the bigger things that we are going to have change notices for. And so that might be part of the attraction is that if we were to just say, no, we don't need change notice driven development, we have the issue summaries. It doesn't solve all the problems because then we have too many issues and we can't focus. But then I thought, well, what kind of issues get change notices? And I mostly major in criticals. So we might be able to approximate, I guess not really, right? Anyway, there might be some way to approximate using change notice driven if we can filter the issues that would eventually get a change notice. So I think the idea of change notice, that's what I've heard when I get rid of this, the change notice driven development is as it forces you to write your goals down before you start the issue. So it's just a trick to trick your mind into writing down your goals before you get started because the issue doesn't force you to do that, it's just a text field that you can enter anything. And that change notice is also a text field but it's supposed to be a text that is useful after the issue is done. So you need to write down what you want to do before you do the issue is kind of my mental understanding of this idea. And we can do other, this is just a change notice driven development, it's just the actual tool used that people suggested here. But it's, I think the mental thing is. It's a trick to change your mental thinking. Yeah, think your goals before, but you could do it if you, so I mean, it's just a mental trick. Okay. And then Larry's idea to make the issue summaries more useful by knowing the last time they were updated, especially like all the comments from 55 through 100 were after the issue summary was updated. That would be really, really cool. But I wonder if with the new mock-ups I've seen them, if I think that might not be as urgent because the new methodology of interacting is driving updating issue summary with every single comment. So it would never be out of date. So I don't know how that relates to our future. You know how much longer we're gonna have to live with what we have. So it might not be, anyway, I thought knowing when the issue summary was updated is a really good point. Brinks. I keep telling myself that when I make a revision log, I'm going to remember to put a dash C, but I never remember to do that. I think we can take that concept of change driven development to even groups.druble.org. If someone is kicking off what they hope to be a discussion about a broader goal, define in that first post what you want a resolution to look like in whatever level of the specificity you can. So it might be, we'll know that this discussion is done when we have agreement on what file format we're using for CMI. Or we'll know that this issue is done when we have agreement on, yeah. Are we sure that Drupal is gonna use the other one? No, actually getting that agreement. I have no. I just started it. That was the goal. Yeah. Yeah. Sure. Sure, yeah, I can't help necessarily. I can't help human nature, but if the person kicking off the discussion sets clear expectations for what the end of the discussion could look like, I think that'll help everyone approaching the discussion move towards what the end goal is. Now, if you wanna bike chat about what the end goal is, bike shed nested inside of bike shed, I don't think there's anything we can do to stop that. So I think we are making up a lot of interesting project management and people management ideas on our own. There are probably existing already because people manage other people and projects. So I wanted to plug just very quickly a book that I recently read and I would suggest everyone to read who would wanna work on open source. It's titled The Switch, How to Make Change When Change is Hard. And it's from Chip and then Heath. And it's not about software. I think there's one example about software in the book, but it's about making change when you feel like you don't have any control. So it's like how you get kids with cancer to take the appeals or how you get a city that is on the verge of bankruptcy for their residents to actually spend their money there or how you get a bird to not go extinct at an island, stuff like that. So there's a lot of very good examples and techniques in the book about managing people and tricking their minds into things when you are for a good cause. There's just an amazing set of techniques and examples there. So I would suggest anyone to pick up the book and read it, it's a lot of fun. Building on what Kathy was just saying, I agree, change, notice, driven development doesn't work for everything. It doesn't necessarily work for a bug where there's not going to be a change notice, which is the majority of issues. But in a sense, I see it as like the feature development, it's a higher level equivalent of test driven development where you write your tests first and that forces you to think through what you're doing. And then you know what you need to write. Somebody, if you can't explain it, it's too complicated. There's another guideline and that's where our good issue summaries with code samples can be very helpful. But again, the idea of updating the issue summary with every comment kind of scares me because we have plenty of cases now where you get into a 30 comment fight with people with different visions and I'd hate that fight to be carried out in the issue summary because then I can't read the damn thing. It's just 12 people's opinions merged together into one document that I can't read. So we also need to somehow protect against that. Again, I'm not entirely sure how, but that's another concern that would come when we start using that more. Yeah. So I think we are over time, right? I think we are. So again, so Neil wanted to say something. Outno all the details of the new issue UI offhand. But if you want to test drive them, they're on our clinical staging sites. Get seven site.devdrupal.org and I can find me all, actually tell you the URL instead of. So the association block has opposed to the new issue of. Yeah, the association block has like to it. And yeah, that's our staging site. That's what Drupal.org would look like if we took the site down and did the upgrade today. And the issue pages are, we put a bunch of effort into closing out all the issues about that last couple of weeks. So they're pretty much set unless we get more feedback and we realize we need to fix something. So yeah, have a look and figure out what exactly it does and if it works. Good. So thanks everyone for coming. I hope this was somewhat useful. And especially thanks for everyone who was involved in the discussion. Thank you.