From Fedora Project Wiki

< GSOC 2014‎ | Student Application sarupbanskota

Revision as of 07:00, 18 March 2014 by Sarupbanskota (talk | contribs) (adding just one sub-header seems ugly)

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[1], and all associated pages that mention about GG.
  • Update the page for GlitterGallery on OpenHatch[2] 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.

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

[2]- http://openhatch.org

Iteration 1 [ 25th May to 7th June ]

This period marks the start of my summer break. By the end of iteration 2, Emily and I are aiming 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:

  • Work on front end for User profile page - TODO: Add mockup for user page.
  • 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.
  • Add Project settings tests.
  • Work on front end for Projects - TODO: Add mockup for projects/show, contributors list, commit history etc
  • 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 ]

At 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 ;)

  • Work on frond end for the pull requests & related pages. TODO: Add mockup related to the issues page.
  • 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, may need to be added back in in 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
  • Develop tests for Glitterposts - I have discussed my ideas for building a super Glitterposts 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 at this point.
  • Implement a news feed and notification system - WIP: Is it too difficult to be considered user one iteration?

Iteration 4 [ 8th July to 21 July ]

  • Work out a suitable architecture to perform messaging and chat - we probably want integration with irc and zodbot too.
  • Work on front end for a personal messaging & chat system.
  • Work with Rohit to develop tests for the system.
  • I'm not going to propose developing a backend for the messaging/chat system for two reasons -
    • There has been interest from other contributors for taking it up.
    • The front end for this has to be done in a quite sophisticated manner, so I doubt there will be enough time to take this up in this iteration.
    • That being said, I'm open to take it up in the next iteration if I'm required to :)

Iteration 5 [ 22nd July to 4th August ]

  • We need a realtime whiteboard for designers to collaborate on SVGs in real time.
  • 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 simpler to implement.

Since I'd like to learn both, the model I'd propose is to come up with one based on togetherjs, let people experiment on it (assuming that by then we have a version up that few people use), and then build one more complex one customized to what we understand from the users.

Iteration 6 [ 5th August to 20th August]

Other information

Potential risks and mitigation strategy

Miscellaneous information

Potential Mentor