Contributing Code to Drupal.org Mini Projects
I had a chance to work on some Drupal 7 upgrades in Drupal.org projects. I'm not contributing in the Drupal core but on the open source distributions and modules. Some people may be inclined to join in any effort but they don’t know how to get started.
Here is my experience on this and I hope to see more people join on these projects. First steps are not always easy so I hope this post helps.
Step 1: Find a project to work on.
I think that finding a project that needs help that I’d be interested in is more like a lucky draw. I don’t really like reading issue queues in drupal.org. I just usually stumble on these help pages and if it sounds right and there is a good instruction on how to help, I’ll join.
I do think that some projects lack the “How to Help” guide in their pages. They ask for help but never tell you how to get started. As far as my experience goes, different projects have different ways on how they handle their team. And asking people to go to IIRC doesn’t help much either. I’m 12 hours ahead in Pacific Time and most people are not in IIRC when I am online. Unless you don’t want people to help from the other side of the world, then please scratch out the IIRC (not totally, just give another option).
If there is a Help guide, you’re lucky! But if there is none, it will take a little more effort from you so dedication is a must. Try to contact the project team leader or project started. They would most likely help you get around easily. And I’ll say that with 99.99% assurance.
Step 2: Get your local environment up.
In some projects, you can ask for a dev environment out of the drupal.org server (ex. https://drupal.org/node/954708). This is usually indicated in the “Help guide” if there is any. But for projects like Drupal 7 upgrade of a module or distribution, then most likely you’ll have to work on your own localhost.
- Install drupal.org
- Install the module you’ll be working and any dependencies.
Step 3: Patch up!
The easiest issue that you could probably work on is that it tells you to “upgrade module” to D7. If it is as simple as that, here is my workflow
- Change the .info to 7.x
- Try to install the module if it works
If there are so many errors, well, you got no choice but to rebuilt entirely the module once again. This usually applies to content types and views upgrade.
Don’t aim for perfection here yet. Make it installable and do the basic staff then ask the community to review your patch. Don’t spend 1 week or so working on it without asking for feedback. And usually, some contributors might want to change something than just copying it as is.
How to create a patch?
git diff > name-of-patch-nodeID-comment-no.patch
git add /path/to/all-affected-filesgit diff > name-of-patch-nodeID-comment-no.patch --cached
Step 4: Test
Before submitting, try your patch first and test it. I usually reinstall my drupal installation and refresh the files to its original form and apply the patch using git. Before, I have to manually go to the browser and reinstall everything including dumping the database using PhpMyadmin. My colleagues have thought me a trick in Drush.
drush si cod --account-pass=123123 –y
The above Drush command will reinstall Drupal along with modules/themes/configuration using the specified install profile.
You don’t have to specify the install profile if you only need to use the standard. The –account-pass makes my life easier so that it doesn’t give you random admin passwords.
Below is the complete Drush command that I just copy and paste to the command line and in less than 2 minutes, my site is rebuilt with my patch.
git reset –hard HEADgit apply –v name-of-patch.patchdrush si cod --account-pass=123123 -ydrush en admin_menu cod_bof field_ui devel devel_generate cod_session_evaluations -ydrush ucrt test --password=testdrush cc all
Step 5: Ready to submit
If it passed your test, put your patch out there and mark the issue for review. Don’t worry if it’s not perfect yet, other contributors will test your patch and tell you what is missing or still needs to be worked out.
If there is heavy development going on, expect a day or 2 that your patch will be reviewed. If not, well, it could take weeks. So don’t wait too long and don’t focus on this issue alone. Sometimes the issue is postponed because of a blocker or some other issues. Don’t feel bad about but instead, move on.
Step 6: Move on
Get involved with other issues like commenting or testing their patch. The more you get yourself involved in the issues, the more you’ll be more comfortable fixing and be contributing by code or by wisdom.
Feel like you need more training before delving into Drupal projects?
