User:01tonythomas/GSoC Experience
The Extension::BounceHandler for handling MediaWiki bounces was prepared as part of the Google Summer of Code 2014, and got deployed on May 30, 2015 into the WMF clusters including the many Wikipedia's 8 months later. This short story would go through various stages of the process, which might not only include:
- The not-so-technical aspects of getting started ( being a strong candidate, devising the plan with mentors etc etc )
- The technical aspects ( writing an extension, preparing the unit tests, getting things reviewed )
- The Wikimedia process of architectural, security and performance review along with different stages of deployment in the WMF clusters ( few hurdles faced, how you can get through )
- Finally rolling out your product in the en-wiki!
I hope this would help someone in the future!
The not so technical aspects of getting started[edit]
When starting with Mediawiki in September 2013, I never had any idea of any GSoC/ other opportunities in here, and all I wanted to do was do some open source contributions - and I think that helped me get in touch with many devs without the regular "Hi my name is so and so, and I want to do GSoC with Mediawiki, what can I do". This happens when possible candidates come in the last minute and stumbles over gerrit, git review and Phabricator.
Being the strong candidate[edit]
Something special about the organization's rule ( from lessons learned ) is "The point of the program is actually to build a productive relationship, not to deliver a feature" - so clearly - the community is looking for long term contributors, and if you can reach well before - say at-least 2 months before the deadline - you are of course, the strong candidate.
Getting attention from devs is yet another trouble you would face anywhere in a new community - and for that - go to Phabricator, search for bugs under project:Easy, and start fixing one by one. By the time the deadlines draw near, you would've enough commits under your gerrit id - and your mentors will say "You have already done great, wow! So why don't you stop doing your microtasks and concentrate more on your proposal ?" this would mean more time with the proposal during the timeline, and yeah - you become the strong candidate.
Meeting your mentor and devising the plan[edit]
I had loads of trouble getting mentors for my own project, as it needed one from the development side and one from technical operations. I emailed various possible mentors whom I know - and luckily Legoktm assured me with the development side - but with operations, finding Jeff was a treasure hunt. I went to #wikimedia-operations and started pinging devs one after the other seeking instructions. brute force works, but keep it neat - and don't spam . Finally, I had to post my request in Wikimedia RT with help of operations team, and Jeff volunteered.
Start early : We did begin our work way before the coding phase started, even one week before the selection results came out. This really works when the project is huge, and you need to make your mentors feel that you are ready to spend your time with the project - and not just the prize excites you.
Email mentors with specific questions : I don't think this would work with every one, but a reply email can have valuable portions for your proposal - so after regular IRC chats, think about writing e-mails too. This would increase your documentation skills, and maybe you would get loads of contents for your proposal too ( I got loads ).
Regular IRC conversations : We had regular IRC discussions ( yeah - almost regular - if you omit the weekends ) and try to draw a sketch of what you are going to do once you get into the project. I would strongly recommend irccloud as it keeps amazing logs.