GSOC 2014/Student Application sarupbanskota/GlitterGallery

Contact Information

• Your name: Sarup Banskota
• FAS Account: sarupbanskota
• Fedora userpage: https://fedoraproject.org/wiki/User:Sarupbanskota

• Email Address: sbanskota08 AT gmail DOT com
• Blog URL: http://thirstyforcola.wordpress.com/category/technology/foss/
• Freenode IRC Nick: banas

Why Fedora Project?

My involvement with the Fedora Project started with GlitterGallery last summer, where I made significant contributions. I'm happy to see it progress! In the process, I have had chance to interact with many other Fedora contributors across various domains. In the spirit of giving back, I spend almost every weekend on a trip evangelizing Fedora and FOSS.

I'd like to continue improving GlitterGallery and learn new development principles in the process. Just like last time, my primary motivation to work with the Fedora project coming summer is to take GG to the next level.

Past involvement with the Fedora project/ other FOSS projects?

• I've made substantial contributions to GlitterGallery[1].
• I do quite some non-programmatic FOSS activity - updating Fedora wiki pages, speaking about FOSS at conferences, conducting hackfests in and around college. Recently I presented at FOSSASIA 2014 in the Fedora track about GlitterGallery[2]. I also did a workshop on getting started with FOSS techniques[3].

[1]- https://github.com/glittergallery/GlitterGallery

[2]- http://www.slideshare.net/sarupbanskota/sarup-fossasia

[3]- http://www.slideshare.net/sarupbanskota/sarup-fossasia-1

Past GSoC involvement

I participated in 2013 as a student with the Fedora project.

Post GSoC 2014 plans with Fedora project

Just as I've been contributing post GSoC 2013, I'll continue doing the same :-) I'm also working on an asknot fork for Fedora [4], so newbie contributors to Fedora project are not lost.

[4]- https://github.com/sarupbanskota/asknot

Why should we choose you over other applicants?

• It wouldn't be wrong to say I know around the codebase really well, especially where we suck. I'm pretty certain I have outlined new ideas/bugfixes etc almost every week since last summer.
• When I started last time, I was new to almost every tool we make use of - Git, RoR, front end stuff. Now that I have picked up skills, I can break (and occasionally make) things much faster than before. Add to that the joy of a summer break when I don't have school pressure and it translates to powerful improvements to GG.
• My writing/art/speaking skills are fairly good, so I also come handy at maintaining wikis, answering questions, doing an occasional artwork and giving talks. Did I mention that through my evangelizing work at conferences, meetups and blogposts, GG's got new contributors?

Overview

• GlitterGallery is an amazing designer collaboration platform being developed by folks at the Fedora design team. The goals are to allow designers to easily share their work, gather and parse feedback in a useful way, and version their work just as developers are able to. GlitterGallery will be somewhat biased to support SVGs from Inkscape, and to work with the magicmockup rapid prototyping program. That doesn't mean it won't work with other filetypes, though!
• Until last summer, GG was mostly just an idea with a really basic implementation. Last summer I chipped in and with Emily's mentorship (and some of my work), we now have a fairly feature-loaded prototype! I'll admit there are many bugs, but they're getting squashed real quick and we should have OpenShift deployable quickstarts by June.
• What's great:
  • The Git integrations.
  • The GitHub fork/pull model
  • Overall structure, documentation, entry points
• What sucks
  • Some random bugs thrown everywhere (although most of them are gone now)
  • Pull requests & Glitterposts
  • The overall UI
  • Lack of email-based notifs and other forms of communication

The need I believe GlitterGallery (and my work coming summer fulfills)

• Designers to be able to share their work: a lot of this has been facilitated. We need a public gallery to be able to showcase work.
• Designers to be able to access other people's work: yes, you can now fork other people's work and submit pull requests, although the PRs break at many instances and aren't robust (WIP).
• Designers to be able to create: we have a canvas that lets you do awesome SVGs from your browser!
• Designers to be able to explain their ideas: I'll be working on Glitterposts this summer, that aims to fulfil exactly this.
• Designers to be able to communicate: Realtime drawings? Email notifications? Just few months away!

Relevant Experience

