Page MenuHomePhabricator

[GSoC 2016 Proposal] Reading List
Closed, DeclinedPublic


Project Title

Reading List

Personal Information

Name: Alangi Derick Ndimnain
IRC Nick: d3r1ck
Github: Github Profile Page

Background Information

I am an undergraduate final year Computer Engineering major, specializing in Software Engineering from the University Of Buea. I participated in as a mentor for the 2015 Google Code-In for Wikimedia Foundation (WMF) and mentored 6 projects. I have been contributing to WMF for about 7 months now and my contribution can be seen here: Contributions, where I have contributed patches across many different extensions.

Programming Background

  • Google Code-In 2015 Mentoring - Projects Mentored.
    • T118390: Using Maniphest's advanced search Documentation Screen cast.
    • T116802: Watching a project to receive its notifications Documentation Screen cast.
    • T118389: Screencast showing how to request a project
    • T121911: Remove deprecated html elements like <font> from SemanticForms
    • T108432: Desktop: Search box inaccessible in Special:Gather
    • T122968: Add a composer.local.json-sample to MediaWiki core
  • My Contributions to WMF Code base - Extensions Worked on
    • Echo Extension
    • Gather Extension
    • Graph Extension
    • Mailgun Extension (co-authoring)
    • MobileFrontend Extension
    • Newsletter Extension
    • Semantic Forms Extension
    • Thanks Extension
    • Wikibase Extension
    • WikibaseJavaScripAPI Extension
  • Also worked on OOJs/UI and MediaWiki Core.
  • Skills
    • Languages: PHP (Excellent), Python(Intermediate), JSON (Excellent), JavaScript/jQuery (Intermediate), CSS (Excellent), SQL (Proficient), HTML (Excellent).
    • Tools: Secure Shell, Git/Github, Gerrit, IFTTT, Linux OS (Ubuntu) and derivatives, Subversion, Vagrant, Composer.

Project Mentors

Synopsis/Project Summary

This project aims at enabling users to keep track of articles to be read later (Add to reading list) in Wiki pages. This will involve the user to stumble on the article he/she wants to read later, then adds this article in a read list. This project now tries to harness all articles that has to be read after or later in a list and well displayed so that when the user has time, he/she can just go to the read list and read the article.

Detailed Project Description


Gather is an extension that providing users with an opportunity to create and share lists of articles. These articles can be used in may various forms like reading them, sharing with friends after reading. Gather collects all these articles and "gathers" them in a defined way. This projects now is to use the Gather extension to hold a list a articles that a user might want to read later when he/she doesn't have time to read it immediately. Also its not only about keeping track of the article items but also managing them.

Implementation Approach

When a user of Wikipedia, MediaWiki, finds an article that he/she want to be read later, this article can be added to the reading list. This can be accomplished in the following approach;

In each article, there should be an Icon that will indicate that the article can be added to reading list or not. I intend using a book icon of this sort

that will indicate that this article can be added to the users reading list. Once for example an item is added to the users reading list, this items ID and the Users ID is inserted into the database where it is queried back and used when the user wants to view his/her Reading List.

Since each user has an individual ID that uniquely identifies him/her when the user wants to manage the Reading List, we can handle it in two ways.

  • Reading the Article in the Reading List: We can approach the situation in this way that when the user reads an article in the reading list, it should automatically be removed since he or she has read it. But this will affect some cases where the user was interrupted and wants to leave the item in the reading list and continue reading later. This situation is handled in the next option.
  • Removing the Item intentionally after Reading Unlike above where the article is automatically removed when the user reads it, we can make it in such a way that after reading the article, either completely or incompletely by the user, the article item is still in the reading list giving an opportunity for the user to leave the article in the reading list after reading it.

Only when the article item has been decided to be removed by the user from the reading list can the user remove it. Also, we can have favorite articles started at once from the reading list and also we can add them to wish list and so many other functions ported and utilized directly from the Reading list.


Adding Articles to Reading List

