 Meaning when you can just post one comment per hour, don't be worried, it's a measurement on Drupal.org to avoid spam, so yeah, the system automatically detects if your account is older, then you will have no problem. I don't know, so you can't, if you try to post many comments within one minute, like you're looking like a bot, then Drupal.org will, I'm not sure how it works. There's some spammer role that you then get or that you lose at some point, it's I'm not sure how it works exactly, it's a bit of a secret. So the spammers don't know how it works on Drupal.org, but yeah. Of course, Drupal.org is a popular website, so people want to publish their content there because it's good for their SEO ranking or whatever. Which also means anything that you do for your Drupal company on Drupal.org gives your company and yourself more visibility, so really, the first thing when you start out with Drupal is just created account and yeah, the first step. So this session will also be a little bit developer centric, so yeah. I will show you that the tools that you need as a developer to get something up and running on Drupal.org, maybe in two minutes. We have to wait a bit until the people arrive and until the recording is ready. Are we ready for recording? So we wait two more minutes to let some more people in and then I'm going to start. If you have any questions at any point, just feel free to ask me. Just raise your hand and I'm going to repeat the question to the microphone so that it's in the recording. We also have some microphones here checking if they work. Do you have a question, sir? What's the best so far with Mumbai? I think the food. So food is good. I'm a vegetarian, so I live in Austria and the options there are limited. So it's nice to go to an Asian place because they have lots of veggie food. I like that. Okay, I think I'm going to start now so that we don't lose a lot of time. Hello, everybody. Welcome to my session. This will be about publishing a module on Drupal.org. So I'm assuming you're a developer and you have some kind of code and you want to start to contribute and want to share something with the community. My name is Klaus Burra or Klausie on Drupal.org. I'm a software engineer at Epico. It's a small company in Austria in Europe. We're working on job boards, which means we're using Drupal and sell them as job boards where companies can post their company profiles and post jobs and applicants can apply for jobs. That's basically our business. On Drupal.org, I'm a project application review administrator, which means there's a group of people that look at new contributors, what kind of code they provide, and we review that code. I'm also a member of the Drupal security team. So when security releases come out, we coordinate with all the maintainers on Drupal.org to get that out. I'm currently working on the rules project. This is a contributed module for Drupal 8. And I'm also a maintainer of the rest module in Drupal 8. Core. And then I also work on coding standards for Drupal. So there's the Coder project, which can automatically review your code for coding standards errors. I will also talk about that a little bit later. So much about me. So one important aspect I want to talk a little bit about is contribution. So we should all thank each other more that we contribute much, that we offer our code to be shared amongst each other, because no one person alone could program all the code that has been developed for Drupal on their own. So we all live of each other's contributions. So this is the most important aspect of the Drupal community, is that we all provide contributions. And this makes this huge pile of magic where you can build actual websites and get stuff done. So I also want to thank you to you all for your future contributions. This is important for the Drupal community, as I said. And this is always the thing that we should focus on when we work together, that we appreciate each other's contribution, and that we make them useful, and that we make them most out of it. So before you start to publish a module, there are some questions that you should ask yourself. One aspect is duplication. Most of the time when you want to publish code, there is something similar probably already out there. So the first thing in order is to do a web search, do a Google search, or do a search on drupal.org. Does a module like that already exist? Can I work with the maintainers that are already there? Can I contribute my code there? Because if we create many similar modules on drupal.org, then it means that it's much, much harder for the users, and we all are users. I'm also searching for modules on drupal.org to find the right thing. If there are 10 modules doing the same thing, and they only have one maintainer, and they're not working together, then that's really bad, because I have no idea which module I should choose. So this plays into the drupal community ethos of joint forces, which means we always emphasize collaboration over competition. In this community, you are not alone. There are always like-minded people, people trying to accomplish the same task, so you should really work together instead of competing, and then make one module which is better than two separate modules that do kind of the same things, but are not really finished, so it's always better to combine that force. Then there's also the aspect of utility. When you program a custom module for your site, it might be very specific to that use case of a site. Then that means it might not be that useful if you publish it as a project on drupal.org, because it should be in some way generic that you could use it on any drupal site for a certain use case. For example, if you have the organic groups module, it's quite generic. It doesn't tell you that this is made for a news site or this is made for a job board site. It's just grouping content together and providing a use case. That's also an important aspect of the drupal community that every module is programmed in a very flexible way and can be used for many things. And also there's the aspect of dedication. It should be, publishing a module is not a one-off shot that you just do once and then forget about it. You should also think about how I'm going to maintain this, how, what happens if there's a security issue, then you have to work together with a security team to create a new release. So you should also think about how you can support this in a long-term, be a responsible maintainer. So the first thing that we have in drupal.org are so-called sandboxes. These are project pages that have a sandbox URL. So it clearly says in the URL that this is a sandbox from the user Clousey and it has just the number. And it also has this experimental warning meaning that there is code in there that hasn't been reviewed, that hasn't been tested. It's probably not meant for production use. It's just something a person put out there. And the most important aspect is everybody that has a drupal.org account and has agreed to the terms and condition and I think there's also a Git repository policy can create such a sandbox. So you create your account in drupal.org and this is where you start. With the sandbox, everybody can push their code. The only thing you need to know is Git. I will talk a little bit about that later. So a sandbox has this project page and it also has a Git repository and the Git repository contains the actual code. And the project page is meant to describe the sandbox, what kind of code is in there. As we can see, there are no releases. Releases are only for full projects and that's basically all there is to a sandbox. On the other hand, there's another kind of project on drupal.org. These are called full project. So what you can see here, they have a full namespace URL, which means you always have the slash project prefix and then a short name for the project. In rules is just rules. Something there's an underscore in there. You probably have seen this pattern a lot. And the biggest differences to sandboxes, of course, they don't have an experimental warning and they have tag releases. So you have some branches in Git and then you create tags and can make releases out of them. And all projects on drupal.org that have stable releases like that, they are also supported by the Drupal security team. So when a security issue comes up, the security team works together with the maintainers to get a new release out and create a so-called security advisory telling people that they should update and what the problem was and how it was fixed. So that's the biggest thing. Not everybody can create full project. This is only user accounts that have been reviewed can do this and I will talk about this review process. But there's also the possibility of abandon project. So there are quite a lot, quite a few, a lot, I don't know how to say that correctly there. Some un-maintained project on drupal.org. So as I already said in the beginning, when I talked about duplication, instead of publishing something new or instead of publishing a fork, you should work together with the un-maintain project to just contact the maintainer and if they don't respond, then you just open an issue in the drupal.org webmaster queue and you say, hey, I would like to take over this project. Here is some code that I've written, this should be replaced and then the webmasters will transfer the ownership of this full project to you. So you can now work in this project and people should do that more often. They should work together. Sometimes the maintainer just say, yeah, sure, you can work with a project. It's not a problem and we should do this more often. So instead of creating another project, really do that. For example, you shouldn't create this plus project or a better project. So don't create a project like better comments or coder plus or I don't know, comments double plus improved now really. You shouldn't really do that. Work together with the projects that already exist and improve them. Also, there are existing users of this full project. So when there is new code out there, they are going to test it and they will give you feedback. You have a much higher visibility to do that. As I already said, if you cannot contact the maintainer, if they don't respond, you can go to the webmasters and they will transfer the ownership to you. So there's a link in there where you can get the instructions exactly how to do that. And these slides are also up at the Drupalcon website now so you can open the presentation from the website and click through the slides and then you can click on the links if you want to look this up. As I already mentioned, every sandbox, every full project has a Git repository attached to it. So for every Drupal developer, it's very important to learn the basics in Git because every maintainer, everybody that pushes code to Drupal.org has to know Git to some degree. You can either use Git from the command line, you can use it in your IDE. For example, in PHPStorm or in NetBeans, you just use it somehow. And why do we use Git? It tracks the changes that you make to your project. So you make an amount of so-called commits which means there are change sets to your code and then you tag a release at a certain point. And later you find a bug, you fix that and you might fix another bug and then you create a new tag and this is then going to be the next release. Every project on Drupal.org has a version control tab and there you can find the Git clone command. It's actually very similar to other systems like GitHub that you know, every project page that you see has an associated Git repository and you find a clone command there and how you give you the instruction how to get the code. Branch names in Drupal we usually call after the major version of Drupal that the code is written against. So this would be an example for Drupal 8 code. You call it 8.x minus the branch of the project 1.x and the tag would then look like this. My module is somehow ready so I tag it with 8.x 1.0 but it's the first beta, it's not a full release yet. And the documentation how to use Git is actually quite good on Drupal.org. I also recommend you to look up that. It's an essential tool that you should use for the project that you publish on Drupal.org but it's also nice to use Git for your client projects. It's really an essential tool for any Drupal developer. Another thing that you consider before you publish your module is to follow the coding standards. This is important because other people are going to look at your code, contributors, clients, people that want to do a security review of the code. They want to look at it because Drupal is of course open source so people are going to read your code and they need to understand it. This is why I have come together to set a certain set of standards and formalities. So for example around whitespace and indentation how code should look like because if we all use the same patterns for our code then it's much easier to look at another module and then immediately realizing what is going on there and what the module does. There are also naming conventions, how you should name your functions, for example in Drupal every function that you write for Drupal 7 module for example needs to start with your module name. That's why for example in the rules module every function will start with rules lowercase. So these are some conventions that we follow. We also have lots of coding standards for inland documentation. So when you write code you should leave comments. You should leave a short comment what the function does. You should give clear names to your variables and all of this is documented on drupal.org in the coding standards document. So in order to follow that there are automated tools that you can use. There is the Coder project which uses PHP code sniffer. This is a command line tool that you can execute. So what I'm doing here is just invoking the PHP CS command with the Drupal standard on some example module and then it will list out all the coding standards problems that it finds. For example there's a function documentation missing or the opening brace is not on the correct line. It will also give you a hint which of those errors it can fix automatically. So Coder and PHP code sniffer come with a second command which automatically can fix your coding standards. This is really nice if you have some old legacy code and it's really not written. It's hard to read because it uses tabs instead of spaces and you can just run this PHP code beautifier over it and it will at least fix that so the code is much more readable. This all is in the Coder project on drupal.org so I recommend you to check that out. The same thing we have for JavaScript. This is done with ESLint. This is a node package. So for most front-end developers it might, it's probably not a problem to install another node package because they're probably using some SAS pre-processing for the CSS anyway and there are instructions how to install ESLint and it works pretty much the same in Coder. It will just review your JavaScript file and then give you hints what you can improve in your code. Drupal 8 already ships with such an ESLint RC config file which specifies in JavaScript files you should use two space indentation, other stuff that should be done and on ESLint.org you find instructions how to install it and how to run it. So these are essential tools that you can run to automatically check your code. They will give you some important hints. And all of this has also been put together on a website called pa-review.sh. So I wrote the original pa-review.sh bash script which uses Coder and uses ESLint and some other review tools that you can execute locally and then Patrick from Germany put it up on a website called pa-review.sh and what you do there you just give it the GitRepose URL of your project and then hit the submit button and then it will download the module and check it and give you a nice report what coding standards problem there are in your project. So in the project application review process where we look at your code we use this a lot to automatically review code. Another important thing to consider when you publish code in Drupal.org is licensing. So we want to prevent the Drupal association to get into legal trouble and since Drupal is open source and it's licensed under the GPL version two all code that is pushed to the GitRepose.org on Drupal.org is automatically GPL version two which means you need to be careful if you have third-party libraries that you are using them in your module because you are not allowed to push them in the GitRepose.org is that you should tell users where to download them. One example you are using for example the Amazon web services SDK for PHP in your module then don't include it in the GitRepose.org and just tell users here's the module and then you download the Amazon PHP library and put it in this place and then it will work. So you can also use for Drupal 7 the libraries API module to include third-party code in Drupal 8 it's more and more the use of Composer if you're referring to PHP libraries but I think the libraries API still exists for JavaScript libraries that you include in your Drupal code. Yes, so it's also important if you develop a theme for example if there are font files or icons, images make sure that you have the right to publish them on Drupal.org because as I said everything that goes in there needs to be GPL version two cannot be anything else and this is important if it violates the licensing then you need to remove it. This is also something that we review when we review applicants that apply for full projects. So I think this is the most important aspect when we think about new project that people put up security. So of course if you publish a module it shouldn't make the website it is running on less secure than it was before. So always when you develop code always work with it in a security mindset make sure that the data is protected make sure that the configuration that can be done with the module is protected in a way that it cannot be abused or anything else. And security is also the reason why we don't just allow everybody to publish full projects on Drupal.org because we have the security team and the security team wants to support all stable releases of any contributed module but they can only do that if we know to a certain degree that the people know what they are doing. So we need to check the code somehow. We need to approve users that we trust them and yeah that's a very important part when we do project application reviews. As I already said your code that you publish shouldn't be a threat. That's why you should security review your own code yourself but it's also a good idea to ask somebody else to do it for you. And in this process you should get a little bit creative so think about it. How could an attacker abuse your module? What could they do with it? Could they run their own JavaScript? Is there a cross-site scripting vulnerability somewhere? What weaknesses does your code contain? Is every path that you have implemented protected with a certain permission? Is the code that you have written ready for a production side or is it still very much experimental? And Ask yourself also are you familiar with the security concepts in Drupal? So there are certain vulnerabilities that you can easily run into and we have some good documentation on Drupal.org to write secure code. This is mostly written for Drupal 7 but many of the concepts also apply to Drupal 8. Just to give you an overview what kind of security vulnerabilities do we find in Drupal Contrib and more than a half is cross-site scripting vulnerabilities. And I will talk a little bit about that. It's basically attackers injecting their own JavaScript into your website and thereby they can exploit admin access, for example. But there are also other kinds of vulnerabilities like access pipers. You forgot to check for a permission somewhere or you forgot to protect a path or you forgot to implement the node access tag when you show a list of nodes. This can easily happen so there are also quite a few access pipers vulnerabilities. And there are also others like cross-site request for tree and SQL injection. They make a smaller percentage of the vulnerabilities but of course they are also very bad. I think that the most that has the highest impact is SQL injection. If you have that in a model it's really bad because then an attacker can easily modify data that is in your database which is really bad. And there are also other kinds of security vulnerabilities in this last piece. So let's look a bit at cross-site scripting. What is this? Many develop a module and your module might produce HTML output and it might access user provided variables. So in this example, we have a reflected cross-site scripting example. Let's assume you have a simple PHP script, not even Drupal. It's just a simple PHP script and you're outputting something from the URL and number. Do you think this is secure? What could go wrong here? And if you think about it, anything an attacker can basically pass anything in that number and when you print it like that an attacker passes script tags like here, they can execute JavaScript on the HTML page. So whenever the page is being printed to an administrator, for example, then the JavaScript is executed. So what would I do as an attacker? I would send you, you are the admin of the Drupal site, I will send you a link with a special number parameter in it and when you click that link, PHP process that, prints that out and then in your browser the script is executed and that script might, so in this example it just pops up and alert which is pretty, that's not really harmful but it could also load some JavaScript code from my homepage for example and then execute it as you as the administrator and for example create a new user account or give some other user an additional role. So cross-site scripting can be really dangerous and you should be aware of that. And in Drupal 7, in 7 the general rule is use it always sanitize user provided text. The user provided text can come in many forms as a parameter in the URL or it can be a note title. It basically can be anything that is in your database. It can be user provided so it's not trusted. So when you print something to HTML we need to make sure that it's not JavaScript that is sanitized properly. In Drupal 8 we use that tweak rendering engine and it has auto escaping built-in which is really, really helpful. So I hope that we can bring down the cross-site scripting vulnerabilities for Drupal 8 quite a lot. Yep. But there is also cross-site request forgery. I just show you some vulnerabilities and how they can be exploited. So to give you a feeling what can possibly go wrong with your code. So cross-site request forgery means an attacker can change data without verifying the intent. Let's look at this HTML example. So we have an image tag here and usually you would find that the source attribute you would find some kind of image. So as an attacker what I have done here I have put in a URL to your Drupal site in there. Let's say example.com is your Drupal site. And let's say there are a quick delete module has been enabled there and it exposes that path. So what happens if you as an admin go there and you have access to the quick delete path and you go to the attacker's page and the image is rendered. What the browser will do it will try to fetch this URL and if there is no CSIF protection then Drupal will just execute the code and quickly delete the node in this example. So what we have to do here is either use confirmation forms. The form API in Drupal 7 and 8 and all versions has CSIF protection built in. So it means when a user goes to that path they have to click an additional button so nothing gets deleted by default. Or we use per user tokens in the URL. So sometimes it's nice to have quick links to delete something but then we need to do it like this here at the bottom we have an additional security token this is different per user so an attacker cannot guess this token and the link will be secured and can only be executed from HTML that has been printed for your user and not on some completely different site or whatever. So these are all things that you have to think about when you take security into consideration when publishing a code. And do you see the pattern here? What happens? We need to be very, very careful about user-provided data that comes into Drupal. It can be in a URL, it can be in a request, it can be in a body of the request, it can be in the content of the database. Because as the golden rule in Drupal you always store what the user typed exactly. So if they put in a script text for example in the node body okay that's fine you store the script text in the database in the field but when you render it to HTML you make sure that it is then sanitized appropriately. That's why we never trust data that is in the database because it could be potentially be from someone that we don't trust. And what attackers try to exploit is missing a weak access control so make sure that your permission setup is configured correctly. And what we saw here when I explained to you cross-site scripting and cross-site request forgery is that this browser features to perform actions behind the user's back. So when we saw the image earlier that the browser doesn't ask you should I fetch this image now? No, it just executes it, it just fetches that path and if it's an image then it can display it but otherwise it just will execute a request and whatever happens on a server happens. Same with cross-site scripting the browser will not ask you should I really execute this JavaScript that is here? It looks a bit suspicious. No, the browser whatever JavaScript text it finds in the HTML it would just execute it. And if an attacker manages to inject JavaScript into your HTML, the browser will just execute it. They won't ask for your permission. So that's important that we always keep this everything that is provided by the user even by admins, by editors, by anybody is not trusted and we need to make sure that it's sanitized when we deal with it. Okay, now let's talk a little bit about workflow how does this now work on Drupal.org the review process? How can you actually put up your code? And there is this review checklist. A lot of these points I have already mentioned. So the review checklist is something that you go through as an applicant but then also reviewers that look at the code will go through the same thing. So they make sure there's no duplication that the module doesn't exist. They check for security and licensing those are the most important parts but they also take a look, is there documentation? Is it obvious to users how this module can be used? Does it follow the coding standards? Is the code usable? How is the API usage? Are they abusing something? Is there maybe an SQL injection or some other weakness that could be exploited? And there's also a link in there which explains the lists which gives you a point for point checklist that you can just go through and make sure that the code follows that. Then there is the project application queue. So on Drupal.org we use the so-called issue queues. Every project has an issue queue like Drupal core has one, the big modules have one, every module has one. And there's a special project called project applications. So this is not really a project it's just a meta queue which is used to track applicants. So what you do, you go there and you open an issue and you give it the name of the module. For example, I want to publish the rules module and you apply it for permissions to create full projects with that because when you start your code is in a sandbox and now you want to push it up to a full project to have a nice name or to have releases. So you create your application issue there. It's just a usual issue queue and then other people will review your code. And in the end, when everything works out you will get approved. So how is the workflow? You open the applications needs to view which means somebody else should look at it and they will then check out the code. They will go through the review checklist that we have seen before and if they find a major problem for example, they find a security issue, they tell you, hey, here's a cross-site scripting vulnerability, you should fix that before you publish that. Then the issue is set to needs work which means now it's your turn to fix this problem and when you've done that you set it back to needs review. So this is the standard issue queue workflow that you might already know from Drupal Core when we develop patches, it's pretty similar and the same thing we're using here to approve applicants to review them and then to approve them. And in the end a reviewer says, okay, I don't see any problems anymore with this. Then they set it to review and test it to the community. So which means in their opinion everything is ready and this can now be approved by a good department. And then a Git administrator, this is a group of people on Drupal.org, they approve the application and set it to fixed. So what then happens is the user gets the so-called Git vetted user on Drupal.org so they have some elevated permissions and they can now create full projects. They can still create sandboxes so nothing changes there but once their sandboxes are ready they can promote them to full projects. And they cannot only do that for one project but they can do it for any project in the future. So this is a one-time approval process. You only do this once. You apply with one sandbox and when that's approved then we trust you which means we trust that all future projects that you create will be secure and good as well and then you can publish them on your own. No review process after that. Of course this is not without problems. So there are certain things that are not nice about this review process. If you compare it with GitHub for example, anybody can publish anything on GitHub that's also why you should be really careful if you download something from GitHub because you don't know what are the skills of that person. Did they actually, is this a known person that knows what they are doing or is this just some experimental code? Yeah, it's hard to tell. On Drupal.org if it's a full project and a chance that it has been created by a user that knows what they are doing is really high and if it's a sandbox then there's a clear distinction this is experimental. So whatever code you download from Drupal.org you're thinking about do I need to review this? By how many people is this used? With the most popular modules like the views module or I don't know the rules module they have been downloaded and used so many times so the chances are good that this is trusted code but if you download something which has only one user might think about maybe I should look at the code myself to make sure it actually does what it says. Yeah, but back to the problems that we have. One thing is that we're always running out of reviewers so at some point you might get really angry in the HQ you created your application and it takes really a long time nobody's looking at your code. Some applicants wait even for months and they don't get feedback fast enough. The problem is that we don't have enough reviewers so this takes some time. These are all volunteers that work in the Drupal community nobody gets paid for that and that's why it may take some time. So what people also might perceive as unfair is this one-time approval process so once you have the role you don't need to get reviewed again so people might think this is really unfair once the people are approved they can basically do anything on Drupal.org but I have to wait here and I cannot publish further modules so people get really annoyed. Some people are also angry that they only get superficial feedback people are pointing out the coding standards errors they make but they don't review the actual functionality of the module. So when you provide feedback for a module make sure that you point out yes this module worked for me I think this use case should work like this or this is good so you should really tell the people about the functionality of the module not only point out coding standard errors. This is something we have to constantly work on as reviewers so that we give the applicants a good experience when they publish their module. After all it's a contribution and as I already said this is something very valuable so we should be careful how we treat the applicants. Some consideration why are we doing this at all so we could also say why just can't everybody publish project? But there is the problem of spam I already mentioned this in the beginning so there could be some namespace quoting by random users they sign up for an account then reserve many namespaces and then the webmasters have to go in and revert that give the namespace back so this could really increase the workload so that's why we have the process to make this a barrier to spam but also we have the security team as I already mentioned and they want to support all of all contributed modules that are out there just have a stable release so the security team makes one important distinction this is between stable releases and non-stable releases unstable releases is a beta and alpha version of a module so the security team does not release advisories for that but if it's a 1.0 or 1.1 or 2.0 then this is considered to be supported by a security lease and they will work together with the maintainers to fix security issues in case they come up also Drupal has a certain reputation so most of the code that we have in Drupal.org is actually quite good and most of the contributed modules are also quite good they are used on many, many sites this is something to be very proud of of the Drupal community so of course we want to preserve this quality level of contributed modules that's also why we consider having this process and also encourage collaboration over competition this is forced into the duplication month that don't publish your module without checking ever what the community provides so make sure that you don't duplicate stuff these are all reasons why we have the current projects but yeah so what can you do to speed up your application? our problem is that we are lacking reviewers so my idea a couple of years ago is that applicants become reviewers themselves so what you do is you review other applications so there are other applicants out there they publish interesting modules you just look at them and you review them according to our checklist and then you say yes this module works or no this module has this and this problem and after you have done this for three projects you give your own issue attack PA review review bonus so which means then you show up on a high priority list where I for example as a Git administrator will look first when I'm reviewing applications I always go to this tag because I don't have time to review everything so I need to prioritize and of course I want to help people that help others so this is my high priority list where I review applications and it's also a good experience you can learn really a lot by reviewing but what you can also do is community networking so as already said as community we should work together so when you want to publish code it's important to make connections to other Drupalistas in your area or worldwide there are many channels that you can use you can ask colleagues at your company to review your code then you can improve the quality so you can even work together with them on Drupal.org you publish the module your colleague reviews it and sets it to RTPC this is totally fine it's just a second pair of eyes that makes sure that the code is good or you can it doesn't have to be colleagues it can be friends it can be other community members you can go to local meetups make connections there you can go to user groups but there's also on the internet IRC we use the internet relay chat protocol so there are certain channels where the Drupal community meets online you can also go there and try to find people that want to work with you there's also Drupal answers on Stack Exchange where people ask questions and your module might be the perfect answer to a question so it also makes sense to post it there and the important thing is just to get visibility to your sandbox and then more people will review it and you will get approved faster it's also always good to communicate about your project so maybe write a blog post about it and post it on social media just get the word out so that people know that you are working on this and want to promote this and it also helps to contribute and make yourself known so in the Drupal community you will just be known and people will trust you we're starting to trust you we want to work with you so this is a very good process everybody should really do community networking because we shouldn't work on our own we should work together we're all using each other's code so it's important to work together what are the benefits of reviewing? you might want to help another applicant so what is in there for you? so what you can really learn you learn Drupal by reviewing code you see what other people are doing with Drupal it's the same as if you look into the source code of Drupal Core you see it's done like this this is very interesting now I know how it works the same with other projects if you review them you can maybe point out even mistakes you can say usually in Drupal we do it this way but it has a problem you learn about alternative ways people are very creative so when they publish new modules they have a really interesting idea how they are doing things and you can learn really a lot for that and to learn how to analyze for a code you learn how to review code which also comes in handy if you are having a Drupal job and you would like to review code from your colleague then it helps if you are already familiar with that you also learn how to write secure code because if you look at the application list you will see people pointing out security issues and then as another review you will see I haven't thought about that that's a good point you learn about best and worst practices you learn what people do right and what they do wrong and how it could be avoided so whenever you write the next module it helps you to do it right you also stay on top of what is new and hot which means there are a lot of interesting new projects posted for certain use cases that are coming up for web trends for example any new third party services that might pull up so a lot of interesting things in the queue you basically see what people are working on and it also helps your own Drupal career if you think about it most of us are professional Drupal developer but maybe you haven't started with Drupal yet so this is a good opportunity to review other people code engage with the community and maybe then land the Drupal job I always recommend that to people so I'm new to Drupal I want to work with it and I don't have a Drupal job yet this is the perfect opportunity to work with other people and help mentoring and being mentored and then it's easy to actually get a job in Drupal so how can we improve this on Drupal or overall there are some plans that people are working on and of course we want to make the experience better for the applicants so currently they have to wait a lot it takes time until they are reviewed and what can we do about this the plans are that we integrate the automated reviews into Drupal.org itself so we saw the PA review website earlier this is an external site it's not that nice it would be actually cool to have a code review tab on every project on sandboxes and full projects so that you can go there and see a report Coder has been executed on this and these are the problems I can just fix it here and the plan is also to give every non-git vetted user the rights to promote one sandbox so you push a code to a sandbox and then you can immediately turn it into a full project but you can only do that for one sandbox until you're not approved yet so the goal is to bring people up to speed sooner so that they can get code out sooner with full projects and releases although they cannot create stable releases so that they can push out the first beta or the first alpha version of a module and people can already download that and they have the visibility and people know about it and they have a better experience so there's no, as I already said there's no security team support for unstable releases so for the security team there wouldn't be changing much you would have your beta release out there and then you would go through the approval process after that so instead of giving a sandbox for review or providing a full project for review and then people would just review that otherwise the process is the same so you get reviewed once and once you got that you can publish as many modules as you want it basically means we trust you now so there's also an issue to track this on Drupal.org where people are currently working on it as I said this is just a plan it hasn't been implemented yet so there is a community initiative on Drupal.org to make this happen and basically we just need to implement permissions so the users can publish this one sandbox and then get started sooner there are a couple of sub-issues in there so they specifically list what tasks need to be done and Jeremy Thorsten is leading that effort I think he also created that issue so if you want to help with that if you want to implement something for Drupal.org that's also the place to get started yes and getting involved overall is a good idea anyway so there's a group of reviewers on groups.drupal.org that do code review and a project application issue queue and those are not only Git administrators but those are regular reviewers that post their stuff there one interesting thing that you can also do if you become a little bit experienced in Drupal you can become a Git admin yourself so the process is not really difficult as soon as you are a regular reviewer we would just get in contact with you and if we see that you do good work if you bonus points if you find security issues in projects on Drupal.org this person really knows how to review code they should be a Git admin themselves and then they can approve users so this is just a list of people that do that and they always want to put in new people so just talk to me if you want to get involved with that as we already talked about Drupal.org plans there are many tasks now that people can help work on and there's also another way to get involved that are the code sprints on Sunday so people will gather work here at this event at DrupalCon on Drupal Core they work on contributed projects they work on documentation, all kinds of things so you don't just you don't have to get involved with code reviewing but there are many, many, many topics in Drupal you can get involved I'm active in code review so I'm also happy to help you out getting involved there so I think that's it for now I made it a bit quicker any questions? yes we have about 8 minutes time for questions anyone? so here's a microphone if the question is short I just repeat it I was guessing that it's on I was guessing that can Drupal review process can be used with the help of platform message with the help of what? platform platform I don't know black form platform.sh oh the hosting company yeah it has a very good review process I see, no I don't know about that it would be interesting so what do they review? just like peer reviews anybody can review any code like that can we implement that? I think it's already implemented at pareview.sh and there are now plans to integrate the automated review that coder does so that's one sub-task of the plans that I've been talking to do that I assume that platform.sh does the same thing is that peer review compatible with some other repositories as well or it only works with Git? no it only works with Git at this point in time everybody should be working with Git everything else is a waste of time that's true but I mean everyone don't use the Git yes if you're still using subversion for example or mercurial or anything else you should really learn Git because it's a tool that is going to be used everywhere on drupal.org and also on other projects I highly recommend that sorry anyone else? so the matrix like number of installs and downloads most of my projects are like long term projects and I usually disable update manager so that the code stays stable it might break with the new version so is there a plan to have a flag or something which I can just go in and say that this project works for me because if it is not working I can easily go in and create an issue but if it is working to have a matrix like this is working no it's a good idea I think people have talked about this very often on drupal.org that there should be some R rating system or some feedback for users or just a flag so that people can indicate this is working for me or not but currently it's not implemented yet I don't know what the current plans for that are I think it's on hold so what you can just look at is the amount of installs basically if many people have this module installed the chances that it's actually working is high but of course it always depends on your use case from the site I could have an instance yes it's still a good indication because you would have to spin up many instances to just to create false data yes then it will count five times like project URL or project name yeah could be possible so that becomes more of better matrix because if I'm trying to enter the site name there are five developers they are trying to enter the site name twice it says that okay that project has already been added in the list yeah would be an idea any more questions here is one this is regarding github you have gith can we have the sandbox on github in github there is no distinction because on github everything is prefixed with the username or the organization you are working for so on drupal.org it's slash project slash name on github it's slash your username or slash organization and then slash the project name so on github there is no distinction that's why I said be careful with the code from github because you don't know how many people are using that how secure is this there is no indication on drupal.org you at least know this is in a sandbox so people mean that this is experimental code if it's in a full project the chances that it's actually stable is higher okay then there's another question see so we want to have two separate things is it possible there's a way to move code from github to this yes it's totally easy so what you just do with your local git repository you just add another remote you clone from github then the remote origin is github then you can add another remote you call it drupal.org and give it the correct URL you find it on the version control tab of your project and then you say git push to the other remote and then it just pushes all your commits and then it's just a complete mirror it's the same it's the mirror of the code in github so what we do in the rules project we have a mirror on github so we're using pull requests to work on rules but the code is also synced to drupal.org so that's a recommended way it's some one way to do it so the most important stuff is that the code is on drupal.org because that's where you create the releases if you have it on github or not it's your choice so because you know you'll find a lot of users and developers on github so if you have an active project you could actually have it on the side the git of drupal or would you recommend the other way around where you have an active project inside because the collaboration would happen more freely on github I'm just guessing you know probably it depends on the drupal community is mostly on drupal.org because the issue queue is much better than on github so in github you cannot say something too needs work only the maintainer of the project can do this so there's no workflow if you imagine drupal code is 30,000 open issues if it would have done on github people would go crazy drupal.org you have better filters that's why people use drupal.org because the issue queue github is so limited so I think we have to stop let me check yeah one more question excuse me I have a question I didn't get the point that you have described benefit of reviewing actually there's a point that learn how to analyze foreign code I didn't get this point actually it means if you look at other people's code often it means you develop a skill to analyze foreign code, foreign means not your own so if you look at another project it's not your own code and you do that very often you see people do it like this that person did it like that you can compare it in your mind how people do things so it's the kind of practice you get and it also helps if with your own programming skills if you have seen many approaches how people do things it helps to improve yourself that's what I meant with that thank you I'll be out for more questions thank you