From Fedora Project Wiki

Mockups here: http://next-fedoragallery.rhcloud.com/sarupbanskota/New%20gg%20mockups/e97fc8f9d67aca0557cf6ca522929a9f

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 a lot of 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].
    • I presented GlitterGallery at LGM 2014, Leipzig[4].

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

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

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

[4]- http://www.slideshare.net/sarupbanskota/helloworld-33181550

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 had proposed to some ambassadors and design team members about redesigning our Join pages, so I'm brainstorming in that direction with Mo, Ryan and Gnokii.

Why should we choose you over other applicants?

  • It wouldn't be wrong to say I know the codebase really well, especially about areas where it needs work. 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
  • Where it needs work:
    • Some random bugs thrown everywhere (although most of them are gone now)
    • Pull requests & Glitterposts
    • The overall UI
    • Lack of email-based notifications and other forms of communication

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

  • Designers can share their work: a lot of this has been facilitated. We need a public gallery to be able to showcase work.
  • Designers can 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 can create: we have a canvas that lets you do awesome SVGs from your browser!
  • Designers can explain their ideas: I'll be working on Glitterposts this summer, that aims to fulfil exactly this.
  • Designers can communicate: Realtime drawings? Email notifications? Just few iterations 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 techniques - 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 with new contributors to develop an extensive test suite.
  • 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.

Technical details, tools and resources

Documentation

UI/Design/Interactions

Realtime stuff

Timeline & Implementation

Development Strategy

Just like last time, I'll follow an iterative methodology. My timeline also makes space for me and my mentor to discuss the progress at least once a week, worst case. Note that this time strategy doesn't strictly apply, since not every iteration is uniform in terms of the sort of work involved. Each iteration takes up two-three weeks of time, in the following order:

  • 4-6 days of iterating over and developing mockups.
    • Do a mockup first - discuss with fellow contributors to invite feedback. re-iterate.
    • convert mockup into an interactive web page with html/css/js.
    • Blog about the finalized plan, and save points for documentation.
  • 4-6 days of writing tests.
    • Lay out what behavior we expect, based on the mockups we have.
    • In cases of difficulty, communicate with those better at tests - Emily and Rohit.
    • Run tests, find where they fail, raise issues on our tracker.
  • 4-6 days of buffer time + documentation period.
    • Share updates with Emily and other contributors, work on any feedback.
    • If new issues may come up, patch them.
    • Using points from the blog, write chunks of the documentation.

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 issues and feature requests 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 listing 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 listing 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 a front end for User profile pages - TODO: Add mockup for user page. We're not going to use 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 front 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 front 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 messaging and chat protocols & involve other developers in the design discussions. 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 messaging and chat protocols; involve other developers in the design discussions.
  • 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 node, will be really robust, but will require a huge learning curve.
    • The other would be working on a togetherjs 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 tough 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? ;)

Other information

Potential risks and mitigation strategy

Iteration fails to complete on time

  • Last time things were quite successful and we never really faced major delays. In the event of an iteration failing to complete on time, I'd do the following:
    • If the process I have missed out impacts future features to be built, I will adjust the next iteration to contain whatever I may have missed.
    • If it doesn't, I will skip that particular feature, and add its implementation to the last iteration.

Fundamental bugs in OpenShift due to which the architecture cannot work

  • The programming is done in as generic a manner as possible. Of course OpenShift works really well, but there shouldn't be major difficulties trying to deploy it on other open PaaS systems such as Cloudfoundry.

Weather/Internet Connectivity

  • For most of the coding period, I will be stationed in Kolkata, India. Summers are hot, and it might begin to rain towards July. But the weather is generally not extreme such that it disrupts internet connectivity. In the event of Internet failures due to my service provider, I have already located cafes near my house from where I can choose to work.

Laptop Crash

  • I will work from my ASUS K55VM laptop in the summer. In case something goes wrong, I have a spare computer at home. Since GlitterGallery is already on GitHub, I will push changes to my branch every 3 days, to avoid accidental data loss.

Miscellaneous information

  • My time zone is UTC +4.30 (accounting daylight savings). I generally prefer working in the evening and nights (UTC 13:00 to 22:00), when it is comparatively quieter and cooler.

Potential Mentor

Emily Dirsh and Ryan Lerch have agreed to mentor me.

Retrieved from "https://fedoraproject.org/w/index.php?title=GSOC_2014/Student_Application_sarupbanskota/User_Interface_improvements_to_GlitterGallery&oldid=376383"