From Fedora Project Wiki

< GSOC 2014‎ | Student Application sarupbanskota

Revision as of 03:11, 19 March 2014 by Sarupbanskota (talk | contribs) (pump more time into i5)

Contact Information

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

  • What the idea is & history
  • What I worked on so far
  • What sucks/breaks from what I built
  • What I'd like to add

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

  • What it was intended to fulfill
  • What my past work fulfills
  • What new work will fulfill

Relevant Experience

  • college, projects
  • web work
  • open source tools
  • codeschool etc
  • github
  • linux skills

Final Deliverables

How I intend to implement the proposed ideas

Technical details, tools and resources

Timeline

Development Strategy

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.

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.

Iteration 5 [ 22nd July to 15th August ]

  • 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? ;)

Iteration 6 [ 5th August to 20th August]

Other information

Potential risks and mitigation strategy

Miscellaneous information

Potential Mentor

Emily Dirsh has offered to mentor me.