 Hi, I'm Ryan Aslet, MixaLogic. I'm with the Drupal Association here to talk about issue workspaces. So this is to talk about how we collaborate in the Drupal-org issue queues. Specifically, a way to make them a better place for us to collaborate and how we manage our changes and code in those workspaces or in the issue queues. So first I'm going to talk about some of the existing problems that we have with the way our issue queues work and what makes them less efficient than they could be. I'll move on to some of the ideal features that we'd like to see in our issue queues. And then we'll look at the possible ways how we can get there, some of the pros and cons of different approaches that have been talked about and discussed. And then lastly, I'll share a possible solution based on research, based on mining all of the conversations that have been happening throughout the years for a way forward. How many of you have worked in the issue queues? Good, I'm talking to the right people. So I probably don't have to go through how they work now, but specifically we're in a patch-based workflow, which patch-based workflows work really well for large open-source projects. Apache uses them to get, I'm sorry, the Linux kernel uses it. Lots of major organizations use this because it's a great way for people to condense their change in code and communicate it with each other. However, there are new tools. Oh, yes. There was a quote off of the one said, this will be a quote about something by someone. Very famous person. Okay, so the limitations of the current issue queues. First of all, I don't know if my animations are gonna work, so bear with me. Oh, there we go. So it's a complex workflow with many steps. Making a patch, the node that tells people how to do that is 12 steps. If you need to re-roll a patch, that's another 18 steps. And usually when people re-roll patches, they would like to see an inner diff. That's an additional eight steps. So our workflow requires about, what is that, 38 steps of information to just be able to interact with our issue queues. So additionally, trivial changes require the same complex workflow. Every time someone submits a patch and there's like, oh, well, everything's right, except just this comment at the top should be this different way. How many people have ever seen that comment and said, hey, you just need to change that rather than make the change themselves? Like if you, yeah, like hey, fix that. Because the assumption is the other person has their system all set up and it's easier for them to make the tweak and upload the patch than it is for you to get all set up. So trivial issues such as code standards, cleanup, documentation, fixing. Those all get neglected for higher priority issues due to perceived conflicts with other aspects of especially like in core development where we don't want patches to interfere with each other. That can make it difficult for learners. So our new people that we'd like to bring into Drupal Core, they have to learn these 30 steps, they have to learn how to work with this patch-based workflow. A lot of new developers are very used to things like GitHub and Bitbucket and all these other workflows that are not patch-based because they've developed after Git has come along and other tools that have made it a lot easier. So the other issue that we have is there's no intra-issue visibility. When you have a patch, the only people who know that, oh, well, we don't want to fix that here because so-and-so is working on this other issue. There's no easy way for us to know that if this gets committed, it'll break these five patches. There's kind of an internal knowledge that is tribal but there isn't necessarily a real simple way to just by looking at the issue have an automated way to say, oh, if you commit this patch, then these other issues will be affected or this issue is currently touching these other issues. So, and that's because patching isn't as smart as something that could get merged. If you use Git, you can merge between different issues to find out whether or not there's conflicts. That also causes problems with reluctance to make major changes. Like for example, there's an issue that's been floating around issue 7269, nice four-digit issue of let's rename all the files to end in .php and Drupal 5, Drupal 6, Drupal 7, Drupal 8, now postponed to Drupal 9. We can't ever make this change because it would break every patch in the queue because all the patches are expecting the file names to be .module, .install. But because it's a patch, it's really hard for everything else to work. Really hard to avoid that problem. And so we have things like disruptive patch windows that we have to wait for for when major changes come through. But with merges, you would be able to merge file renames into an existing body of work and be able to say, oh, great. Now everything's working on .php files and we don't have those sorts of conflicts. So that's another problem with our current queue. And again, the not having this ability means we have to rely on tribal knowledge and very few contributors that can know the large scope of what things are gonna be affected or impacted. Patch review, reviewing these patches can be challenging. So because patches aren't granular, sometimes by the end of an issue when it's time to fix something, you have a patch that hits 300 files and fixes a lots of different things. And it's not necessarily possible to parse apart what was just tangential to the patch or it can be a really large, large patch by the time all the work is finished on it. And you can't see the granular commits or the granular changes that led up to what that actually became. We also don't have a built in diff viewer to group.org. It's been implemented externally with Dreadnr, which most of us use, but the functionality is mostly there, but we do have to rely on an external tool. And for new developers, of course, it's like, oh, what, there's a secret tool that we have to use that makes it better? I didn't know that. Finally, another issue that I'm, this is one of my pet peeves, is that stale patches happen in the issue queues. There's 14,000 issues in the Drupal core project. There was like 8,000 of them that were marked need to review. All of those patches, somebody really cared about the code that they were submitting to that issue. They were like, this needs to be fixed. Here's my idea to fix it. And maybe no one had time to get into that issue and find out, oh, yes, we should apply this, we should fix this. Because the average wait time is about 23 days between the time that someone posts a patch and the time that someone answers that patch. So because of that, by the time someone gets around to looking at it, that patch may be stale. Commits may have happened on head and that patch may no longer apply. It may conflict with something that got committed. And the person who is most invested in that code, the change doesn't get notified when their patch becomes stale, when it breaks. And so six months later, someone might be like, hey, I re-rolled that patch. And then be like, oh yeah, that patch that I worked on six months ago, oh cool, someone's touching that now. So we have this problem where patches get stale, nobody knows about it. People have to do kind of grunt busy work to re-roll these patches to make them usable again. And so if you go and look at the issue queue and you look at needs review, doesn't mean here's a bunch of changes that need review. It means here's a bunch of changes that could potentially need review, probably needs a re-roll, probably doesn't work anymore. It doesn't give us a nice clean, this is what we're looking at. So what would better tools look like? And this is kind of a high level, current state's not ideal, but what would it something better have? So since we're using Git, something that uses a Git-based workflow, things that have pull requests or something that would allow us to have less disruption by not having, by using a Git-based workflow, we could use patches, instead of patches, submit and review and accept work, have pull requests, have forks, have all these things that other places like GitHub or even hosted services have, we'd be able to do merges instead of patch re-rolling. It lets us avoid the concept that patches are really just an export out of our Git database that we use to communicate and then we import them back in. We no longer, we would avoid that. It would allow us to detect code conflicts and provide immediate notification. So let people know when their patch gets out of date, let people know that there's patch conflicts with other patches and that can give us a whole slew of benefits like you would find out that somebody else is working on the same issue but just in another, or the same problem but in another issue that you didn't know it existed. We'd be able to commit changes without the worry of disruption. We'd be able to move forward on things that were kind of stuck on that kind of stop velocity and then we'd also be able to see how different issues affect each other. So a tool would also integrate a code review functionality because honestly that's really part of the process. We, someone has a change that they want. Everybody else looks at it and says, I get what you're going for, it should be better this way, that could be better that way. There needs to be that ability to discuss code on a line by line level, similar to what we do now. And finally we wanna be able to have something like an inline editor so that when there is that small fix that nobody wants to roll another patch for you can be like, oh I just fixed that for you using just this editor built into the issue. So these are things that we would like to see that I've seen these as problems or maybe others that we haven't covered here but these are some big ones that I think would allow us to kind of have a higher velocity. And so the constraints that we have that we're operating under is we don't wanna disrupt everything. We don't wanna just jerk the rug out from everything but hey, here's the whole new everything. Everyone stop what you're doing and learn the new thing. We wanna preserve the way that our community collaborates on issues because right now anytime someone wants to fix something they open an issue and the conversation all happens and everybody discusses this issue and they figure it out in one place and the community works on a patch together. We don't have what I think of as a star model where one person has an idea and the maintainer and them work it out. It's everybody works on the issue together. And I think that's part of what makes the Drupal sausage like really valuable. We also wanna keep Drupal.org the home of the community. So some of the options and ideas we tossed around may or may not help with that. You know, we start to push things in different places then Drupal.org, the Drupal community can start to fragment as some people will never need to go to Drupal.org because all they do is pull code from somewhere. So it might, you know, that is a constraint. And then we've only got so many resources to make changes in the first place. And so we have to look at how difficult it will be to implement changes and how much of an impact some of these will be. Because there's definitely a lot of some discussions about why don't you just do this? And oftentimes there are a lot larger problems than just. Okay, so what are the options? Knowing we have constraints, this isn't a new conversation. We've, this has been talked about a lot in the issue queues. And so a lot of this is like summarizing and digesting all that information and coming out with an idea. So we have four potential options. Do nothing. Status closed, fine. We're happy with the way things are. We viterated some, you know, previously already that, like that's probably not an option. We could move to an externally hosted service. This is move everything to Bitbucket. Move everything to GitHub. Move everything to GitLab's new hosted service. Let somebody else handle our code, issues, repositories. We could switch to a self-hosted service. Things like Fabricator or Jarrett or GitLab on our own infrastructure. These are also options that we could use to tackle this problem. Or we can modernize our own issue queues. Fix them in such a way that we're used to working with them with and try and reduce impact. So let's look at each one of these. So doing nothing. Let's keep our tools the way they are. Now, I've already talked about some problems and I've saw some heads nodding that like, yeah, those seem like problems. I think I saw some agreement anyways. If it's not broke, don't fix it. Any change will break someone's workflow. We don't think this is an option, but we keep hearing from throughout research, throughout all the issue queues that keep coming up, throughout all of the people that are experimenting with other options, or even people that have moved their stuff somewhere else. Or people that are like, well, I'm using Hubdrop to mirror all my projects on GitHub and you don't have to worry about how people don't just get any more. So people are definitely looking for other options because they're not happy with what they have. So option two, move to a hosted service. Things like Bitbuckets or GitHub or GitLab. So these hosted services are awesome. Lots of people use them. We've looked at them and they may or may not be appropriate for what we're doing. So one of these hosted services I want to talk about specific is GitHub. I want to talk about their data model and their workflow and how we don't think it necessarily applies to the way Drupal builds its products or its code. So you have code changes on GitHub that are pull requests. Both pull requests and issues have comments on them. So you can start an issue, start commenting and tie a pull request to it, but that pull request can also have comments on it. And then if that pull request isn't quite right, someone says, oh, well, I like your approach, but I don't know if that's the way we want to do it. Then someone has to fork that pull request and create another stream of comments. And then if a new contributor comes in and is like, hey, I want to help on this issue, where do they go? Where do they look for the canonical discussion of what's happening with this code change? Convention says, well, we just keep everything on the issue and never comment on pull requests. But if people can comment places, they will. And so it's kind of fragmented. And so what ends up happening is forking a pull request forks the conversation. We end up with conversation in multiple places and it will just kind of break down the way that we communicate. So Drupals, on Drupal.org currently, our code changes our patches. They live in comments on issues. And if someone else wants to work on the same code, they create another patch. All the conversation happens in one place. And so that, to me, is the fundamental difference between what we've got already and what GitHub could offer us. And I think these are the same issues with Bitbucket and with the other hosted data models. So some of the hosted services, wins and fails, moving would be really disruptive. We'd have to tell everybody, hey, everything is moving over. All 27,000 of our repositories no longer live on Drupal.org. They're on GitHub. Here's your new account. And of course, there's account issues of how would we manage logins and who has access to things. And there's just a lot of things that we need to consider there. It would break the collaborative model of our coding, which again, I say, is basis of our community. Drupal.org wouldn't be the place where everyone goes for code. They would be going to GitHub. And it wouldn't necessarily be, here's the Drupal section of GitHub where you can walk around and see other modules and find other pieces of code so that you can look for examples of an implementation somewhere else in the code base. It would be spread all over GitHub. It would be a little harder to find your way around. And finally, like I said before, this sounds easy in theory. But the sheer amount of work of moving everything over to something like that requires a lot of API integration, requires a lot of thought, a lot of design, a lot of how would this really work if we were to try to do this. And it's not simple. So what other options do we have? Well, let's move it to a self-hosted service. Let's turn on Fabricator, which is what Facebook built for their code review and code tools and its open source. Or we could use Jarrett, which is another code review tool that I haven't had much experience with. There's several of these that we could use that could mirror our Git repositories. Yeah, that's Diffy, the Kung Fu review cuckoo from Jarrett. We could use that last thing stuff, but it runs on Java. So it takes a while. So what would happen if we did that? So we've got some software, self-hosted art software, some of the wins and fails that we've seen in a lot of the discussions that came up, where the data models might not be that different. So we could potentially keep the collaborative model that we have, but we would have to evaluate these other code bases to the nth degree. The code bases might be in, they might be open source, but they might be Java, and we don't have Java resources on staff to help manage or maintain it. Security updates to this software would be something that we would have to handle that's kind of outside of what we're used to dealing with as far as, well, we know Drupal, and we have people looking at Drupal, and this is an external piece of software that, what if there's a hole in it? And then we're just at the mercy of whoever's looking at that code for us. An advantage, though, self-hosted means we own the data. It would still be disruptive. Like, you'd still be like, here's the new thing, and everyone stop what you're doing, and move on to this new tool. So we'd definitely have resource requirements like we'd all have to learn this new piece of software. We'd all have to figure out how to administer it, and implement it, and configure it. And so those are some of the self-hosted wins and fails. There's a lot more discussion on this on various different spots on GroupStudDrupal.org, and I've got some links in the slides once I put these online. OK, so finally the last option is modernizing our issue queue. Taking what we've already got built and moving it forward just enough that it actually satisfies some of the needs and some of the pain points that we have right now. So we want to level it up. Maybe. I don't know if that's a feature request at this point. OK, so this has been talked about before. When we were all talking about moving to Git, we were saying, oh, the phase three of the Git migration will offer per-issue branches of core. And there was a lot of ideas and a lot of things that were happening around that. What we'd have to do is add new features to the existing issue queues. And the Git daemon itself, we'd have to add things to that to support what we'd want to change. This would provide minimal disruption. The issue queues would still be somewhat the same. There would be new features added. But we would try and preserve exactly what we have now so people could gradually move over. And this would preserve our collaboration issues. So we would still be working on an issue. People would still be doing things the way they aren't used to. It would keep people at home in the community. And this is achievable given the resources that we have. Now we have a tech team of 11 people. There are people who can dedicate enough time to this that, similar to the way people put time into building the Git infrastructure in the first place, we have some resources that are able to do this. So what is the proposed solution here? Issue workspaces. So issue workspaces, it's a new way of working on issues that use some of the underutilized features of Git. The allow contributors working on an issue to use the power of Git to manage change. Very similar to per issue repositories, but it's more like a per issue fork of the main repository. The feature that allows issue workspaces to work underneath the hood is a thing called Git namespaces. Basically, Git namespaces is a logical separation on the server that would allow us to have separate branches, heads, and tags in its own namespace, yet all share the same repository on the server. So you'd have one really big repository, which each issue would have its own, like a fork, of the repository. And it would have access. But then merging back and forth in between these workspaces would be really easy and be able to use Git to do it. So let me go into a little bit more detail. So there would be one namespace per issue. So once you open an issue, if you decide you want to namespace for it, because you're going to do code changes, you'd create a namespace. This namespace would have a per user, per issue protected branch in that namespace that only that user can push to. So you're kind of like the maintainer of your own branch on that issue. So you'd have a branch that you could commit to that nobody else would be able to push stuff on top of. You wouldn't have to worry about having to catch your code back up. There would be a branch pointer so that there would be something called latest. Just like you could do Git pull head, you could do Git pull latest. And whoever was working on that issue last, you would be able to use that as a convenience method. So you wouldn't have to go and find out Git hashes each time you say Git merge latest from whoever else was working on this issue. And then any number of shared branches that anybody could have access to can be in this namespace. So you'd create an issue. Four people are working on it. There'd be four branches, one for each of those users. They would each have access to those branches. And then there'd be a shared one where if they want to merge back and forth, and they don't want to just work in their own spaces, that would allow for those sorts of collaborative efforts. So it kind of gives us a lot of options, a lot of choices on how we could work with this. So that's issue workspaces in a nutshell. So it gives us our Git-based workflow. The contributor would clone the workspace, which would be a button on the issue itself where much like on GitHub when you want to clone a repo, there's a button that says here's the string you need, or just like on our revision control tag. And it would be git clone your name at git.drupal.org project slash drupal slash issues slash issue number dot git. And the server would be able to translate that into the namespace. So locally it looks like you're working on a copy of drupal.org with your separated branches. But on the server side, it would be connected to the main master repository. So user would make changes to the code, they'd make their commits, and they would push. So this push would you wouldn't need to create patches anymore. You'd be able to just push back up to the repository. Those changes would happen in the issue queue itself. You would just like as if you had submitted the patch, would show up as a change in the issue. So yeah, on drupal.org the issue queue would create the comments and notify everyone that's following the issue, hey, someone pushed a new change to this issue. So everyone involved would be able to see that it actually changed. And then the one thing where this kind of makes things a little bit iffy is right now when we submit a patch, there is all the explanation that goes with that patch can be typed up in the same issue. We attach a patch to the comment. In this case, you're pushing up and you've got your commit message, but there's not really an easy way to afford a richer, like here's my description of the change that I'm trying to make. Because you might want to have bullet points and all the nice HTML formatting and stuff. So you might have to go back to the issue queue after you push something major and do your explanation as another comment. So to kind of describe how this would look, this is a real issue that happened 1740492. And I just picked one arbitrary to kind of show what would happen. So Dominer would create an issue workspace. He was the first one to open this issue and post the first patch. So he would create this issue workspace, clone it, and then push the change on his branch to the workspace. Xgm saw that patch and said, this looks good, except there's some text cleanup that needs to happen. And so she, in this issue, actually posted another patch with a text cleanup. But in this case, she would be able to use the inline editor and just do the text cleanup right in line. And then he says, oh, oh, cool. Thanks. And he pulls her changes, does some more work. And he had actually posted three more patches to comment 18, 19, and 20. And so three more commits pushes those up. And then it sat for a while. No one addressed it. No one reviewed what was going on. And it needed a re-roll. And so in this case, he would just be merging a head back into his branch so that instead of re-rolling, he's just like, well, does this still apply? And the person that's working on it in their branch would have the ability to resolve conflicts right at that point. So they would be able to know that, oh, OK, there was a change in head that broke what I was working on. Easy for them to know. I should have put a commit in there on head that showed that. And so Damien comes along and says, hey, I want to work on this, too. And he says, on every commit in the issue queue, there would be a work from this point URL. So he could say, OK, well, I want to clone this workspace. But I want to work from where Damien was at. So he would clone that and would start him there. And he would be able to make his commit merge in head because he had actually also done a re-roll. And then he'd be able to push that up. And then he makes some more fixes. This is actually, again, what happened in the issue 35, 36. He said, oh, yeah, those are good fixes. I'll take those back and keep working on it. And so they're able to merge back and forth between each other. Now, Dostro came along, created a branch based off of where Dominer was at. It was like, hey, I've got some ideas. And then he made another commit. And then a long time passed. And no one addressed this for a long time. And then when Dominer finally came back, he was like, ah, I see what you're doing. But a lot of stuff has changed since then. I'm not going to use your changes. I'm going to roll this off of the patch that I already had. And so he doesn't have to merge in those changes if someone else is working on an issue. It's like, that's not the direction we necessarily want to take. So he was able to pull that in. And then Jennifer Hodgson came along and said, hey, we've got to document this. And so she submitted a documentation patch. But that could also be an inline edit. Like, let's just add the documentation around the code that we want to document. Finally he said, oh, yeah, totally. We need to document that. And from 74 to 128, he was patching and merging head in and re-rolling and patching and merging head in. Finally at 128, it was RTBC. And the last commit, Alex took that commit and committed it. And in this case, we now have all this Git history here. We've got all everyone who's worked on the issue in Git. We could choose to keep that. But I think in contrib that might be really valuable to say, oh, these five things happened. Let's just move that in. But in core, we might do something like the Linux kernel does, which is do a squash merge everything and put one commit in there and say, issue number 174092, worked on by Dolaner, Xgm, and Damian, dot joe. Be able to commit that as one whole thing. This would still be in the repository, would still have access to see what changes there were. Reviewing this, we could see each granular commit. We'd be able to see inner diffs between each of these things easily because we could just use Git to say, what's the difference between those two show me? So that is kind of it in a nutshell. This is just another demonstration with the kind of swim lanes there showing the lines between the branches and who's got permission to commit to them. And so each person can only commit into their own spot and can choose to merge from others. But they don't have to. And there's nothing stopping anybody from saying, well, let's just create another branch and we'll just work there because that might be easier for this particular thing. I'll push, you push, I'll push, you push. It might be one person's working on documentation, another person's working on the code itself. That might just be faster and easier than doing a bunch of mergers back and forth. So that would be an option too. Additionally, you could probably, I haven't fully thought this through, but you could add additional branches that you only had access to because the branch is going to be restricted by your username and the issue number. So we could add more of those if need be. So the legacy patch base workflow, what happens? We don't want it to go away. We don't want to say, all right, everybody, now you're all using Git. Because some people are going to be like, well, I'm fine with patches. What was wrong with that? And we don't want to force anybody into moving to something new that they didn't want. So we want to keep it and all the tools working the way that they currently do. So you could still upload and download and apply patches. And anytime someone does that, it would create a commit behind the scenes. Additionally, whenever someone creates pushes a change with Git, on the issue itself, there would be a link for the patch that you could download of that change. And so tools like Dredditor and other things are used to, seeing that there's a patch in line, would still work. They would still be able to review that patch. People who are used to using tools for that would be able to interact with the issue queues in the same way. And what that also gives us is it allows us to minimize disruption. It allows us to implement this feature and roll it out and beta that feature. It allows us to say, hey, you three want to try this and tell us what we missed on this or tell us what's broken on it. So instead of being like, here's the whole new thing, who likes it, who hates it, we can be like, hey, try this out. Let's work out the kinks. Let's move forward and make this really nice, and we can still keep our patch-based workflow. And then inline editing. So simplifying these complex things, we want to be able to make it so that you can edit progress that's in work. This isn't intended to be browse the code base, pick on a file, and start developing. We're not trying to build an online IDE. We're just trying to reduce the amount of effort it takes for someone to make a small change in the midst of a code change. You might need some of the start it and get or upload a patch, because the thing that we don't have from the gate, from the get go, and this is where we're going to start with. We can always iterate and add this. But the initial thing is, well, how would they select which file to work on? Where does that interface live? Right now, the only way we can browse our Git repositories is in the C Git repository, which isn't Drupal, which doesn't give us an API that we can say, this file, I want to edit it. And so that's something else we're also would like to look at, is like. Just to clarify, so it would be only changing what is being edited in Disney, so kind of editing a patch? Yeah, it would allow you to edit a patch that's already in progress. But the context would be the file that's correct. Right. And so when they edit it, it would also create a commit in the workspace on that. Whatever user it is it's making the edit, it would create them a branch behind the scenes, it would add their commit to it, and it would be just as if they had made the change in Git behind the scenes. So that people using Git would see that change, how they're used to seeing it. People, it would also create the patch on the, because every time a commit goes, the patch would go on the issue. So it kind of translates between all three systems, or all three ways of working. And then, yeah, the goal is it's not for editing everything yet. Maybe we can add that in, maybe we can get an interface to where people can say, I want to fix that, read me file. And they can change the read me file. But right now, that's not in scope, basically. Michael has a question. Are you taking a question? Sort of, yeah. On this specific thing or? Well, that's a larger point than just that, but if you want to finish, I can go back. Yeah, let's do that. I'm getting close. And then the code review tools. Right now, we want better code review. This doesn't necessarily solve it, but it doesn't break what we already have. We can still use Redditor because the patches will still be there. We can still comment on lines of code. So until we have time to maybe pull out the best part of fabricator and say, hey, here's a nice code review tool we can embed inside of Drupal.org, or here's a nice piece of open source software that allows us to do this without reinventing everything and building our own again, yeah. So it would use existing tools. We would still be able to create the interchange diffs fairly easily. We could say, this patch and that patch, what changed between those two? So inner diffs no longer need to be something that's uploaded separately. It could be something we have in the interface that says, show me the differences between these two things. I think that would be something that would be able to do out of the gates. Plus the reviews would be more granular. We would see each commit and the change that happened in that commit. With the interchange diffs, we could say, show me what happened in this issue. Show me what happened between this and the last change. So those are options that we would have for code review. And then once we want to merge the changes upstream, the maintainers could use a button in the issue queues and say, just like on GitHub, where they're like, yeah, go ahead and merge that change. We can do the same thing. We can add a button that says, this is good to go. It's RTBC. Everybody's happy with it. Push, and it would merge it in and commit it to the production branch. Or they could do that with Git. They could do the same thing. Again, whatever tool people are used to working in, if they want to work from the web interface, or if they want to work from Git, they would be able to merge these changes upstream. So what would this do for our velocity acceleration? We'd be able to use Git to reveal these issue conflicts. Right now, our version control database has kind of an insane level of detail, like each file and each line number and each file that is affected by a patch is being tracked currently. We already have all that data. So we can say, OK, this issue is touching these five files. Which other issues have these files in them? Let's do a merge between those two and see if there's a problem. So we could be able to detect this issue and that issue if we commit them both, they're going to break. So we can offer an interface that says, this issue is going to cause problems with these five other issues. Revealing things like, oh, this is intra-issue conflict and additionally revealing things like duplicates. Yes, that's what I was looking for. Thank you. It would reduce the need for disruptive patch windows. Like, oh, if we make this change, everything else grinds through a halt. Let's do it at the right time. So we can kind of relieve some project management burden there. And then when someone does make a commit on production and says, OK, here's on head. Head moves forward and that commit broke some other issue in the queue. And the person moving in is like, yeah, I know it's going to break it. We're not worried about that. But the person who was worried about that issue would immediately get a notification. They would know right then that, hey, this code that you took time to commit and add to the workflow, you would know right away that, hey, it's stale. Do you want to do something about it? And I told a friend, Jonathan Headstrom, about how many needs review issues were just floating around for just years in the queue. And he said he went through and he just started trying to apply the patches and say, re-roll needs re-roll. And doing that, and he was like, people would just come out of the woodwork and just start fixing their things because they knew about it. But for now, they don't know about when needs review breaks. Oh, we can. What this does is we've already got the intra, well. Yeah, it simplifies that process and also makes it so that we don't need to run a test to see whether it doesn't apply. Because that's all we're really trying to say is this no longer applies. We want to let you know right now that it no longer applies. I get that. And yes, we could solve this another way, just without even changing any of this. I think it's easier to re-roll patch some of that. Yeah. We have this current Git system that was custom built for us. Has it? Yeah. And so why is that there are seven instances where Drupal needs to build tools for its use. And there's seven instances where we should build on APIs and other services to provide. So I'm seeing this, and I'm thinking in my head, there's an enormous amount of code, an enormous amount of infrastructure work. And there's probably other tools on a self-hosted plan where we just integrate with their API as opposed to building something and then having to maintain it indefinitely ourselves. Well, it's just to integrate with their APIs part that is actually a lot larger than it sounds. But it's infinitesimally smaller than building the entire system from scratch. But we've already got the system built. This is just a proposal to push it forward a few steps. And I'm not aware of the security issues with the Git system. I don't share those. Yeah. But I mean, they've been patched at this point. But I don't know why we're continuing to, like, if there's the D8 mantra, we should be building our own tools, and now we're going to kind of jump off the island and embrace symphony, embrace other tools. Well, there's embracing other tools. And then there's embracing other services. And so when all of our code is dependent upon some other businesses, business model, and business decisions, that binds us to something. That ties us to something that, you know, using symphony doesn't tie us to that. Like, it's another open source project. We're not necessarily paying them to use their code. Or even signing an agreement that says, sure, we'll get it for free. I think more alarming analysis of, like, using Jenkins tools does the job. There are other tools. We couldn't build our own task partner tool. We had one, actually, for a while. We chose a product that's open source that we're using. There's other open source projects that we go out and add APIs into. And rely on them to do things like make sure that, you know, we're not the only set of eyes running it. Because the D8, with the current staffing level of 11, people really want to continue running it. I mean, that's a fair question. It's, there was an issue with the get name recently, where basically the way that authentication was happening was causing people to get denied access. And, you know, Alex and WebTrip can definitely, the test to the number of times you had to push and was like, why did it break? I'll just push again. And the only person who really knew that software works was Sam Boyer. And I was able to sit with him for a few hours and we went through the code and we dig into it. So now I know it too. But that is a good point. Like, what do we want to run our own Git Damon? Do we want to have our own Git service? And is there an alternative to that? Or do we want to run our own custom built Git Damon versus another Git Damon that we could implement? I'm not saying we should have shown it. I'm just saying that we should really, we should ask that question and investigate, you know, that we took one of the off the shelf Git Damon that are open source or even paid. How much work is it really to make it work on our system? Give you a minute, we've got the craziest access permission. The way we do access permissions on projects is not customizable on the project. Right. Wouldn't it be necessarily maybe more work to actually get out the third party system? And some of the things that I've seen is most of the third party systems haven't even delved in to get namespaces. And they haven't, they don't have that feature. Like I looked at a few of them and it's like, well, we could use this, but they don't have this thing we want to do here. So that was, that was another issue, but I mean maybe there are ones that are implementing it now or maybe we could put in a feature request. Or maybe we implement it and help them get to move their project. Right. Yeah. Yeah, and the Git Damon itself isn't necessarily a part of how this workflow works. It's just a piece that ideally should be transparent to everybody. Like you should be able to connect to the Git Damon and it should be able to interface with the permissioning and architecture. But this wouldn't necessarily preclude or exclude using somebody else's Git Damon to handle that. Would it be safe to say that this is mostly about how our Git interacts with our issues? Yes. More than anything else. And that's the one thing that wherever we look at like what does integration look like. The fact that we have coming issues, now we have issues. Did you have issues? I just wanted to show the issues. Oh, that's fine. Yeah. I mean, we've got a lot of resources we need to protect. And we have to... I mean, some of it we have implemented ourselves. Like we have our own single sign-on. We have our own variety of different things that... Sure. If we involve a bakery, it doesn't like it. I don't know. I don't know. I'm absolutely not picking on you. Yeah. We did a decent job of running the Git Damon of zero people for a couple of years. It didn't explode too much. So I've only got like two more slides. So let me just finish those. And then we'll just move right into questions and discussions. Next step is collect feedback. We've been reluctant to open an issue and start on this because I've been busy with a lot of other things and I haven't been able to respond to some of these ideas. And so now there's an issue. Now we're going to start talking about it. Now it's like go through... I want to link in everything that's already been talked about, linked in all the different spreadsheets that have happened that show like we thought about this and we thought about that so that we don't have to rehash some of the same arguments. And if the feedback is, yeah, let's move forward, then we would implement the backend changes. And this might be, Michael, where we find a better Git Damon because honestly, I don't know that I want to get into this twisted Python script and re-figure that out again in this asynchronous Python code that I somewhat understand from a two-hour code view. Then we would... And this would be implementing the Git namespaces and making all the access control and everything else work on the backend. And then we'd design and implement the UI elements, offer a beta test, get some people involved and say, hey, let's try this. Does this work? Are we crazy? Does this actually help anything? And then finally we'd launch it if it's solid and everyone's happy. So I do want to point out that, yeah, standing on the shoulders of giants, all of this code was written by other people. There's so much stuff in there and there's so many things that... These are a lot of the names that showed up in all of the issue, all of the repositories that hold all the stuff for version control and version control get and project module and things like that. So these were just some of the people that have helped me, have described how this stuff really works. So I just want to say thanks to those folks. And finally there's some details about me, Tatiana here. If you have questions that you know, product manager, my details. I'm on RCE all the time. I work for the Drupal Association. So I am available. We want to produce a product that you're happy with. Yeah, let us know what you thought. But let's take more questions. You guys, what do you think? Like what, do you have ideas? Or you're like, ooh, that's not going to work or Damien's getting up right now. So I'll let you... Just so they're recorded I guess. Yes. A simple question I may have missed. But given the current workload that you have already for other projects and the amount of work you're estimating this to be, when do you think you'll have something launchable? I mean honestly I feel like the amount of change that are required and the amount of... It's more adding tests to make sure everything works that would take the longest. I feel pretty confident that we could have something maybe beta-able by Barcelona depending on how many fires there are, depending on how many times the test spots fall over randomly or depending on those sorts of things. Because we're managing, working on a product versus maintaining issues that happen, we're kind of dual role of support and product creation. So they're saying that you've got functional prototype where you possibly only working on a code that just needs bullet proofing and further testing? Well, no. As far as the changes that need to take place are actually kind of minimal. Like on the Git daemon side we just need to implement the namespaces feature on Git, which is it's already baked into Git. It just means that when someone authenticates at the Git daemon we need to make it so that it understands that they're asking for a branch on an issue namespace. And just make the translation between git clone issue number to dash dash issue namespace struple.org.git. I've actually got some backup slides here kind of how it works on the deeper back end. But yeah. Did I answer your question? I mean, does that... Yeah, it's hard to know exactly how long anything's going to take until it's completely coming out. Who say? So, first off, I'm really excited about what you're showing us. I think the idea of collaborating on branches mirrors the way that most people work on people itself. So it's really exciting to see that happening in the issue. I'm cautious of over-editing the disruptive issue thing because if you take the example that you used as the PHT issue it wasn't that the patch was dead it didn't get committed. It was that at the point in the release cycle it was we didn't want to have to change all the documentation and all the things that surround the issue. So... Was that just for Drupal 8, you mean? Or 4, 5, 6, 7, and 8? Well, everyone's used to be like a module file coming with a .module with a whole heap of library. And also it's not. Right, so that particular issue might not have been... The disruption to the existing queue that was important. On the subject of like validating patches and giving the feedback that would be excellent. About a year and a half ago I wrote some tools that I processed the RGC queue so that when I did it I did walk back to the pile of patches that were in the RGC queue and not come back to it and need to work and have increased velocity. So if we have that happening automatically we put in... I'm really excited. Cool. Can I kind of share what you presented here through my passions like get tooling and Drupal. So I'm just wondering how can I help. I've heard a lot of things saying you've got 11 in-house people that can work on this. Is this in the open or is this where can I go to help? Yeah, it is now. We haven't wanted to ask for help until now because we haven't been able to necessarily know what to do with it yet. We haven't had a plan in place. So I think it'll be the public discussion and we'll come up with a plan and then we can definitely start segmenting tasks and have things like here's how you can help. But I don't know that we have that outline yet specifically. But we welcome it. Yeah. On the wide side of the issue... Go back to which one? Would it be possible to have like a function called that kind of abstracts away all the stuff happening on the back end so like if later we decided we wanted to switch all the stuff to a different hosting provider or internally hosted service that would just be literally changing like four or five functions for how they entered it and how to read that stuff. Is that a possibility to do in the UI now when we do that? I'm sure we could put a facade in between where we get our data and how that... Basically you're suggesting we have a layer in between that the issue queue works with an API and then that API connects with either our back end or some other and that's a great idea. That should be a way we can engineer it. The version control system itself is engineered such that we can switch over to Bazaar tomorrow if we wanted to. It's just... It's flexible. So yeah, adding that sort of flexibility might be a really good future proofing if we come to the realization that GitHub adds new features to change the way that you manage to actually work for us. I remembered my other thing. It's kind of just like echoing Michael's concern about security. During the driveway cycle there was a moment when everyone in Maintain.exe could push to the 8.x branch. If we're using main spaces, which means that everyone's going to be able to push to the 8.x repository because we're going to have to do that. It's interesting because if you submit a pull request right now to any project on GitHub you are committing code to their repository. That data is there. You can do git clone dash dash mirror and it will mirror the entire repository down and in the deep end here here's my mouse pointer. There'll be on GitHub heads tags and there's another one called polls and that's actually the pull request and the code that somebody submitted to your repository. It's one of the things where what if they can push to core but they can't push to the 8.x branch. That's really the security level that we want to keep. We want to keep it so that they can't push to the branch that matters. But just like on GitHub a pull request like it's in the repository but it doesn't merge into the thing that counts. Just from history like when that happened to un-pull what about the sparkle patch that happened recently? Gerhard's he had committed something. That's different. He was supposed to have got it. Or is that it? He's there. You got it. So I had a question. The whole talk was you come to an issue with work to be done and work to be submitted because you have an idea. Drupal is very developer oriented and I like this because it works great for developer but what about the user that's submitting a feature request for a bug report? Like take Drupal commerce for example. Like all those issues are nothing but just so so hard. I don't know it's cycle. It's going to be just as easy for them to create an issue workspace and then let's say I'm in the issue and then how I can continue working. All the use cases were brought on like you developer submitting a cache and then running with it. What about when it's non-developers creating issues? Well creating a workspace wouldn't necessarily be something that's automatically tied to an issue. It would be a button that someone could say create me a workspace I'm going to start adding code to this. So in those situations like people would still be able to comment and they would still be, I mean I don't know how else they would work on the issue besides response to what's going on and so the issue would still have all of its information in there. So they would be able to create issues and there would be a link right then to show up in the browser. Yes, yes. Yeah. Someone related to the point that I thought of can you speak to any thoughts on getting rid of commits or branches or with namespaces where somebody adds something either problematic content or say something that is that breaks the licensing agreement and stuff? Sure. Right now, I mean the way that the Get Damian is set up is it forbids forced pushes. It doesn't allow people to do a forced push to remove something so there's a workaround for that where you make another branch and then you delete, you move everything over to that branch and you delete the branch that was on there and push that and delete the branch remotely so that actually works but I don't know that we're addressing that with this but it is something we should be able to have as a thing to address if people are going to be using Get more often to push stuff as opposed to patches because then you write it, you know somebody submits a patch file and I just deleted one of these the other day where it's like hey that patch file actually had a password in it, can you kill it? And so we just deleted the patch file off the system and it was gone but putting it in Get requires a little bit more effort to make it gone so that's something we should definitely consider. So have you since we talked about removing the block of forced pushes of course? Not specifically because I don't know why it was there in the first place so I'm sure there was a reason for it so I'd like to find out why that was there to find out what were we trying to stop? What is removing that enable which maybe we could add forced pushes to individual namespace branches because no one else should be cloning your branch oh no they would still break it because they would be able to pull from it yeah well she's got a whole laptop full of questions well I'm not going to lie to you I'm sorry I just wanted to release some content who so the twitters say there's a big sidebar discussion about why are we moving to get them which you would expect but I guess what I would recommend is when you do a big blog post about the aspect of this happening really being on that I've seen you elucidate this many times that you understand all the issues of the collaboration but maybe some kind of illustration showing the fragmentation issue that you're worried about because I think people are so used to the way GitHub works they literally do not understand what is valuable about our collaboration and why that's important right which goes back to his point like I'm a I've got an issue in commerce where would I go to report like hey I've got a problem and is that an issue on GitHub and would they be able to find it and would they know where to comment and yeah it's a complete mess but I think you just need to be able to explain that because I think a lot of people are having a major reaction which is why are we spending people that owe money on this we could just be moving to get it it sounds easy but I think when you explain this people just be you know another question and I wrote this up the last time I saw this is you know there's a big emphasis on these individual branches and people pulling and pushing and stuff from each other's branches but the way that we're set up in part of the heart of our collaboration model is this swarm effect where we all just work in the same place so it is still confusing to me that that is not a default and that you Dassjo who wants to do some weird can make his own personal branch off of the main one but why we make it a lot more complicated for people who just want to work with each other it's a little bit confusing that that's still what we're planning to do well we're not necessarily removing the ability to do that I know but this seems like you're still pushing this as the default model and I think this is really hard to explain to people who are used to what it patches like it might be but this is the swarm the only reason that there's these different lanes is that it makes it so that people can't step on each other's changes right now if I come to an issue and I see a patch on that issue I don't have to pull that patch down and change my working space I can choose not to my working space is my own and nobody else is able to affect that if everyone well the way we work is messy but it's like that you just take where the latest patches you would hack at it if someone else is hacking at the same time oops you conflict but 90% of the time that isn't what happened so anyway it's just proof of thought as well so I figured the last one was oh this was one for me I'm really I'm really concerned a little bit that we're so focused on get namespaces and how this is an awesome technology and we can get this all figured out from the back it's the very last slide right or yes sorry that one that you just had this one yep so you're saying we're first going to collect feedback absolutely awesome that's great although I would caution you to have a really good explanation for why not get hub before you you know really push that on people but you're talking about implementing the back end changes first and then designing the UI elements to do the work and I think that backwards or at least those two things should be happening in parallel because it makes a really big difference to our you're talking about changing the way we work it's really important how that UI works and I think the way UI works is going to inform some of the back end changes so I would deeply request that those two things are happening alongside each other and not otherwise what's going to happen I fear is we're going to get stuff with UI that mirrors how Git works and Git was never intended for anyone other than Minus to make any sense of so right and this to be fair this slide isn't real clear what I'm talking about back end changes I was talking about the low level right at the the point where Git allows people in the door and gives them authentication but I haven't gone as far as how the UI actually integrates with that back end so yeah the yeah exactly so there's there's kind of two back ends to this and and you're right that other back end needs to come after we design implement the UI elements but this this was one that like I could provide a proof of concept and not change anything anywhere else as far as just does namespaces work will it scale like maybe it's maybe this is you know it's a new enough technology that no one's leveraged this way that it breaks everything and it's like okay it's really slow there for some reason I not sure so probably shouldn't it see right it'll just leak memory you want to hit the microphone sorry just since I can't guarantee anything on this but one of our essay is I believe it's the package maintainer for Git for giving you see like he blows my mind I can try to like clean him and see if he has an influence on performance though then it's doesn't speak to the stack I don't believe that would be the use of like the GSM intricate I actually went into the Git the blame log for this issue in Git and found the guy who committed it and he works at Intel in Portland and I've been following him on Twitter and kind of liking his things and getting to the point where I could be like hey can I ask you a question you know so but yes yeah any any questions and help on things like this like that would be great anybody else well hey I think that includes this session