• I'm a computer science student at Amrita University in my third year. I've done relevant courses like OOP, Databases, etc
• I'm passionate about the web and have worked on some freelance projects previously.
• I'm an open source enthusiast and I'm committed to contribute to the Fedora Project.
• I have contributed to developing GlitterGallery.
• I'm familiar with the Git/GitHub workflow - well, we're talking GlitterGallery, which does better ;)
• I'm familiar with open source tecniques - irc/mailing_lists/version_control.

Final Deliverables

• Make GlitterGallery's documentation so good, other similar projects are inspired. I've spent more time trying to get more contributors than on anything else. In the process, I tend to realize what hurdles newcomers face, especially smart students who haven't been exposed to the industry workflow before. I'd like to make the project accessible to developers, administrators who have to maintain it on their fork, and designers themselves (our users).
• Set up a very good workflow for how contribution to the project works, track progress in a more organized way, and the like.
• Work on the backend stuff that we've been lazy about - simple things like providing user settings, project renaming etc so we're ready to deploy.
• Give GlitterGallery a fresh, new, functional UI.
• Improve the social stuff - set up mail notifications, create an activity feed, work on a realtime drawing board.

Timeline

Iteration Zero [ current to 25th May ]

The official Google timeline starts community bonding period on 21st April. Why wait that long? ;) I'm going to contribute as I generally do, but I must admit I'm really occupied with GlitterGallery/Fedora related travel and will not be extremely active (code-wise) until my exams get over on 25th May. I'll perform maintainance tasks and continue answering emails though.

Known engagements during this phase

