 Hi everybody. So we're here to talk about revamping the project application process on Drupal.org. Yes, we are. I'm David Hernandez. I am a member of the Drupal.org software working group, which is a governance group that's part of the Drupal project and part of Drupal.org. I'm sure you all know about that. Who doesn't know about the governance groups? If you don't know, go to Drupal.org slash governance and you'll find out about all the different groups. The software working group specifically is the one responsible for most of the workings of the Drupal.org website itself and the community-facing sub-sites. And I'm Michael Hess. I am in the security working group, which is actually not a Drupal.org group. It covers the Drupal project, but also interfaces in strange, tentacle ways to Drupal.org itself on this topic today. However, unfortunately, neither of the two working groups that we represent own the actual policy we're discussing. The policy is owned by the technical working group, which is another governance group. The group is actually responsible for most of the technical policymaking that affects the Drupal project as a whole. None of their members could be here today, but they were responsible and they did a lot of the legwork for making these policy decisions. And it was really a group effort between people who really cared, making sure security concerns were met, and making sure we had changes that were necessary that the community wanted, and that there were things that we'd be able to implement on Drupal.org. And so we're going to review the current process here. Yeah. So the current process, we know people complain a lot about we hear those complaints, and that's one of the reasons why we started this process. We know currently it's very slow from the time someone initiates a project review to the time they actually get vetted, can take months, years, sometimes. It's been a huge pain point for developers in Drupal.org. It's something that's actively been hurting the community, so we want to make sure that we try to do something about it. It relies way too much on human work, having reviewers actually manually review code, check projects, test them out, manage the queue, provide feedback, almost really mentor some of the new developers and make sure they're doing things correctly, using APIs correctly, make sure that the code style is correct, doing things like checking for project duplication and all this sort of stuff. It's a really long involved, almost painful process for new developers and something that they're not normally used to, especially if you've been using, say, GitHub to just publish your content, you can just do that right away. So this process discourages a lot of people, and it ends up creating this sort of two-tiered or multi-tiered environment that we have in the community where there's the has and have nots, the people who've already been vetted who get to join the club and walk right in, do whatever they want, and the people who haven't gotten in yet, especially for older developers who've been around the Drupal community for a long time, people who never had to actually get vetted. I think this is one of the reasons why this process has gone on for so long this way because it's not a pain point for people who've already been through it or people who've been around for, say, 10 years. They don't understand the frustration for new developers, so it hasn't really been a high priority to do anything about it. But there are things about the process that work. It helps us limit the number of spam projects that created. If we just had a fully open system where everyone could just dump whatever they want in Drupal.org, you would have all kinds of problems, malicious code, terrible code, people that just try to do bad things and are using Drupal.org as just their host to put these horrible things out there. If we think module duplication is a problem, obviously it'd be 10 times worse if it's just completely open. All of those problems create security problems, and that's something that adds a huge workload to the security team. Drupal security is really a selling point for the project as a whole. It's something that we consider seriously. We like to tell people how secure it is and how the modules are secure for the most part. It's a really big selling point for enterprises, for all kinds of people, so if we want to continue this policy we have now doing security reviews and having security advisories for all the projects and we just open the floodgates and have millions of projects coming through, just think of the amount of work the security team would have to take on. Obviously it would be too much. Out of the slide, Vosley, who's kind of spearheading the project application. Yeah, he's one of the main main people behind it. He's also a member of the security team and he points heavily to reviewing projects with Security Eye and about 10% of the issues had major security problems with them. That's from February, so it's probably keeping that trend at this point. There's been this pain point and we've tried to find a process to address the pain point and we've got some goals along addressing that pain point, but we should preface this, or at least I'm going to preface this with this is a it's a step in the right direction. It's not going to solve all the problems, but it's going to get us in the right direction. Yeah, there was a lot of discussion post online. If you look at that link, that's at the bottom, that's node 2453587. This is where I posted the full policy. You'll see most of it in these slides, but it's fully written out there and there was a rather large discussion about it in the community about different things that they liked and didn't like. Feel free to review it and add more comments if you think necessary. We'll sort of do a brief version of it, but what we really want to do is make sure that we don't just describe the policy changes in the new procedures, but give some explanation behind why we're doing certain things that we're doing. We understand that some people want us to go further than we're going, but there's reasons why we're not going further. As Michael said, we're going to do some baby steps. We're going to see some things, see if how they work. If they do work, we'll progress. If they don't work, we'll find new solutions, but we can't just do everything right away in one step because if we do, it's letting the horse out of the barn. It's hard to put it back once you do. If we were to completely put everything up, it would be almost impossible to go backwards from there. Some of the things we're trying to do is get rid of this two-tiered system. Treat all of our developers equally. Not just give preference to people who happened to have just been here for a while or know the right people. We still want to make sure that we prevent insecure and badly written code. We don't want to just turn Drupal.org into GitHub with all kinds of random garbage if we can prevent it. We do want to give sandbox users some installable releases because that's one of the things people have really been asking for. That sort of sandbox idea was a bit of a stop gap, but it was a nice way for people to post their projects, but they still don't like it because you have to check them out. We're going to go into how we're going to promote a project and the people who are able to promote their first project, they get the vanity URLs, they will be discoverable. Right now, if you create a sandbox, you just get a URL that's like Drupal.org slash user sandbox, one, two, three, four, five, six, but it doesn't really show up in the main searches and things like that, but we're going to have a few changes where people can promote a single project and that would show up in searches. And we're adding a lot of automation to the process, which should help reduce the workload for the reviewers. We really are growing at a scale that we have to reduce the manual workload as much as possible and move towards basically a fully automated system if we can. I think that's the only way we're going to keep up with the demand that we have, or at least get the human factor down to the point where it's things that are simpler or at least the things that we want and not all of these other things that could be automated. So what is the new policy? We're going to outline some of the key points of the policy and some of the new procedures. So all projects will get scanned by automated code review tools. This is actually a live screenshot from Drupal.org right now. Administrator role to see. It needs some cleanup before we make it available to more people, but this is there and working summary data around this is actually going to be made public for every project. So whether it's views or a brand new project that somebody just created, the number of warnings, the number of errors is going to end up becoming public. So we're going to have some project health metrics. Thank you. Project health metrics. In addition to the number of open issues, the number of closed issues, the little graph that we're drawing out there now, this will probably show up in near the same place. This is actually going into the database in a manner that can be displayed there relatively easily. The barrier to this moment is project application review doesn't really work well for projects like you. It needs some work to make it more translatable, but it's there. It's in place and it running out of a docker container. So if you'd like to sprint on this, let me know and I can set you up with how to do it. Once we get that taken care of, the results, the full results, which is what you're seeing there will be shown to project maintainers so they can actually see what the details are and correct their code. So rather than a project application review person telling them, hey, you need to do this, this, and this, they check in their code, they pull the results, it shows them what they need to do, they fix their code, they check it in, shows them what they still need to do, and they can fight the test spot so to speak, except it's not a real test spot. But they're fighting a computer as opposed to a person which makes things go much smoother. It reduces that wait time. And we have not discussed quite yet what will block a project. So obviously we'll get warnings versus errors and at some point there'll be a bigger discussion as to what exactly the flag will be and what we'll definitely put a stop to project promotion. And speaking of project promotion, we're going to basically make every user, get vetted users, non-get vetted users, start with a sandbox first. Yeah, so we have design work I think to do. Obviously like these are the implementation details which we haven't gone over yet, and that's going to come later. So some of the questions in the discussion we've had before with some people was like, well, how is this part going to work? And it's a bit of the implementation detail, which will be public and it'll get worked on. We'll have designers involved, we'll have community people involved, but yeah, it's essentially going to be probably like a button or a link that you'll click and say, I want to now promote this project, I'm ready to do it, and the scans will happen, you'll have to make sure that you don't have any of the flags that we decide on. And a key point is that only the owner of that project will be able to initiate the promotion, which is a slightly different change than what we have now to stop some people who are sort of skirting the rules by having other people sort of take over the project and do it for them and then hand it back, things like that. It really is about getting that individual through the process and incentivizing them to do it. So if it passes, you get promoted, you'll be able to take on a namespace, so you don't have to deal with those ugly sandbox URLs anymore if you actually want your project to have a specific name, a specific URL, you'll be able to choose it, and this is before going through the actual vetting process. So you'll get that one project, you'll get a nice URL for it, then you can begin the project application process to get vetted. So non-vetted users are going to end up with some restrictions on them. They can only have one project at a time promoted to full status. That's for really two reasons. One, to prevent grabbing of namespaces and squatting on it. And two, to like encourage them to still go through the whole get vetted process, but hopefully it'll be easier once we have some of these other changes like automated code reviews in place. The promoted project will have development snapshots. Those are the releases that appear in red at the bottom of the page, but won't be able to have tagged releases, so no green releases. They are not able to create a supported release because that invokes the security team at that point until they've gone through it. And the project page and potentially update status will have some type of warning that this is experimental, non-vetted code and that the project is not going to be subject to security advisories or security team interplay, so to speak. So that new users of the community who find a project get a little extra warning that what they're about to download may be not that safe. Yeah, so let's discuss a little bit why so that you guys understand. As Michael said, this is about pushing people towards the application process, not just giving them new candy. So like one of the questions we got continuously is why only allow one project to be promoted and why not three or five or something like that? Well, obviously, a lot of people when they're creating projects, these developers, maybe you only have one or two or three projects that you're ever going to create and become the maintainer of. So if we allow you to create five of them without ever getting vetted, what is your incentive to actually ever go through the process? You can create five and then be done with it. So that's why we really want to limit it to one so that we can give you that one project when you're a new contributor and you've got that itch to scratch and people tell you, hey, why don't you contribute that thing that you made? You can just go ahead and do it right away without us holding you back, but we hold you back just from going further just so that you can go through the vetting process. And the same thing with the development snapshots, obviously, we only want to give people dev releases, but we want to give them those releases so they get that download link that shows up on the project page that they don't have now. So if somebody gives out that project to a friend of theirs and says here it is, go download it, they at least get that link and someone can get a tar ball and a zip file without having to use git to check the project out. But again, we don't want to give them full releases because we don't want to misrepresent the project and the developer as being a full project and haven't already gone through the process. I don't want to stand. Would that include Drush access and then the ability to do the daily builds and updates? It's a release on Drupal.org so Drush will be able to pick it up. So the project application process, it would be different but you'll still have to essentially do what we're doing now where you'll have to submit something in the queue and we can probably automate this as part of that button where it creates an issue in the queue, lets us know what project you're trying to promote and then immediately someone can start looking at it. The nice thing is because it's already been scanned and gone through that whole process the reviewers then know there's legitimacy to the project that it's passed all of our gates. So it should be relatively free of certain like code style problems and a lot of the other cruft that you know normally deal with. And the reviewers can go ahead and just start reviewing not having to worry about a lot of that sort of administrative overhead of saying hey you didn't include the read me file if you think that's important or you know all your spacing is wrong or you didn't do certain things and like that's part of what takes so long. So we'll do that and then once they review we've sort of reduced the burden on the reviewer as far as what they have to check for. So we're pretty much getting rid of the whole idea of mentoring people when they go through the process except for small things like hey you should have done this instead of that. We encourage the reviewers to notify people about certain mistakes they've made but we really don't want to hold up the project. We just want to ensure that the project is minimally viable in a way. I mean because after all these are still dev projects right we shouldn't consider that it's a full 1.0 viable project when someone submits it. After all we do the same thing. People who are already vetted will create a new project and the first thing to do is put it in dev and then say well I'm working on it and I'll have a beta soon. It's like why do you get to wait on a beta but the person going through a project application has to be basically release ready when they do it. So we still need to make sure that there aren't licensing problem because that's an issue for Drupal.org so that's mandatory and the reviewers are going to check for security and they're going to check for API usage but we want major API uses. Someone basically looks like they've used Drupal before and written a module before. That's what we want. We want to check the module and see that it doesn't look like someone who has no idea what they're doing. It has never even looked at the documentation and they're just doing all kinds of crazy things. They're just coming from a straight PHP background and they've never done Drupal project right. You know things where like we've seen people you know are building out pages and not ever using hook menu because they didn't know that was a thing. It's like well if that's not a thing we probably shouldn't vet you just yet and tell you how to do that correctly. But we don't want to like handhold and completely mentor people and turn them into you know A1 project maintainers because it's just a lengthy process and that should really be more of a volunteer process something that they want to do and you know we can provide that but we don't want to hold up their application and basically their the rights for their accounts on things like that and things that can often be a little opinionated from reviewers. We want to keep it strict to the technical stuff. We're not allowing this project to go through because you did something really bad, something really insecure or you did something really terrible with the API we have to flag it. So we should assume come from the point of view of assuming a project will go through when looking for something to stop it as opposed to you looking for permission to get it through. And this last point here that's actually already being done right now. Yeah. And it has been for a while by Clause C and Matt and I and all the others in the in the Git application or in the project application queue we're actually probably a little less lenient or more lenient than some of the novice users that are helping us out in the queue. So just something to think of you know if you get flagged on something because it's an API Drupal usage thing security yeah that's always going to flag it but if it's a Drupal API thing you don't have to fix all of the stuff because the Git admins probably aren't gonna flag it. It depends on the API usage most of the API some API misuse can lead to security issues even if the way you've misused the API is it directly a security issue? What I'm trying trying to say is it's gotten a bad name and I'm trying to address that that bad name yes obviously we need to address security. I think also part of it is as we do these policy changes is to make sure that this is actually written down and approved so that if there are conflicts and people are going through the process can actually point to something and say no you're not supposed to stop me on something like that. I mean I think that's important we look at it from the reviewer's point of view but we also have to look at it from the applicant's point of view as well and make sure that they're being treated fairly and that they have a way to respond in the process they can go through and resolve that conflict. So with the reviews in the project application queue is that data that we'd want to keep with the project? I mean I'm thinking in terms of an example project I looked at this module that implemented an API for a third party service so I was like looked into the code and was like wow I don't know if I want to use this and then I found it in the product application queue and D-MAT had given a really long thorough review of everything that needed to be fixed on this module and various information I was like wow this is really he just saved me so much time of me actually looking at it. Is there value in surfacing those sorts of reviews up to the module project page or is that something that we to the project page? So actually yeah so like when you ask for a when you ask for when you create the sandbox and ask for the get that user basically putting that issue link on the project page so that people who find the project the full project that yet where the author yet has to get get that user I've been up since can find that issue much easier than having to search some of their queues they may not know exists. Oh so you're saying and related to that I think once that project application has been approved there still might be some minor feedback that probably should be opened up in an issue over in the project queue and I think that's lessons for me as a get admin and others right we need to be thinking about that in a process of procedures. Sure like I to make sure that we find it's syntax error or something not a big deal we won't hold it up I'll file an issue in your project and approve it. Yeah I would agree. Yeah I think we need I think as get admins we don't do that we need to I think that's good lessons good notes for us or make the author of the page do it or as a learning experience. Let's just put that on. Oh it is on okay or would it be valuable to have a way to take the issue once it's closed in the project application queue and just move it to the project so that it's a closed issue in that new project queue so that it's historical and it's easy to find and you can see the process you know. Well I guess it depends on how much history we want in the project application queue because if those issues. Well we could we could put a tag on it. I mean I definitely do want more metadata for those applications because we want to know things like you know we've been discussing all day things like who are the reviewers and how much credit are they getting for the reviews that they do so we want to make sure we do have that kind of information and that that could be really useful in the future too like we know that not only this is a top 10 reviewer but they honestly they have the best reviews we see like the projects they let through had the fewest problems or ones that keep getting bounced back or have security issues are all being reviewed by the same person maybe there's something that they're not strong as reviewing or could use some help with or something I think that's all useful information. Question but I think this is great because I've been working on a module for a year now and it's it's substantial it's three to three five hundred lines of JavaScript and 2500 lines of PHP and I'm having a hard time getting anyone to even look at it so but it's a module to edit images rotate and contrast and saturation right in Drupal and I think it's my question actually I'm going to have a question is when do you see this change taking place? So the policy change is really immediate it's already been voted on and approved by the technical working group so technically that's really done the code scanner is in place as Michael said it's already working and scanning projects what we have to do is get to a point where we think the scanner is working really well discuss the things we want to flag and then we'll probably have to open it in some permissive mode at some point and test it out and then maybe have a few test cases to test projects that we go through but until the scanner is done and working properly we can't do the other things like the project promotion to do the vanity URLs and stuff like that we'll probably hold off on that I think but there are things that have been worked on since the beginning of the year and we're continuing to work on them. Could you clarify a little bit of the get vetting status? I've got I maintain her on a couple of modules that I inherited but I don't have a way that I can see to promote a sandbox project so are there are those two separate permissions or there's no promoter sandbox like button right now okay you I don't I don't see a way to create a named project and that's I was thinking about this thing um yeah so you're not vetted I don't know yeah I don't know if I don't think there's anything actually tells you on like your your user page or anything yeah yes there's no but I do have get access on several projects so no no an official project a couple of official projects that I inherited and yeah anyone can be added as a maintainer to another project okay as long as you what is it as long as you've agreed to the get yeah the get a user agreement thing whatever okay because I've got a sandbox project that is just about ready to uh to go through the application project okay so you know honestly now that I think about that's probably something that would be useful for the application process to know if that person's already listed as a maintainer or other projects yeah and then we can just check and like if the reviewers know oh this person's already been working on things and committing and see the work they've been doing that might be an interesting thing to do with the review process would be just to take every single maintainer who's not get vetted drop them onto a list and have some process whereby a get admin goes through on some regular basis and says yeah these people are cool let's go ahead and bump them up to get vetted or is your staff volunteering it depends on the number I mean if it were if it were something reasonable that were you know that we could do with an hour a month that would be totally worth it for the community but if it's something where you know I have to dedicate a whole person to it not so it's hard to know like if you've been given access to a module it's hard to know what contributions were yours as a non-get vetted user and what ones weren't but we're getting a little off a topic and I want to kind of stay on topic with this I actually had an idea related to that but it may be if it's off topic the idea was we've got the new the new new user tag and let people kind of vet users saying they're not a spam bot but maybe surface that for people who are get vetted you know saying you know this is someone who is in this kind of gray area status and if they want to kind of take a look at them and vet them kind of on a one-on-one just surfacing that when those people appear on Drupal.org rather than making it a list I'm not sure what you mean if someone is well the new user label shows up when they have a new account right but then there's the community member status I can't remember what it's called are you saying what if they upload a patch to something no just if they are actively participating if they are maintainer on modules you know if they have made commits but they are not get vetted so just a way to mark that account and if someone sees that and say okay yeah they're cool that's kind of the project admin or the get administrator role is what that is yeah so if there's if Ryan doesn't oh you remember sorry um so someone will be able to promote a project right they'll have one that is downloadable people can use it on their sites I'm imagining a scenario where some subcontractor gets hired to create a Drupal module for a company and they put one up there and then they never come back and it sits there and it gets used is there some arbitrary line of like n number of uses or downloads so we've discussed this sort of like namespace squatting and that kind of stuff um we haven't but but he's actually going he's going in another direction yeah not not namespace squatting but like they've got a module up and it actually gets usage far and wide but the developer has no interest of going through the application process and actually becoming get vetted because they're gone they just have a module that everybody uses but that's that's going to be a project that exists so it would probably still be subject to the rules of like somebody else taking it over or even if they just decide never to well the the current policy on one point of release the current policy on transferring ownership of a project would apply in that case but that user who originally promoted it would not get vetted sorry i've kind of polluted it with the user being gone i mean they're there they just don't care about creating a one point or release because people are using their module and they're just like whatever it's just beta one beta two beta three it's still going to sit there with all the warnings and everything else that we usually will have right but if people use it anyways people use it anyway it's no different than this situation now where people download dev releases of things and they shouldn't we're probably going to put like my goal for this and we haven't talked implementation would be that the project page has something ugly in it and update status inside your site has something ugly in it so it's going to be really obvious you're using it and just you know if you download code from a sandbox you have the same problem now okay last year at triple con there was some questions during the friday sprint about doing some type of mentoring for the project application review process like people that were interested in it if there is significant interest you have friends we might be able to do something like that again we did that last year we might be able to do another one like that just to answer questions on the on the friday sprinting okay great okay so go there do the feedback form fill out thing evaluations whatever it's called session page and come to the sprints and definitely come to sprints on friday and if you were really really interested in helping with those automated scanners talk to michael there's already some interest shown in it so i'd love to turn that over to people who have interest in scanning large chunks of code i have a it's for a friend project with rtpc well