The Beginnings
I am no stranger to contributing to open source. I have contributed in some way or another since early 2007, when I found a love for Linux and the Fedora Project. I was approaching the end of my time in college, and later in the year I joined the Fedora Art Team and teethed my contributing bug by helping create and provide graphics for upcoming releases of the operating system.
I have since evolved and moved on to other open source projects–specifically our beloved WordPress. While I was not active on a weekly basis, where I was creating tickets and patches constantly, I was staying aware of what was going on and current developments. I contributed when I could. One place that I was especially active was the support rooms on IRC.
Over time, I started to get an itch to do more. I wanted to contribute to the code of something. The WordPress core team had decided to improve its inline documentation, especially in the areas of available hooks and filters. Drew Jaynes and others spearheaded this effort and took the initiative of going through the codebase and providing documentation on every available hook. At this point, it dawned on me that this would be an awesome way to contribute back, but I needed a different codebase that needed the same tender loving care. Enter BuddyPress.
The Current
I approached Brad last autumn about having a small block of time provided each week that I would use to contribute during a work day. He came back to me later that day to inform that I had been granted the time as part of my day on Fridays.
Not long after this, Matt Mullenweg championed the idea of “5 for the Future,” where companies allow their employees paid time during their week to contribute to open source projects. The idea was to use 5%, or two hours in a 40-hour work week, of the employee’s time to give back. WebDevStudios followed suit and implemented their own “5 for the Future” policy for its employees. This rolled nicely in with what I was already doing. Marriage made in heaven!
Process
My contributions began when I simply made BuddyPress Trac tickets for the various BuddyPress components and added the created patch files to those tickets for review and commit by the current BuddyPress core developers. This worked out well while I was getting my bearings and becoming comfortable with the process and formatting we wanted for the documentation blocks.
Not long after that though, they approached me about granting commit access to the core repository. They felt that the process would be streamlined and more swiftly taken care of that way. I was granted BuddyPress core committer status with a focus on code documentation. It felt pretty awesome.
In terms of workflow, I started out working from a SVN copy of the codebase, which is what I still use when making the actual commits. I wanted the ease and fluidity of Git’s branching model as I knew it would help make the process even smoother as I worked through the filters and hooks. From there, I grabbed a Git copy of the code and do all of my actual work in Git branches for each component, before committing via SVN.
I do all of the work in PHPStorm and make good use of its features as an IDE, including code quality coverage and PHPDoc block issue reporting. Before anything was committed, I gave the changes a second review for QA and make sure there were not any nitpicky inconsistencies.
The future
I am proud to say that by the time this is posted, the journey to document the BuddyPress hooks will have been deemed complete. I have no plans to stop using my “5 for the Future” time on BuddyPress. After having scrolled my way through most of the nooks and crannies of BuddyPress’ codebase, I know there are many areas that still need documentation improvement and that is where I plan to focus next. Feel free to reach out if you would like to contribute as well; I’d love to help you accomplish that.