• FOSSASIA related travel, Phnom Penh, Feb 25 - March 5
• Fedora India planning meet, Bangalore, March 7 - March 10
• Fedora evangelizing at SJCE, Mysore, March 14 - March 17
• RubyConf India, Goa, March 20 - March 24
• Libre Graphics Meeting, Leipzig, March 28 - April 9
• End Semester Exams (seriously, they're PITA), tentatively May 15 - May 25

Work

• Update the page for GlitterGallery on FedoraWiki[5], and all associated pages that mention about GG.
• Update the page for GlitterGallery on OpenHatch[6] and similar platforms that will help us drive contributors.
• Set up a well-defined workflow for contributing to GG. There have been some confusions with people forking off my repo and sending PRs to me, for example.
• As requested by Emily, elaborate on the more important PRs so it becomes contextual to newbies.
• Set up Wiki pages to track status about how the project is improving, to add release information and stuff like that. Since we're hoping to have new contriibutors, it would be great to have information about their progress listed somewhere.
• Properly document newcomer contribution guidelines based on the new workflow I come up with (based on discussions with Emily).
• Set up things on GitHub pages so we have a nice & fresh landing page. Sanjay has started off one, so we could take that as a starting point. Emily has set up glittergallery.net to currently point to the GitHub repo, so we set it up to work with the landing page.

[5]- https://fedoraproject.org/wiki/Design/GlitterGallery

[6]- http://openhatch.org

Iteration 1 [ 25th May to 7th June ]

This period marks the start of my summer break. By the end of the next iteration, Emily and I aim to put up the first GG for Fedora folk to use. I'd like to work on specific ideas that help build our way towards this goal. Below, I'm enlisting the set of things that we'll likely want tested, built and deployed for the first release. Note that I'm not proposing to do all of this, I'm just enlisting them here to generate context:

• User profiles
  • People have bio, gravatars, handle, a page to do their settings - change passwords, set preferences, the like.
• Projects with the git internals working right.
  • Settings - renaming it, adding a description, deleting it (unlike how we do it now we'll need something like a password confirm since it's a critical destructive action that cannot be reverted back).
  • Forking - currently we just copy since Grit's clone functions weren't clearly defined, but we can retain for now. If we make the move to rugged (explained later), it might be a good idea to fix it then.
  • Pull Requests - automerges/merges work, but I feel this needs a lot of working on and might not be as easy to implement as we originally thought. So, I'm thinking we just drop PRs for the first release and add it back in in the second when it's more robust. I'm open to comments on this.
  • SVG edit canvas - let people draw in the browser, apart from the usual upload. There have been issues with specific browsers[3] that we need to look at. Uploads need to be checked for the kind of uploads being performed. Multi-file update would be a bonus.
• Improve the UI. Seriously.

What I'll work on:

• Develop as front end for User profile pages - TODO: Add mockup for user page. We're not going to Bootstrap, so it's going to be tricky, but super awesome!
• Add to Rohit's tests - for the User settings.
• Provide settings for users - space for them to write about themselves, their interests, change authentication related info etc. Integrate with developed front end.
• Work on front end for Projects - TODO: Add mockup for projects/show, contributors list, commit history etc
• Add Project settings tests.
• Provide settings for projects - space for provide desc, add collaborators (in future maybe), delete with confirmations, etc. Integrate with developed front end.
• Ensure the fork process is smooth, and the non_bare and bare_repos are syncing as we need them to.

Iteration 2 [ 8th June to 23rd June ]

Towards the end of this phase, I'd like to be able to release a version of GG for Fedora design folks to start doing design work on. This will lead us to discover many bugs, which translates to more work (and more pizza and beer and fun and...)

• Work on frond end for the pull requests & related pages. TODO: Add mockup related to the issues page.. I have mockups inspired from GitHub's pull request model, but I'm open to discussions if we should follow alternate models (like Gerrit's), or even invent our own.
• Work on fixing browser-specific problems with svg-edit canvas. Some discovered issues seem to have been fixed in the upstream trunk, we'll need to integrate them back in to the current system.
• Ensure what we have completely deploys on OpenShift and doesn't error out.
• Last time I tried, OpenShift deployments were taking too long. Work on creating a quickstarter that creates an instance without problems - may require precompiling assets and adding turbo-sprockets: stuff that was added to the rails 3 version, will require to be added back in to the rails 4 upgrade.
• Set up things to create an instance of GG for Fedora design team to use. Identify and understand various issues people report and work on squashing them.
• There have been reports about SVG-edit not behaving properly on certain browsers. Emily and I had a discussion about this, seems like the latest version of svg-edit:trunk fixes this. Work on merging it back in to GlitterGallery.

Iteration 3 [ 24th June to 7th July ]

• Work on front end for Glitterposts TODO: Add mockups for Glitterposts. Most of Glitterposts is the frontendy stuff anyway, so I might as well fix the entire thing ;)
• Develop tests for Glitterposts - I have discussed my ideas for building a super Glitterposts platform at various conferences, I'll describe them here as well.
• Work on a frond end for News Feed and notification system. TODO: Add mockups for News Feed and notification system.
• Work with Rohit to add tests for news feed and notifications - I'll be honest, these tests might be a little difficult for me to attempt directly at this point.
• Implement a news feed and notification system. People will get an activity feed that hopefully will keep users hooked on to GlitterGallery when they use it, while it tries not to be a source of spam.

Iteration 4 [ 8th July to 21 July ]

Research phase

I've discussed with Emily about taking some time off at this point to research a bit about how chat/messaging architectures are made. We want to be practical - the front end for this stuff is going to be pretty complex and will take up a fair bit of time, so I'm not going to propose developing the backend. However, out of curiosity, I'd like to participate in discussions revolving around the decisions we make about the design aspects of implementing a communication system - we'd likely want it integrated with irc too. Won't it be lovely if zodbot is friends with GlitterGallery and links to an issue page when someone mentions something relevant on irc? ;)

• Research on architectures around messaginging and chat - involve in discussions about design aspects of the stuff with other developers who are working on it.
• Work on the front end for a personal messaging & chat system.
• Work with Rohit to develop tests for the communication system.
• Work on an email-based notification system. You know, emailing people when someone follows them and so on. I have worked on something similar before - shouldn't take too long.

Iteration 5 [ 22nd July to 15th August ]

Note: My college resumes sometime during this iteration, although I don't have exact dates yet. I'm also hoping to make it to Flock this year, so if it works out, the period in August might be occupied.

• We need a realtime whiteboard for designers to collaborate on SVGs in real time. This can also serve as a place to conduct meetings centered around interaction design. Etherdraw doesn't fit the bill since Emily has faced problems supporting it on OpenShift. Let's do better!
• Work on developing such a whiteboard. I have thought of at least 2 ways to implement this
  • One utilizes the node, will be really robust, but will require a huge learning curve.
  • The other would be working on a togtherjs driven improvement over svg-edit, which I feel will be relatively simpler to implement.

The model I'd propose is to come up with one based on togetherjs for the summer. Emily also feels this is going to be tuff since not much work has been done on this before, so we have decided to give it two iterations worth of time. What good is a summer if there are no challenges? ;)

Potential Mentor

Emily Dirsh has offered to mentor me.