There is a lot of work involved in getting a module on drupal.org – its no walk in the park that’s for sure. I mean, it literally isn’t anything like a walk in the park – its going to be a lot more like sitting in front of a computer for hours. But that’s ok, chances are you were going to be doing that anyway. You probably hate the park.
Well, for good reason really – it serves as a kind of safeguard against a torrent of shitty code that would surely be submitted otherwise.
You see, once you have successfully contributed your first project, you obtain the Create Full Projects git permission and can post whatever projects you like. Going through the one-time approval process will ensure you are writing secure code, following the coding standards and generally following best practices.
Now before I hit you with the list I want to preface this by saying that I’m using the idea of contributing a module as an example, but the same basic rules apply to submitting any Drupal project.
Ok, so you’re gonna want to:
Now the module should be something you think other people will actually want to use and that doesn’t already exist. Drupal encourages collaboration over competition so if another similar module already exists it is better to try collaborate.
Ideally you want to add the module to your sandbox as soon as possible and make regular commits so that application reviewers can get an idea of your development and maintenance style.
Yep. Obviously you wanna test the crap out of your module. Literally test it until it isn’t crap. Use it as much as you can, and try and convince your friends to try it out too. You want to get your module into a state you consider to be release-ready.
PAReview is an online, automated test that will check your project for all sorts of errors. Pretty much everyone who reviews your module will be checking if it passes this test so you should preempt all of that by running it through here first. I also recommend running PAReview after every commit you make once your project is in the review queue.
Before you submit your module for review you will need to change to a version specific branch like 7.x-1.x and delete your master branch. Check out Moving from a master branch to a version branch.
People will begin to review your module and if there is anything that needs to be fixed they will explain what and change the status to Needs Work. You should try fix these bugs as soon as you can and commit your changes, I would also recommend running PAReview again too.
When you feel satisfied with your changes you can change the status back to Needs Review, leaving a comment explaining what you have changed. Eventually, when someone reviews the project and concludes that there are no bugs they will change the status to Reviewed & tested by the community.
Unless you want to wait for months for your module to be approved, you should participate in the bonus review scheme.
You will need to find at least 3 applications on the application queue to review. This will likely mean checking the queue quite often to find a module you feel you can adequately review.
Once you have reviewed enough projects you need to edit your own application and link to the reviews you have done and then tag your application with the ‘PAReview: review bonus’ tag.
It’s pretty much just playing the waiting game after that. If your module is up to scratch it shouldn’t take too long to be approved, mine took something like 2 or 3 days.