 Yes, we should not plug this in, right That microphone, right they take a lot of care. Okay. Hello everyone. Thanks for stopping by We will talk about the project application review process today How you can publish projects on ruble org? This is not the developer session. This is not the site builder session. This is more an Organization organizational kind of session where we talk about how we work on ruble or how contributors can Contribute the code how the process works out. It's not recording looks good We are still okay. We are recording already so I can continue Who are we? My name is Klaus bura or Klausie on ruble.org. I'm from Austria I work with ruble for about four years. I'm a ruble developer Not really a theme or such more module development I work for a small company in Austria called epico We're doing online job boards and the recruiter distribution I'm also a code review administrator. We talk about that later That means that I have the permission to grant others the right to publish the projects on ruble.org I'm a Google Summer of Code Mentor Yeah, that's basically it Hi, my name is Patrick. I Just started ruble one year ago and I pretty soon got stuck in the application queue. Is this good? Sound is okay Well, I'm working for Malou and I'm also a project application administrator and My druble org name is Patrick D Yeah Okay So you might wonder how can you actually contribute code on ruble.org? so One fundamental concept on ruble.org.org are sandboxes Sandboxes are git repositories that have a project page and a full issue tracker That everybody can use for free So this is the good message if you have code if you have you developed a module and you want to contribute back You can start right now by pushing it to a sandbox and where you can collaborate with others You can manage your project with the issue tracker and so on just register on ruble.org Click the confirmation that you will only Publish GPL version to code because that's Required on ruble.org and then you can start creating a sandboxes. There's also a lot of documentation Where we can read that up how you can do that. It's quite simple. Everybody can do it That's what a typical sandbox looks like The it has a not so shiny URL which is tied to the username with a unique identifier It has the term sandbox in the title so that people know it as an experimental project And that's that's one fundamental thing about sandboxes they are considered experimental they are Not verified project mostly there is new code in them You should use them with caution if you are deploying that code on a production site You should verify yourself that it actually works and that it does what it's supposed to do And it has no download loadable releases as you can see there is only the git URL very prominently placed on the project page So that developers can easily download the module But it's not intended for end users for site builders that are just looking around You have to know what you're doing when you are using a sandbox on your Drupal site on the contrary We have full projects on Drupal.org I'm sure you have seen those views for example is a full project or Drupal itself is a full project on Drupal.org And the full project is basically a sandbox and it has some additional gimmicks for example It has a nice project URL where the module short name or the theme short name is used in a URL It has package releases for download. So it is Specifically intended to be used by end users. It is also favored in search results and full projects are considered to be healthy and maintained and Everybody expects that's critical bugs or security issues or whatever gets fixed in a timely fashion so that is it is really considered something community supported and I'm sure you have seen that That's a typical project page of a full project on Drupal.org The path is slash project slash the short name of the module or the theme rules in this example It has most of the time it says stable release published that you can download in the tar ball it In many times it also has development releases where you can grab the latest nightly slap snapshot of the repository and It has user statistics, which sandboxes have not because they are not tracked by the Drupal update XML system So you can see how often is this module used often has it been downloaded and so on So that's about it for full projects The thing about full projects they are not for free and there's a reason to that and there are several problems with The idea that we should give full projects just to anyone First there's the problem of namespace squatting because you know the internet It's full of spammers if we would give full projects away for free people would just reserve the name We would Run out of short names very soon. So models would would get very long names and so on Another thing why we want to Hold back things a little for full project is a licensing issue issues because Drupal.org is GPL version 2 only or everything that's compatible to GPL version 2 so We need to protect the Drupal Association the legal body of Drupal.org from any issues that might arise when there is copyright infringement or whatever Another important thing for Drupal's reputation is of course security We expect from full project that they are basically secure Of course security issues can always happen and they do and we have a process in place that deals with that issues But in general we consider that the developers that work on that module know what they are doing and they are familiar with security best Practices so that everybody can safely use the project So we want to make sure that full project before they are released Have secure code in them Another problem and I assume you have all stumbled upon that one is project duplication on Drupal.org We need to make sure that we do not fragment our community in forks of Basically the same project We always emphasize the notion of collaboration over competition. We want people to work together We don't want them to fork a project for a minor reason Of course if you are a new contributor you think you can do everything on your own and you have your idea You can do it right and nobody else can but we have to just push people in the direction of working together and to not duplicate what's already there and We also want to make sure of code quality and best practices because every full project on Drupal.org is Might get copied because people learn from full project. They use them. They modify them So you want to have a good code quality in them and we also want them to use best practices how Drupal all the Drupal API should be used and Another problem are abandoned projects. We already have a lot of abandoned projects on Drupal.org because the maintainers Have moved on do not have time anymore to maintain the project And if you would open the floodgates and would allow everybody to create full projects We would get a lot of abandoned projects where people just dump their code and move on and it would be even harder to find the Right modules for your Drupal project So what do we do? We want full projects and we want high quality code. So we have a process in place. That's the project review process and That works like this There's a permission on Drupal.org that we can assign to users so that they are able to Publish full projects. This is a one-time approval process. So if you have a new module you go to the issue Q The issue Q is Drupal.org slash project source project application, which we use to manage those Applications and you bring the basically you bring a new project and we bring the reviews So we want to make sure that you have a basic understanding of Drupal and When you are through that you you get the get vetted user role That's the permission or the user role on Drupal.org So you are able to promote any sandbox of yours to a full project so the sandbox is the Preliminary step you can publish all the code and do blood or any sandbox It just says that it's experimental and then you get the permission and then you are a verified member and you can publish a code in a full project manner and An important note here if you want to collaborate on an existing project If you want to help maintain views for example at the maintainer of use can add you as maintainers So you don't have to go through this process. It's only for new project when new full project should come out So maintainers can manage themselves if they want to add people as maintainers to their project Exactly they don't have to have to get vetted user role. They can be just normal Drupal.org users They just have to accept the licensing terms before they can commit any code and That's it and then you can commit to views if you have been accepted as maintainer without any approval process So that's that and what's happens next your application is then sitting there in the Issue queue and people will review a project and everything and if everything went well a code review administrator like me or Patrick or Mica who is sitting here? Will approve your project and you get the vetted user role and then you can move on to full projects There's also a list of people that are responsible For that approval process, which is listed on groups or Drupal.org I put the link here You can download the slides after this session and looked it up yourself So there's a basic workflow in place. You all know the Drupal.org issue queues an issue has a state and we use that state to Express some certain condition that apply currently to an application For example needs review means that the application is ready to be reviewed by regular Drupal.org reviewers The needs work state is used if there are problems with the application licensing issues a security hole Whatever so that signals to the maintainer of that sandbox. Hey, you need to correct that before we can publish that as full project and in the end a reviewer marks that as review and test reviewed and tested by the community So if there are no issues left and the reviewer is confident that this can be published It gets the state and then the code review administrators like us step in and approve that or bump it back to needs work if we find issue for whatever reasons and The closed states if an application goes through it. It is marked as fixed if an application is not Appropriate for whatever reason it is marked as won't fix and we also have to duplicate state because we want persons to As submit only one project at a time because we already have a huge load of applications coming in So we want to have only one application per person and we mark other applications of the same person as duplicate That's basically it the workflow is documented. You can also look that up Yes, some benefits for you viewing applications. You might be wondering why are you doing this? What what can you take away from that when I started reviewing applications? I think in September or October last year I really got a huge learning experience You learn Drupal because you look at other people's code you learn how to do things you learn about alternative ways to Solve specific problems you learn how to analyze for a encode. That's a very important skill that you gain and Of course you learn to write secure code because you see what other reviewers find and you'll see how they identify Security issues in modules, which is really a great gain to be a better Drupal developer and of course you learn about best and worst practices you see What what people do vary in an elegant way and you see what people are doing really wrong and Of course you tell them about it and Yes, you you get to know common patterns how modules can go wrong and what is wrong with them And of course you stay on top of what is new it's and hot you see What is missing in Drupal what ideas people come up with how they want to? Improve Drupal by modules for example how they develop their responsive base themes or whatever. It's really cool to see the way forward and what the new ideas that come up with new contributors and In the end you get a lot of karma of course for helping and mentoring others you can make a name for yourself you You are well known in the Drupal community and you can use that for your own projects to promote your own projects or Getting better feedback for your patches or whatever for sure We cannot simply review modules by random We need a system to do this and to make sure that are the important points are always checked and we've spent a lot of time to implement a good review checklist and you can see the Main points up there. It's basically first check if there is a similar module module available and if it is Asked the Applicant whether how it compares to the existing module is it really necessary to duplicate it and it and if it's obviously a Full of functional duplicate then close the issue Then also and we only allow one application per user That's because we have a very very high workflow already and we can't Just have anyone ten applications waiting in the queue and let's see which one gets fixed first That simply doesn't work out So we first have to make sure that one user will really only one has one application Then many new users are also new to get That means that some of them don't know how to push Codes onto their git repository some of them even don't know how to create a sandbox and they simply create an application issue so we have to make sure that code is actually there to review and That they are using the correct names for branching and tagging other issues are a Custom license that text it's not necessary to add your own license that text because it's added automatically by the packer and third-party stuff as closely said it's only a GPL version two will out well What's often underestimated while reviewing projects is the documentation of the project Does the does the project page contain good good information how to install it how to use it and There should also be a read me available because The most users of these modules will be side builders and side rules are mostly no developers and They have to understand what this module is doing without looking into the code and The second and most important point is that you are securely and correctly using the Drupal APIs and For sure you have no security issues in your code, but sometimes can be hard for new reviewers, but The admins at least will have a deep check on this Yes We said it already and security is a very important issue for a new project The most common issue that we see is cross-site scripting or XSS, which you see in this picture is the the biggest part of the pie and Which means dealing with user-supplied text is dealing with a bomb basically because Drupal stores user-supplied text Unsanitized and if you print it out you need to diffuse that bomb so to speak and most people forget that There can be glitches where they not doing it correctly and if that user-supplied text gets printed without sanitization there might be script tags in it and then JavaScript would be executed and information could be leaked or the account could be taken over or the session cookie could be Send it elsewhere whatever so that's the most common issue that we see From time to time there are unprotected menu parts in modules That's an example for commerce modules that integrate with some payment gateway For example where the payment gateway calls back to Drupal and often that page callback is unprotected with no permission And then you have to be careful what you are doing in your page callback You have to make sure that this is a valid request from the payment gateway and not something other that Hackamite attempt to send at that path. So I've seen some issues of that Of course, please use the form API because when users are submitting data We need to be careful what how we validate that and how we use that people are often using the PHP superglobals dollar post for example, which they should not do. They should use the form API We see some cross-site request for three which means You're executing an action on a get request So somebody just visits a page and some random stuff gets executed That is not allowed in Drupal because somebody could trick you into clicking that link or following that link and then action is Executed on your behalf, which you might not have intended so We also see access bypass on any front So every everywhere where user privileges are escalated where they shouldn't shouldn't have been and What it's very rare nowadays is SQL injection because people are mostly Contributing Drupal 7 modules right now. There are very few Drupal 6 modules and in Drupal 7 We have the database API which takes good care of SQL injection. So that is really rare now There's also documentation on Drupal.org for writing secure code. Please read it. It's really helpful information how to deal with user supplied text and so on Another important aspect I want to mention is mentoring of new applicants. Of course, those are new contributors They are new to Drupal. They are new to the contributed world and we need to take care of them We need to take care that they don't turn away. We need to support them in a way of creating a full project Which means we need to give them links to resources. It's always good when people can inform themselves So providing good links is really a Task for reviewing an application or suggesting alternate alternative solutions more efficient solutions to applicants It really can open their eyes when they see what exactly they did wrong and how it can be done correctly And they are also eager to solve that issues. Of course, clear instructions are important. So We are exactly the problem. How should it be solved? Where can you learn more about that? Yeah The more specific you are the better for the applicants and of course we need to provide help and encouragement to applicants because as I said Drupal is growing Drupal talent is missing as we said yesterday in his keynote and We want those new contributors one. We don't want them to turn away. So it's important to talk to them in an encouraging manner So from my point of view, what do I do when I look at project applications? First I checked the review bonus list. I'll talk about the review bonus system a bit later then I checked the RTPC issues because I'm Git administrator I can approve people so I look at the RTPC issues then I walk down to the critical issues that didn't get a response in a long time and then I do some random reviews here and there and Look after each a queue that it is in a good shape Yeah, that's basically it. I'm basically introducing new applicants into the queue and mostly approving and the oldest RTPC issues because there are a lot of them already and a Lot more there are oldest applications There are many new reviewers who come in and review the newest applications but I highly recommend to review the oldest ones because there are people really waiting for months and Generally, we both she giving support and cheering up desperate applicants It's reviewed and tested by the community It's a state in the queue that indicates this application has been looked at no problems have been found We can move on with it. Hello administrators. Please take a look at this. I think it's ready Correct Exactly. So the issue queue is located on Drupal.org It is just reused a normal. It is a normal project page that is used as this application each a queue and There we manage the applications Yes shortly just raise your hands if you have any questions and it's even better if you go to the microphone Oh, yeah, please begin. I think we are not that many Yes, exactly. So the command was that there are 500 open issues right now But not of not all of them are waiting for review There are a lot of issues that need a response from a maintainer of the sandbox and there are approximately 100 open issues that really need review We get to the actualist now right now Well the queue unfortunately, oh another question. So my question would be if I submit the new project How can there be an issue queue already because it's new And every project has an issue queue. It's the Every sandbox has its own issue queue without being promoters, but a project application is a project Which has an issue queue where you should submit your application to so you create a new issue in the queue of the project application project Yeah Exactly so the command was that it's an issue to get the actually the get vetted user role So the project applications issue queue has no code in it. It's not a code project It's just a way to manage applications We're just reusing that the project tools that are in Drupal org to organize the applications That's it Exactly. Yes. So the command was that in an application issue. There's a link to the user submits the Application there's a link to the sandbox. There's a short description What that user wants to accomplish with the module and then it waits there for review? Yeah Please come to the microphone Yeah, we're recording this so either I have to repeat the question or you can speak yourself to the microphone What what's a reasonable Time to expect someone to review an application, you know, if I submit it Do I wait a couple of days or do I wait a couple of weeks and it's still considered appropriate because I don't want to start bothering the reviewers So that depends on your application There are certain incentives that you can do so that the project gets reviewed earlier like the review bonus system I get back to that in a couple of minutes You can of course raise your priority of the issue if you're waiting for two weeks You can raise it to major if you're waiting for four weeks. You can raise it to critical So then it's more likely that you'll get a review Well, it won't help you much to make it critical It won't help Yes that that's in Actually an important command Drupal needs my module You need you need to good you need to do good things and talk about them If you promote your project on your own and you get people to know they will of course Stop by at the issue can't review it because they have an interest that it gets promoted to full project. So Okay, any questions lift? Yes Not not just us. We are just the administrators who say oh, yes, the reviews went fine Now we can approve it, but other people are doing the reviews. So we really rely on regular reviewers that stop by and chip in exactly Exactly, and then if the administrator detects that that review wasn't really a review Then yeah, it's not a good image for the reviewer themselves And we we didn't have actually any problems with that most reviews are quite okay So there are no just setting something to R2PC without any review. It works out pretty well. I think Anything left Okay, so as we see the queue has some issues and The current status of the queue is there are about 100 applications waiting for a review for a review and There are 1,800 overall applications and there are three two four new ones per day. So that's pretty much On the other side only one per day gets approved if it's a good day and 111 of them have still security issues so you can see that the whole process really is makes sense and it's really necessary to check this and The obvious problem is that we have a huge really huge lack of active reviewers which leads to very long response times very desperate applicants and quite bad reputation to potential new Drupal developers because they are simply Mad about how long this this time takes to simply approve this project and Yes, the only solution for this is we need more people doing regular reviews And we need even more automation and we need clear documentation So the question is How many reviewers do we need? Minima one, but that's very long response times Currently we have three to four five around and Still long response time still very desperate applicants would be sustainable if we had at least six to ten people doing regular reviews It would be super awesome if ten people of you in here would start reviewing applications now and we would have a wonderful short response time and a very good reputation for new developers Yeah, now that was a bit negative Let's talk about some accomplishments and how we improve that process in a recent months and years First we have introduced automated review tools to the queue and that has really revolutionized the process The result of that is that we have almost no coding standard issues any more new Projects people are able to use correct git branch names. They have comments on every functions So the code is well documented the coding standard time place So the code that comes in from new contribute is contributors is really easy to read and understand and written in a Drupal way and Many details more that are detected by those automate automated review tools and the good thing about it If I go in in the issue queue and I'd be nitpicky about your module and I'd say Comma is missing here and the command is missing here People will take that personally and the good thing about Robots and automated review tools is that people just accept anything they tell them or they hate them a report Is coming out and they take it for granted and they fix it and there is no problem So that's really cool and we can focus in our reviews really on the function of the module and can provide feedback on that And we don't have to point out all those Tiny coding standard errors or whatever So the command was that the speed of the the review of the automated robot You can spit out a huge report at one time and not repeating those nitpicky comments all the time from from really human people Another question. I'll get to that on the next slide yeah So that the question was how that works out technically and we are using some programs that analyze the source code of new projects First there is the classic module coder You may be heard of it which uses regular expressions to find coding standard errors and security issues in Drupal modules Unfortunately, it has a lot of false positives that really confuse applicants and they fix things that are not false. So They are check planning They are sanitizing Text variables that are not user-supplied text. So it doesn't make sense to sanitize them Then a better approach is Drupal code sniffer, which we use a lot It is it uses a parser engine to analyze the source code and it reports Issues to that and it's based on PHP code sniffer where we can reuse existing rules and it's really convenient It works independent of Drupal so you can run it for example in your private git repository Automatically when you're pushing commits or whatever There's also the PA review shell script Which I wrote to do the basic git checks to to clone the project to analyze the source codes It's basically just a wrapper around Drupal code sniffer and coder and What Patrick did is really awesome He took that script to his server and published is on ventral.org where we can just submit git URL to a repository and we just Batch it and process the code and spit out a full report of what is going wrong with your code So that's really awesome and everybody can submit repository repository repository is there and get reports from that and fix them on their own So that is that So how do you avoid the long response times what I introduced is the review bonus system so the problem is the lack of reviewers and What I see is a possible solution is that applicants become reviewers because Let's be honest. They are just Drupal developers like you and me just that they don't have that much experience But they basically know what they're doing. They're familiar with Drupal so they can review other projects and the thing is they review three other project applications and they can add a special tag to their own application so that I know Aha, this person has helped other people So now it's on my high priority list to look at that code and to approve it and to move it forward So if you want to avoid long response times just help others and I'll be at your service There are some improvements planned to directly integrate on Drupal.org to nh the whole process itself First of all, we want to integrate the automated review service completely and Drupal.org so they don't have to go to an external site and submit it manually every time and We want to make sure that the workflow is followed so that if the issues created that's Automated review can Can be learned not less than six X errors and we see issues are also proved after a number of weeks and Jeremy already implemented some of this stuff in a sandbox, which is really cool, but can't be Pushed into Drupal.org live yet and We're really looking forward to this and we heard of many applicants that they are really waiting for This features to have on Drupal.org and to make it easier for them and for us There are several other ideas for improvements. Many of them also came from applicants themselves for example This one came from Clousey and he said let's make review bonus mandatory So if you want to get through the through the process you have to review three other applications Unfortunately, it turns out that many many applicants simply don't have time to do this and Therefore, it's not yet official There are issue queue free shorts Which means that we should? Not longer than four weeks wait for a project to be finished and We also think about having a really review team at the moment There's no real government and on this whole thing. It's just do you want to make reviews? Yes, then do it, but there's no real team that you can say hey These are the people who really regularly do the reviews likes in the documentation team where even leaders are defined then there's also often a problem that there are very specific applications like and commerce plug-ins and I Personally don't have very much. I Don't know very much about commerce and how to integrate with it. So the idea was to add tags to do to do applications that show people who Know something about commerce that this is the issue that they could look at so really experts and can do reviews on things that they know about Unfortunately, that's not really working out yet because simply experts are not looking into the application queue and Also often proposed was that we are separating the improvement of modules seems and features because seems and modules are Not really the same especially when it's about security and the correct API usage so it would be a solution to to Simply separate this to make sure that a seam developer don't create Secure a module with security issues one year later because you never You never was told how this works really So how could there be a mandatory Refuge bonus for new developers or if I submit for the first time how can I earn a Refuge bonus by Reviewing other modules because I'm new to that. How can I refue them? So it was recorded. So I don't have to repeat it There's extensive documentation on Drupal.org. There's the simple checklist that you can use to to check out other people's code It's not that hard. You just open the code files You can either look the look at them in your browser with the git repository browse on Drupal.org Or you can just clone the project take a look at the code and what you find is good And if you find nothing, it's totally okay to set it to rtbc which says I have not found any issues and this can move forward So nobody will will shout at you if you have not seen an issue for example that might turn out later But getting started with reviewing other applications definitely need some time You need some practice with it and you have to do it more often Lee But what's the cool thing about this is by reviewing other applications? You really learn many new things and It's simply if we demand from applicants that they need to review other modules We can make even sure that These applicants are really knowing what they're doing because they're showing it us and their reviews not a question so the question was that Mathematically if there are more reviews than application problem, we never had that problem. That's that's a very Esoteric discussion Yeah Yeah, we haven't we haven't decided anything about making required. We're just leaving it as is right now. Yeah so that's also a Another point about feedback and governance we've done some Surveys about how applicants think about the process and these are the Comments that they most often showed up with and Many said that often thought about giving up Are you say it's the review bonus bonus help me getting through within a week? Hey the long response times are very frustrating and We also very often heard that the process and is really good and I appreciate that Wow And if we ask them, what should be changed? Then we mostly had having more reviewers is essential for sustainable response times. Yeah, he also thinks this and More automation directly on triple org. Yeah Reviews should be less picky. Well, sorry that's often a problem and We are already trying to not be too picky on especially on coding style and But we simply have to be picky on security and API misuse it misuse it misusage issues. So bear with us and Sometimes we often heard that sometimes we often were sometimes we heard that the documentation should be more cohesive and less duplicating Meaning that many of the documentation is spread over several nodes and it's many duplicating information on them and it's a Mass of text to read for new applicants. So what they do nothing They don't read any of the document documentation simply create an application and and we wonder how this could happen and We really playing to work on this and we're looking forward to anyone who wants to help us Yeah, I don't think I thought that it shouldn't change at all Yeah, yeah, something a bit about review process governance well Who decides what we are doing in the queue and who decides what we are accepting and who decides how this work for should go Well, we all do we have a code review group. That's the name of the of a group on groups Don't triple org and we do discussions there and we do some decision-making there and this process that we currently have is Still evolving we're planning to do more automation. We are thinking about how we can enhance it to so that we have less Not that long response times and in the end we all work it out together how Drupal at org should work Often there are comments We should just enhance sandboxes so that they have downloadable release that would be enough for some applicants But on the other hand, we don't want that because the sandboxes are considered experimental and we don't want to mix that up so Yeah, we we can figure it out together and discuss how we should move forward. Yes, there's a question Yes Project needed process. So the the comment was that We might have a wish list of modules that do not exist But we might like to have and then new contributors can step in and fulfill the task and then it's it's as it is A desired feature it would go there. It would get the reviews sooner and it would be a better process Yes, that might be an idea. Yeah, but the question is who maintains that wish list and so on I think if so if somebody steps up and would like to do something like that It wouldn't be an issue. I think it would be very much appreciated Yeah So some next steps, of course, we are always recruiting So if you have five minutes of time ten minutes of time take a look at the project application issue queue And if you find something interesting if you see a module that or a theme that needs review Just take a look at the code If you and if you think it's sane and it does not violate anything that you have seen in Drupal doc marketers RGPC And we will really appreciate your help. It helps to keep this process going and We are finishing the Drupal dot Drupal dot org Drupal 7 migration So because we don't want to build tools for Drupal 6 right now We want to wait until this is on Drupal 7 so that we don't waste our time implementing something And we of course have to revisit our automation plans What rules exactly do we want to implement for the project application issue queue how it should work? We will have to make plans for that and then in the end We will implement that and publish that on Drupal dot org so that we don't need the External service for automated reviews that we have for example automated security issue review Yes, and so forth We also had a lot of thinking about how could we attract reviews and Some of the ideas we come up is that we do regular application review sprints China's on Friday. We are really We would really like to see any one of you there and join us to review a project applications It's not like hey, we take you and say now your review We really want to help you if you need an instruction how to review we we can show you We really want more people doing reviews. So if you are any interested then please come and ask It's really open The location will be on the just a usual code sprint on Friday. I don't know if it's here on the venue or somewhere else I think it's on it's on the Drupal con website Can just click on sprint and we will be there. Yeah, and We already said that we are encouraging applicants to review each other by the review bonus And we are also having now the the project review witness day. Where is once a week this These RSS feed from Drupal planets and we're Projects sitting in the application queue is promoted and said hey if you wanted to review it and We also thinking about a kind of application queue spotlight. So we can Show people who doing who are doing reviews regularly and say hey these people are awesome And we hope that by doing this more people want to get into this because they simply can make their self a name And they can get known by this So finally, let's come to the point sort of the stuff that you actually should remember about Key messages are Everyone of you can publish code directly sandbox projects are also a kind of contribution Because dump your code if you don't want to maintain it. Okay. Leave it in a sandbox. Please if you want to maintain it Come to us in the application queue then We need help really we need your help to review project applications and The third point is that review automation must be the future because if The count of reviewers Doesn't rise with the counts of applicants. We have a huge problem in the queue we have also my list of resources where you can They can join us and figure out how to review applications find out more more information about the issue queue itself and we also have Drupal review account on Twitter where we are always tweeting about the discussions and Under the newest projects going on in the application queue, so please follow it So you will remember that you want to help us So any questions left? Hi My name is Benjamin Melanson, and I actually also have the privilege of Promoting projects to forget projects So the extent that there's a problem, and I think there there still is one I am a large part of it Because I have been very absent involvement and actually even just check it doing handling the things that are already rtb seed I think we just have a fundamental Inequality that's sort of untenable in that we expect more from brand new Contributors of projects then we expect of people have projects. I have 10 projects or whatever. I have I'm clearly not maintaining them. Well, if I don't remember the exact number And you know I can pop off a project right that no review whatsoever I'm not you know one doesn't have to be up on the latest security APIs or anything to just do that But also I'm I'm invested in Drupal. I'm not gonna walk away if someone says well hold on like let's you know Look at your project a little more if someone just sits and gets nothing So that then that's really really bad first experience for people's like first big involvement I do think we have to be much clearer that your project is fully usable as a sandbox project and all of that It is a different regime But there's just that fundamental inequality that Personally I would love us to move towards a system where every project needed this some kind of process to become a full project And then we're all in the same boat together and all the module developers who and people who have The grandfathered access from like the days of CVS Who say oh no, I never want to go through this process. Well now they have to get involved and make it work for everybody That's considered untenable because that would What Drupal or some 10 times or more 20 times the number of projects that we have to review But honestly, I really feel that we have an inequality between new contributors and existing contributors That I'd rather see us thrown into a sinking boat together than just sort of have new people like waiver like this But there's been done an awesome job and so please everyone get involved in the queue And let's try to treat the new people as great as possible, but There's middle ground whereas the automated reviews can start to apply to All projects so these are the you know anything that can be done to make the Make it equal between existing contributors and new contributors. I think that's a huge step forward and Thanks, you're quite right about that inequality, but I think there's one aspect to it I think we have to be a bit more pushy to new contributors because there are there are the old foxes like you that are around and then Basically know what they're doing. They're not doing very very critical mistakes Of course, it's possible that an experienced Drupal developer will have a security issue in his or her module But it's less likely and I think we have to be a bit pushy and a bit nitpicky about new contributors because we do it only once We could change that and have this sinking boat. We are all thinking all modules have to go through the process but It's currently we don't have the resources for that so it's not quite sustainable We have we haven't figured that out, but on the other hand Maybe it attracts a lot of reviewers if every full project has to go through that application through that review More people would be in the queue and more people would maybe review. Maybe that would be better I guess the main other thing I would suggest as part of the the all equal approach is that did not be the The git Administrator able to approve proposition anymore But anyone else who has one or maybe three projects that already can is is automatically without any application able to approve other people's But that there'd be like a public record of that so that your name is attached to a project So that everyone has their reputation staked on The project they approve and it should still you know have a review process now But we again we remove this bottleneck that you know basically makes us the target of of the IRs like no This is how the Drupal community works You have a project to apply anybody with a project in Drupal can approve it And again, we have to have more people understand that anyone in Drupal can review your project so Putting more literature up front in the review application process that you know Drupal is done as a community Here's how you get involved in the community and get someone to review yours, of course doing your own reviews But all this is overlap, but if you know you just know that anyone in Drupal can do it It's up to you to to you know help make that happen I think that's teaching people how this project should work and that for someone who is an established Drupal developer It's not hard to find someone to sign off on their project that will go like that So I don't think it'd be onerous for established people and but it would actually be at least be technically equal I think that's a good comment actually I was just thinking that I'm not sure if all users on Drupal at org are on the same page for example regarding duplication and fragmentation So we have quite some applications that we just close and say hey, please talk to that maintainer that project already exists Please collaborate. Please do not create another few slideshow module. Please don't don't do it and and Yeah, that might be a problem because other users disagree to say The more modules the better the more contributors the better and they just would approve someone Which might not be desired by the overall community so Yeah But that's sort of the spot where the inequality calls people the most Because yeah, if you're already out there if you're once you get through the process with some other module Then you can release that review slideshow. So these Yeah, I mean, it's I honestly think that for things like that where there's no way like right now Anything that's a security issue or even API issues There's it's feasible that someone will go into a module You know, we'll go to into a module that's already out there and say no This one is shut down or whatever if it doesn't live up to it There's no way that's gonna happen the community's not gonna go and say tell me that I that The module I made is a duplicate and has to be shut down And so that is an inequality that we're facing new people to that I I think we just can't do that if we don't want duplicate projects Then we have to have a community wide thing We can't we can't put gates on new contributors that we don't even pretend to ever put on existing contributors And so we as a community want to prevent duplicate projects Then we have to we have to put that gate up separately But I think I think that's key and I think we have to drop that gate from the project review process We can we can encourage we can nudge But I don't think we can enforce it as an absolute gate because it's it's just not equal so What happens if I submit the project and you cannot Accept it because it has some issues. Do I have to reapply or what happens next? So the the issue Has a command follow-up. I Post the command and I say you have to fix this you have to fix that because that's a security issue And I put it as needs work then you work on your project commit the new code And then you say hey, I fixed that I'm ready to review again and set it back to needs review in a comment after that It's just that the standard issue queue workflow as we are using on other modules just a little Reused for project for applications any other questions Other useful comments Yeah, first of all, thanks for all the great work I think it's it's amazing what you guys pull off there. Thank you I think in general it's it's possible to get your project approved because I don't know if that comment was By me I think I got through in ten days or something like that But definitely being is a more centralized Documentation because at some point I read with the review bonus program that I'm shouldn't like Review one project a couple of times and then I thought well, that's Weird because I mean I already know the project then or the module and it would be better if I'll just stick to it and see okay does the Does the owner actually come back to the stuff that I suggested? Another post and I basically said that Also think it's all I was shocked by the amount of projects that were Committed where people were just lacking basic basic stuff like wrong get URL or They had 50 lines and they were like why is my project not being? being accepted or just basic checklist stuff and so I Would just go there and say well, please go to that link read it all and You can't say don't come back Five times I just wrote the same the same stuff. Okay, you're good. You're all should look like this Please take a look at that. Well, you're You have coding coding garland issues and so that's just the the stuff that might take a lot of work and the second point is that Maybe that can also be a different or two different levels because what I didn't really figure out in the beginning was that it's When I get into the bonus review program and then when I have that and when I flag it and then you take a look at my code and had I just have basic Stuff wrong and I kind of wasted three reviews. I'm evil No, no I got in touch with other Without the other applicants and said okay, I read with your project Can you just read your mind? Yeah to get the basic stuff covered and I in that way I also get the the reviews that I need for the bonus program Yeah, and then I can just tell you okay Can now take a look and I think that's a lot easier for you because I don't have to deal with the really basic stuff and so maybe it would be a good way to to promote that Kind of collaboration. Yeah a bit more to basically say, okay if you really want to Get things done get in touch with other people and work together review your stuff and Then do it in that way, but yeah Thanks, thanks Because of the documentation you mentioned We are also planning to work on a documentation on Friday. So we really want to Enhance the documentation. We want to talk about the future of the process. We also want to review some of the applications and Please please join us. We're really really looking forward to anyone who comes So we are not alone We will also we will also do some discussion about automation plan. So how we can tackle some of those issues and What you mentioned is I started to to build those automated review tools because I was repeating myself all the time And in the issue queue I found the very same issues in in In all the new project that have applied then I realized people were often using that the wrong permission in the menu callbacks And then I took a look at the example documentation for hook menu and the default what the default permission was Access administration pages which totally doesn't make sense for an administration configuration So if somebody can enter code just visit administration pages not enough It's the wrong permission and because it was in that example documentation people were using it a lot. So Overall documentation improvement for Drupal is also a great help for making new contributions better and More adhering to standards. Yes, so the comment was integrating the automation stuff into Drupal org would be a huge step I I agree. So I think you are running out of time So thanks all for coming. I hope I see you on Friday You have to do at least one one application or I will slap you. No, okay, just a joke It's on the general venue code sprint. I don't know what room that is right now It's on the Drupal con website. So hope to see you there. Thanks for coming