GSoC/2013/Report: Difference between revisions

From SMC Wiki
(Created page with "==GSOC 2013 list of proposals== The response from the student community were overwhelming, considering the fact that SMC and Silpa occupy a niche area of language computing a...")
(No difference)

Revision as of 15:13, 14 February 2014

GSOC 2013 list of proposals

The response from the student community were overwhelming, considering the fact that SMC and Silpa occupy a niche area of language computing as opposed to something that solves much more generic problems. The primary point of contact was of course the mailing list, and then IRC. The following students prepared proposals for consideration.

The selection process

The people involved in the selection process were mostly org admins and mentors. We consider this natural since it is after all, the mentors who'd need to find time and work with the students.

First cut of proposals

First we - (mentors/org admins) - looked at each student proposals, and got in touch with them via email/IRC for an initial evaluation. Once we were convinced that their idea is valid, we gave feedback on their proposal -This means that we thought the proposal was good and it is something which would add value to our work, hence benefit the community. A few proposals were pruned during this time.

Short listing proposals

We evaluated applicants' existing work and in some cases, asked them to prove their ability - this also means the mentors were involved in a deeper relationship with the student and probably looked at their code, helped them through some stuff, asked them to fix some minor bugs- this was a capability evaluation phase. Again, this means that we seriously considered their proposal, and thought it was good. At the end of this period, the mentors had already formed a sort of bond with the students. We had a short list of projects by this time. This phase ended on May 27, 2013, when the community bonding period ended(as per the GSOC 2013 schedule).

Final selection

On May 27th, Google announced the number of slots we are entitled to - and as always it wasn't as much as we expected. We got 3 slots. There was a furious round of discussion on IRC/via emails, each mentor defended respective student's proposal and tried to push it in. Finally we looked at the following simple things to arrive at a final list.

  • Immediate need - The proposal satisfies a long lived/immediate need for a piece of software
  • Practicality - The proposal's aims fall within what could be considered an achievable target within the GSOC time line.

After de-duplication checks and sorting out such issues with other FOSS projects, we selected top 3 proposals as per criteria above.

Selected proposals and their status

A word about these proposals. As mentioned earlier, these were chosen keeping the immediate need and practicality in mind. We also gave preference to students who were already part of Free Software community in general and for whom mentors could vouch for, with evidence of programming ability.

  • Ershad - Grandham web application is planning to store and process bibliography data of books with i8n support. This satisfied an immediate need, and was very practical. Ershad was already a long time community member with proven programming ability and has already contributed to couple of other open source projects as well. Once again, this turned out to be a wise choice. The code quality was very good and achived all primary objectives. The outcome of the project will be going live as a website with Open data sets in grandham.org . as soon as we get the production server infrastructure ready, and Ershad is continuing with the project.
  • Nithin - Complete the task of porting SILPA as a flask application, and restructure the modules into entirely stand alone modules available via Pypi. Among the list of applicants, Nithin had to prove himself to his mentor and the community, and demonstrated enough drive to convince us. This was an important task since SILPA modules can now be installed from PyPi and be setup to run as a flask application. Installation and maintenance of SILPA was not entirely straight forward before this and we believe this was one of the factors that was preventing contributions/adoption of SILPA.
  • Nandaja- Automated Rendering testing. This satisfied an immediate need to verify the correctness of glyphs produced by Harfbuzz rendering engine's output. Nandaja was already contributing to the community via her localization efforts as well as by packaging Ruby gems for Debian. In hindsight, we are glad that we chose her - she continues contributions to this day, either by code or by volunteering time for offline activities. The solution is now very helpful in rendering testing in font/rendering engine developments and changes.

==Progress report on each proposal

Each project sucessfully achived its stated primary objectives. Each student was advised to blog every week and post updates in wiki and project lists. This automtcally increased the discussion on on going developments in the project

Overall experience for SMC

Since this was the second time around for SMC, we were prepared to handle the initial influx of proposals as well as trimming down the list. Mentors and org admins put in a lot of time considering scope, viability as well as need for each of the proposal. More importantly, we very patiently evaluated each student and had their individual impressions vetted by each other so that there would be no gaps in understanding. We knew that we'd have to pare down the list we arrived at from phase 2 of selection process, and had lengthy discussions. Note that mentors were taking time off their precious spare time, and were simultaneously actively contributing throughout the GSOC period as well. We were very satisfied about GSOC 2013 as a whole since we gained three valuable members as well as solved three very diverse, equally important problems. This has made our work lighter in the areas of rendering testing, making bibliography data publicly available in a user friendly fashion, as well as making Silpa easier to install, use and manage.

Overall impression from students

The students have remained active contributors and have formed a bond with the community. Majority of the SMC community are from Kerala, and one of the students, Nithin, is located in a city far from Kerala. He hasn't been able to interact with more members of the community offline, but has maintained contact with the community and still contributes. The students have the following to say about GSOC 2013 mentorship. Nandaja - "My experience working with Swathanthra Malayalam Computing in this GsoC season was more that satisfactory. My mentors Rajeesh K Nambiar and Santhosh Thottingal provided necessary guidance and full support throughout the project period. I could learn a lot from my mentors and SMC. I could manage my college work along with the GsoC project very easily with the support from by mentors and the mentoring organization. Suggestions provided by the mentors after each evaluation was very helpful for me to make the project better and also to learn new things. I hope more students get opputunity to work under SMC in the coming Google Summer of Code season." Ershad - "I had 3 mentors for this project, namely Anivar, Baiju and Mahesh. They were very supportive and we had a fun time building the software. We pretty much met all the expectations we had for the project. We have been working on it after the GSoC program too to make it better" Nithin - "I was happy with the mentoring. I learnt a lot from my mentors.They were very understanding and helpful whenever I was stuck."

Issues we ran into and how we solved it

  • First of the issues (as always) was ensuring that the students provided timely updates. Sorting this out was very tedious, especially when the students and mentors were separated geographically. Mentors had to keep out an extra eye for this. The fact that updates were over the community mailing list helped things a bit, as the community also kept track of progress.
  • Actual collaboration - yes ! even in this age of technology, nothing beats sitting together in a room. We used all possible form of communication over the internet - IRC, email, google hangout, phone call and even viber . There was a certain time delay between the students getting stuck at some point and the mentors responding, but it was never more than a day. But in the end, turns out that the only thing that is needed for collaboration is an active and shared interest, and nothing else. We'd have done this over morse code if we had to :)
  • Documentation - The students documented their progress properly, but we feel that the mentors should also document their experience along with the students.

Conclusions - what we gained and learned

We learned

  • That we should document EVERYTHING related to GSOC (and expand that to other activities) - we will have more people to do documentation this year.
  • That we should look at other means of collaboration than email and IRC - shared task lists and whiteboards (Trello, Etherpad, Loomio and such)
  • That mentoring is a tough job. They should rely on the community to ease their load a bit, especially thing such as tracking progress. This year we will have people exclusively assigned to track progress, in addition to mentoring.
  • That there are other means of communication, like Telegram/Whatsapp which are handier and which often enables short and meaningful bursts of communication between people in the community. As such, we'd start channels devoted for GSOC on telegram as well.
  • That when considering proposals, try to gauge the interest levels in the student and give it more weight. Sometimes, no, always, a keen interest makes up for lack of knowledge.

Overall, we gained a LOT and lost nothing. Very important pieces of software, and 3 valuable members to the community. Hopefully, they will volunteer to be mentors in the coming GSOCs.