Page MenuHomePhabricator

Improving static analysis tools for MediaWiki(GSoC 2016 Proposal)
Closed, DeclinedPublic



Name: Bill Morrisson
IRC or IM networks/handle(s): billm on freenode
Web Page / Blog / Microblog / Portfolio: Personal portfolio being developed, you can look at some of my work in the meantime at
Location: Buea, Cameroon
Typical working hours: 8-10 hours a day 9am to 5pm and 2am to 6am GMT+1


This project aims to improve on the code standardization of the mediawiki codebase and other extensions to standardize it in a consistent manner such that developers should not be worried about style when coding but should just code away and let analysis tool handle the coding style. By not only checking the code for errors in an automated manner but also fixing them wherever applicable. This will enable MediaWiki to have a consistent codebase for all developers and developer time will be reduced which will result in less confusion and reduced time in finishing tasks.

Mentors : @Addshore, @EBernhardson, @Legoktm


Right now, MediaWiki core and some other extensions are using PHPCS standard for code standardization but some functionalities are still lacking full support for all the coding conventions in MediaWiki. Some ideas to be implemented as said in the task's description are:

  • Usage of $dbr->query() directly instead of the $dbr->select() wrapper
  • Using wfMessage() when $this->msg() is usable
  • Using globals ($wgUser, $wgRequest) when their context equivalents could be used instead ($this->getUser(), $this->getRequest())
  • Modifying certain globals ($wgUser, $wgResourceModules, etc) inside a $wgExtensionFunction where it is either too early or late to do so

Some ideas I have are:

  • Enable the following tests as sniffs also: AutoLoaderTest, ResourceTest and StructureTest
  • Testing infrastructure for the codesniffer to be checked. (T92751, T108458)

Project timetable

COMMUNITY BONDING Research on sources like or itself - which do similar static code analysis - and identify whether they can be implemented/modified for our case. Go through recent patch sets and identify issues mentioned in the comments that can be checked using codesniffer. Read through Manual:Coding conventions and identify any points that need more looking into. (I've already read a good chunk of it.)
Week 1 - May 23Enable a sniff to check the use of $dbr-> select() wrapper instead of using $dbr->query() directly
Week 2 – May 30Enable a sniff for checking functions like wfMessage when $this-> msg() should be used
Week 3 - June 6Enable a sniff to check for the use of globals when their context-equivalent should be used directly
Week 4 - June 13Adapt MediaWiki-CS test framework to support testing sniffs that support auto-fixing
Week 5 - June 20(continued) Adapt MediaWiki-CS test framework to support testing sniffs that support auto-fixing
Week 6 - June 27Enable StructureTest to work as a sniff
Week 7 - July 4Enable ResourceTest to work as a sniff
Week 8 - July 11Enable AutoLoaderTest to work as a sniff
Week 9 - July 18Improve Test Suite for mediawiki phpcs standard
Week 10 - July 25(continued) Improve Test Suite for mediawiki phpcs standard
Week 11 - August 1Feature freeze, strengthen unit testing, bug fixing
Week 12 – August 8Bug fixing, strengthen documentation


I'm at ease using Git , so I've got the basic code review workflow and collaboration aspect pretty well established.
While I'll be working on this project, I'll submit my code for review daily to Gerrit. I like to keep things backed up, and doing this daily ensures that other developers will be able to keep track of my work much better.
Also, these are the additionnal means I plan to use to communicate progress:

About you

I'm a computer networks undergrad in my fourth year at the Catholic University Institute of Buea, Cameroon.

How did you hear about Google Summer of Code?
I heard it from a friend that is in the Google developers group in my community but at the time I didn't know how to code and it looked like a great experience. Last year I went to a conference where it was mentioned, but I was on an internship and it was already past the student application deadline. So here I am this year ;)

Will you have any other time commitments, such as school work, another job, planned vacation, etc., during the duration of the program?
I will be involved with some course work that does not actually take more than eight hours a week and also the final exams which will be in July(date not set) will not take more than five days.

We advise all candidates eligible to Google Summer of Code and Outreachy (previously known as FOSS Outreach Program for Women) to apply for both programs. Are you planning to apply to both programs and, if so, with what organization(s)?
I apply only for the Google Summer of Code 2016
We don't just care about your project -- you are a person, and that matters to us! What drives you? What makes you want to make this the most awesomest wiki enhancement ever?
What initially sparked my interest for this particular project was that when I cloned the MediaWiki code base some months ago and I wanted to start making little contributions, hovering over some parts of the code base rendered me a little confused and I couldn't make any significant contribution. When I saw this project I saw it as a good fit for helping any newbie (or any new developer in the community) to follow the consistency of the core code base and the extensions and to code without having to worry about the styling.

Past experience
Since I started coding, I have helped a team coming out with these two projects: and
While I haven't worked on any major open source projects yet, I'm confident that my prior work experience will serve me well. Having already worked as a freelance developer makes me even more confident that I am able to give it my all during the entire summer. The patches that I have already worked on are:

Other info

I also have a Github but stuff there was mostly used for educational purposes when I started programming. For the curious only ;)

Microtasks submitted

Event Timeline

Billghost renamed this task from Improving static analysis tools for MediaWiki(GSo) to Improving static analysis tools for MediaWiki(GSoC 2016 Proposal).Mar 19 2016, 2:53 PM
Billghost raised the priority of this task from Lowest to Normal.
Billghost updated the task description. (Show Details)

Please dont link microtasks not to the main project task in your proposal. You can add it in a separate section like 'Past contributions'

Billghost updated the task description. (Show Details)Mar 21 2016, 10:31 PM
Billghost updated the task description. (Show Details)Mar 21 2016, 10:37 PM
Billghost updated the task description. (Show Details)Mar 21 2016, 10:52 PM
Billghost updated the task description. (Show Details)Mar 22 2016, 7:48 AM

Thanks for reviewing and also for your comments on my proposal

IMPORTANT: The deadline for submitting your proposal to Google Summer of Code 2016 application system at GSoC application system falls in roughly 24 hours at Mar 25 2016, 19:00 UTC. Please make sure that you have a pdf copy of your proposal in the application system beforehand, to avoid last minute confusions. Remember to relate your Phabricator task and associate 2 mentors in the proposal description, so that it gets easy for review. Past the deadline, you should only make changes limited to fixing typos, or incorporating feedback's. Good Luck, and check out the micro-tasks!

Bill, I encourage you to focus on a single proposal. But in case you want to do both, the microtask for this one needs tests still. Try to get it merged as soon as possible.

Ok @Niharika thanks for the suggestion I will be mostly focusing on this proposal:

01tonythomas closed this task as Declined.Apr 23 2016, 6:13 AM

Thank you for your proposal, but sadly it didn't make it to the selects this time. You are welcome to apply for Outreachy round'13, or GSoC round 14 with the same proposal ( if it still have consensus ) or a new one if elibible. Please notify your siblings below 18 years of age about the Google Code In 2016 ( ) round and add yourself as a mentor for the same, if eligible. Closing the proposal as Declined, see you around in #wikimedia-dev.