Open up a Wiki page
status = Add article to Reading list to be read later;

 if ( status == success ) {

        Continue adding articles to be read later to reading list;
else {
       Fails to add article to reading list;
       Prompts the user to try adding the article again;

       exit if user closes the page;

Managing the Reading List

Each article Item in the reading list will have a remove button;

While ( article Items In reading list ) {

          if ( item is removed from reading list ) {
                      Remove Item from reading list;
          else {
                       Leave article Item in reading list;

Testing and Verification


Testing like Unit testing shall be done by Jenkins bot first before mentors and I test the code to make sure it does what its intended for. But most of the test will be done by me and then sent to the mentors for review and other developers before its merged to the main Gather extension repository on gerrit.


Verification is where by the test is actually working or passes. After this verification which is still done by me, mentors and Jenkins including other developers, the patch set will then be merged into the main repository and development continues.

Development Schedule/Timeline

This is a plan that I will use during the GSoC period

  • April 23 - May 7 (2 weeks)
    • Community bonding period
    • Read docs concerning the Gather extension and how it collects information.
    • Docs on how Gather handles list of articles, how its created and how its being shared.
  • May 8 - May 22 (2 weeks)
    • Community bonding continues
    • Familiarize myself more with the Gather extension and how other extensions use it.
    • Fix patches related to this task or project
  • May 23 - June 13 (1 weeks)
    • Create a database table to hold the user information and articles added to reading list
    • Update the maintenance update.php script to import the table into the wiki database
    • Update my wiki report page daily.
  • May 31 - June 13 (2 weeks)
    • Design the UI for the Reading list page
    • Choose Icons and buttons to use in the Reading list to represent operations
    • Start writing codes to add article items to Reading list.
    • Update my wiki report page daily.
  • June 14 - June 21 (1 week)
    • Unit testing, Integration testing and debugging.
    • Fixing of bugs and documentation.
    • Update my wiki report page daily.
  • June 22 - July 6 (3 weeks)
    • Develop Reading list management strategies
    • Include buttons to the UI to which users can remove items from the reading list
    • Write codes for the reading list management strategies
  • July 7 - July 14 (1 week)
    • Unit testing, Integration testing and debugging
    • Bug fixing and documentation
    • Update my wiki report page daily.
  • July 14 - July 28 (2 weeks)
    • Add functionality for adding article to wish list in the Reading list
    • Add functionality for removing article from wish list in the reading list
    • Update my wiki report page daily.
  • July 29 - August 22 (3.5 weeks)
    • Code clean up and Unit testing of the whole project
    • Integration testing and debugging of the whole whole project
    • Update my wiki report page daily.
  • August 23 - August 29 (1 week)
    • Pencil down period
    • Code review and rounding up
    • Wrap up with documentation
    • Update my wiki report page daily.
    • Submit code to Google.

Time Availability

I would be able to offer over 40 hours per week on the project. Also, to meet up with the demands of the project, I will be coding during weekends and regularly informing my mentors on the status of the project and regularly updating my wiki report page. In addition to the time I will put in, during the GSoC program, I will have a 2 weeks period for exams starting from the 21 June - 8 July. During this period, my commitment time will drop a little bit but after that, I will put in 40 hours during the weekends to catch up with the work undone.

Why Wikimedia Foundation(WMF)?

Wikimedia Foundation which focuses on encouraging the growth, development and distribution of free, multilingual, educational content, and to providing the full content of these wiki-based projects to the public free of charge is an organisation worth working with to make my continent (Africa) especially Cameroon to be sensitized about such organisations, their projects and projects which enriches knowledge to the society for free. This will go a long way to improve my community and Africa including the world as a whole in terms of education and academics "for free".

My Contributions

Since I joined the Wikimedia Foundation (WMF) around September 2015 till now, I have contributed in several ways in the improvement of this movement both in coding and mentoring perspectives.

  • In terms of coding and submission of patches, I have over 20 patches merged, check here and more are still to come.
  • Also in terms of Mentoring, like I mentioned above in my Programming Background section, I mentored the Google Code-In 2015 program for the organisation. I mentored 6 projects.

Event Timeline

D3r1ck01 created this task.Mar 18 2016, 8:31 PM
D3r1ck01 updated the task description. (Show Details)Mar 18 2016, 8:49 PM
D3r1ck01 updated the task description. (Show Details)Mar 18 2016, 10:15 PM
JMinor removed a subscriber: JMinor.Mar 19 2016, 5:07 PM
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!
01tonythomas closed this task as Declined.EditedApr 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 eligible.

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.