IEG Update (August)

Phase 2 has begun, and I’ve been working on the newbie-friendly enhancements and new location-based features for the app. Below are summaries of the tasks I have completed or are working on this month:


Allow account creation from within the app itself (#48). The ‘sign up’ button previously redirected users to their browser, which breaks flow and poses a bit of an inconvenience. Initially the plan for this task was to embed account registration in the app programatically, but this turned out to pose several challenges that would have significantly increased the # of hours needed to implement this feature if we went that route.

Eventually, we decided to just embed the Commons mobile registration URL in a WebView, and override the ‘success’ page to bring users back to the login screen of the app. This approach appears to be the best of both worlds – we can use the Commons web registration system (so it will automatically update with any changes made to the system), but flow isn’t broken and the user doesn’t need to switch back to the app from the browser.

ieg-create-accountWarn users if they submit image without selecting categories (#61). A dialog was implemented to warn users if they attempt to submit an image without selecting any categories, and to stress the importance of categorization. The user still has the option to choose to continue with submission, as some people might prefer to add categories later.

ieg-no-categoriesWarn users if they press back button without selecting categories (#58). Pressing the back button on the category screen by mistake will irreversibly take the user back to the main screen without allowing them to select categories, whereas the upload has already begun. A dialog was implemented to ensure that leaving the category selection screen is intentional and not by mistake.



In progress

Add page to tutorial to educate new users on what types of images are useful (#95). I have been talking with Pine about the possibility of collaborating on the tutorial, and the plan is to re-use his educational script for Commons as the basis for our tutorial. As his script is not yet complete, this task has been pushed back a little and I have moved forward with the location-based features while waiting.

Display nearby wiki articles lacking photos (#73). This task is currently in progress. I am working on implementing a list of nearby places lacking photos, drawing from a CSV file that is maintained by the Wiki Needs Pictures project. I’ve hit a few snags, but substantial progress has been made and I estimate that this should be done in 1-2 weeks.

Add geocoding template (#35). This task is next on the list if Pine’s scripts are not yet ready for the tutorial task.


All in all, some minor changes and setbacks, but all seems to be going reasonably well. Looking forward to getting more new features in! 🙂

IEG Update (August)

List of tasks completed or in progress (Phase 2)

I will be updating this post periodically with the tasks that I have completed or am currently working on for Phase 2 of the IEG project.

2(a) Make app more newbie-friendly – (5.5 wks)

  • Allow account creation from within the app itself (#48) – Completed, released
  • Warn users if they submit image without selecting categories (#61) – Completed, released
  • Warn users if they press back button without selecting categories (#58) – Completed, released
  • Add page to tutorial to educate new users on what types of images are useful (#95) – Awaiting Pine to complete Commons module so we can re-use

2(b) New location-based features – (5 wks)

  • Display nearby wiki articles lacking photos (#73) – Completed, released
  • Add geocoding template (#35) – Completed, released

2(c) Enhance titles and categorization – (6 wks)

  • Option to copy title and description from previous upload (#65) – Completed, released
  • Suggest categories based on entered title (#43) – Completed, released
  • Filter out year categories (#47) – Completed, released
  • Headers to distinguish where suggestions come from (#76) – In progress
List of tasks completed or in progress (Phase 2)

IEG Update (July)

We are experiencing what I would term as ‘a good problem to have’. One of our measures of success was a 50% increase in active installs, compared against the benchmark of 217 active installs when my grant was approved. It was anticipated that we would only hit that mark after the publicity phase (Phase 3). However, it is only 3 weeks into the grant, and we’ve already exceeded that! 😮 We now have 337 active installs and counting.

Why is that a good ‘problem’? Well, due to the nature of how Android works. Unlike iOS, which is fairly standardized (AFAIK iOS devs only need to target one version and one type of hardware at any time), Android is a much more multifaceted beast. OS updates are not mandatory, so many manufacturers don’t push Android updates to their devices, especially older ones. As a result, the more users you have, the wider the variety of Android versions and hardware your app runs on, and the higher the potential of things breaking. Also, of course, more users try more things that you wouldn’t have thought of.


As you can see from the pie chart, our users are split between several versions. The most popular are Android 6.0, Android 5.1, and Android 4.4. Those are all very different and code that works for a particular version might not necessarily work for another. Also, the existing code for the app is fairly old (from a few years back), so several changes needed to be made to make it compatible with the newer versions of Android. The runtime permissions feature introduced in Android 6.0 in particular has been the source of several bugs.

My initial plan for Phase 1 did account for the possibility of a few new crash reports coming in… but I hadn’t accounted for anywhere near the number that actually did come in. As a ballpark figure, about half of the bugs that I have fixed so far were reported after the start of the grant. As a result, as Phase 1 draws to a close, I find myself needing to prioritize new bugs that were causing significant problems for multiple users (like the API 23 camera bug and the Google Photos bug), and having to potentially put aside some of the less-serious bugs that I was initially intending to fix (for instance, my pet peeve bug is Newly uploaded picture replacing some of the other pics (in My Uploads page) , but that hasn’t yielded any success after spending a few hours on it, and no other users have complained about it).

There is still about a week left in Phase 1, and I will do the best I can to fix what I can manage. Ideally, I would be able to fix everything. But unfortunately, realistically I think that would be unlikely before I have to move on to Phase 2. 😦

Update 29th July: Moving on to Phase 2 as planned. Most of the major bugs have been fixed in Phase 1, so fingers crossed that the new users that we are acquiring on an almost daily basis do not experience much trouble with the app.


IEG Update (July)

List of bugs fixed (Phase 1)

This post contains a running list of bugs fixed and Google Play releases of the app, for Phase 1 (Fix existing bugs/crashes) of my IEG project.







List of bugs fixed (Phase 1)

A new chapter begins: IEG

My IEG proposal has been selected for this round! 🙂 I’ll be spending the next 6 months working on the ‘Upload to Commons’ Android app, and I’m absolutely psyched. It’s been announced on the official Wikimedia blog as well (woohoo!). I marvel at how it seems like not so long ago that I was downloading the GitHub client for the first time and trying to figure out the whole collaborative open source thing… I wouldn’t be here if it weren’t for Outreachy and my two amazing mentors. Mentored internships are awesomesauce. Srsly. It’s never too late to do one.

In other news, the ‘Upload to Commons’ app is now known as the ‘Wikimedia Commons’ app! Yes, we’ve been authorized by Wikimedia Foundation to use their trademark Commons logo and name, contract has been signed and all that. There was a little snag with the app being suspended while we tried to get the contract to Google, but that should all be sorted now. Hopefully.

We also had our first new collaborator on our GitHub repo in a long time, and he’s done some really awesome stuff, including helping us migrate our project to Gradle (using Maven with outdated dependencies on Android Studio was a huuuuge pain in the butt). Welcome, Adam Jones!

Will probably try to update more often, with my IEG project starting and all. Stay tuned! 🙂

A new chapter begins: IEG

Three cheers for Outreachy!

Outreachy’s goal is to encourage more people to get involved with FOSS – and I think they’ve succeeded in my case! I’ve always identified with the ethos and ideology of FOSS, have always wanted to contribute, but was previously too intimidated to get involved. Plus, lets be honest – starting out is always one of the most difficult parts, starting out without a mentor is harder, and starting out without a mentor while simultaneously juggling a day job even more so.

While I can’t say that Outreachy inspired my interest in FOSS (I’ve always been interested), they’ve provided a clearer and easier path to get involved by alleviating the other two issues – mentors and finances. Having the opportunity to get paid to work on FOSS full-time while being guided by experienced FOSS contributors has been absolutely fantastic, and has helped me get over the starting-out hump. Thank you, Marina and everyone else behind Outreachy. 🙂

So…. what next?

I’m still unsure as to where I’ll go from here with regards to FOSS. Being able to continue working on FOSS (and with Wikimedia) as a job would be amazing. Wikimedia offers Individual Engagement Grants for people who want to undertake a project to improve various aspects of it, so I’ve submitted a proposal for the next IEG round. It’s a bit of a far-reaching goal – I’m not a long-time contributor and I haven’t received too many endorsements on my proposal yet – but it’s a goal all the same. 🙂

Three cheers for Outreachy!

Guide: Applying to Wikimedia for Outreachy/GSoC

Applications for this round’s GSoC and Outreachy programmes are in full swing, with the associated flurry of activity. Yay, the community grows! 😀

I did my Outreachy project with Wikimedia, which turned out to be an excellent choice for me. IMO, working on a project that you actually use in your personal time is a huge advantage – you’re constantly motivated by seeing the improvements you make being used by other people… and yourself.

That being said, I won’t lie, the application process for Wikimedia is a bit more complicated than that of some other organizations (albeit very thoroughly documented). There are several additional requirements, and if you are new to everything it might feel slightly overwhelming. But do not worry! This little guide is for you, from one newbie to another. 🙂

(Disclaimer: This is a rough guide based on my personal experiences in the Dec ’15 – Mar ’16 Outreachy round, and do not reflect the views of Wikimedia Foundation. Also, there may be differences with GSoC that I am not aware of, but AFAIK the two have an extremely similar application process. Also, this is not intended to be an exhaustive guide, but rather to highlight the Wikimedia-specific requirements that are not covered much in the GSoC/Outreachy guidelines.)

Getting started

Essential reading: Life of a successful project. You will be referring to this page multiple times during the process of your application and internship.

Phabricator is the lifeblood of technical collaboration in Wikimedia. Everything on Phabricator is a ‘task’ – the project task you pick, the proposal task you will make, the reports you will write later on. Tasks are associated with project boards which are essentially ‘groups’ of tasks – for instance, this is the GSoC 2016 board.

Finding a project and mentors

There are 2 main options for finding your project:

The “Featured project ideas” column on the GSoC or Outreachy project board contains the project tasks that are ready for you to choose – they have been approved by the community and have 2 mentors ready for it. This is the easier route.

Another option is to scour Possible-Tech-Projects for projects that may or may not be ‘ready’ yet. This is a viable option but involves more effort and risk – you will also be responsible for finding your own 2 mentors (yes, 2 are usually required by Wikimedia, the lead mentor and a co-mentor). This is the route I took, because there was a particular project that I really wanted to do that was not featured yet.

Complete your microtask

This step is similar with Outreachy or GSoC’s requirements and varies widely depending on the project you chose, so there isn’t much to elaborate on.

Drafting your proposal

GSoC/Outreachy has its own application template, but your Wikimedia proposal is a separate requirement. Create a Phabricator task – this will be your proposal task – and follow the template stated. Some of the questions will overlap with your GSoC/Outreachy application, copy/pasting between the two is okay. Associate your proposal task with the project task.

As far as I know, only one intern can be accepted for one project. The selection process is described here, along with the criteria used for selection. From my observation, the thoroughness and quality of your proposal matters a lot, so it is worth putting some thought and time into a good proposal. You also need to have fulfilled programme-specific requirements, such as not having too heavy a university load during the 3 months of the internship for Outreachy.

By the application deadline, your proposal should be mostly complete and residing in the ‘Proposals Submitted’ column of your project board and you should have at least one microtask completed.


The mentors for each project task will select their preferred candidate and there will be a discussion with the organization admins to determine the selections. However, GSoC or Outreachy admins also have the right to reject applicants who do not fulfill various programme-specific requirements.

Community bonding period

Hooray, you got accepted! Congratulations. There will be a community bonding period during the week prior to the start of your internship; more on that here. The community bonding period is fairly time-consuming, so you would ideally not have full-time commitments during that week as well.


All the best folks!

Guide: Applying to Wikimedia for Outreachy/GSoC