From Fedora Project Wiki

Proposal

An overview of your proposal

I'd like to make 5 major changes/improvements to GlitterGallery. These also serve as the final deliverables at the end of the coding period.

I gather from the commit history that devise was used earlier on in the project, but scrapped later (couldn't find a reason anywhere yet). However, I feel that devise can cater to this need pretty well. Also, as Emily mentioned, I'll keep an option for the administrator to change the allowed authentication methods.

Grit is no longer actively developed, and although there is no current use case in GlitterGallery where Grit fails, it surely could happen in the future.

  • Create an issue tracker. (Something on the lines of Github's issue tracker)

Though the basic idea is the same as GitHub's issue tracker, as Sarup suggested - It'd be good to have the option of creating an issue by just commenting, instead of having to go to an issues page and create one. This could be implemented as a 'mark as issue' checkbox when creating a comment.

  • Incorporate social features - including but not limited to - a public project gallery, a stars/rating/voting feature.

Each project will have an option of being made public, and a stars attribute. Public projects will appear in the public gallery, and the stars rating will be displayed along with it. Projects in the public gallery will be sortable by various factors such as stars, creation date etc.

  • Improve the contributor experience.

The current documentation is indeed quite good (Thanks to Sarup Banskota's work) and has everything that a seasoned developer needs, but it can be made more beginner friendly. The first step would be to define a concrete development workflow. I'd also like to integrate with a continuous integration/delivery service such as Travis CI or Wercker and create a live demo that is in sync with the master branch.

The need you believe it fulfills

Nowadays, designers still use email/chat for feedback and store/share their work using tools like DropBox and SparkleShare. Neither do designers have the skill to use a service such as GitHub, nor do services like GitHub have what a designer needs - to be able to edit, view and get feedback on their work, and harness the power of version control.

GlitterGallery is an excellent answer to all these problems, and the changes that I'd like to make will help in bringing GlitterGallery closer to a production-ready application.

Any relevant experience you have

  • I've been contributing to GlitterGallery, and am familiar with the codebase. Up till now, my contributions have primarily been cleaning up code, writing tests, fixing small bugs, updating to Rails 4, and enforcing best practices wherever possible. I've also started a branch with a new design, and am collecting feedback on the same.
  • I'm well versed with Git, and understand the power and importance of Version Control.
  • I'm a firm believer in 100% test coverage. I learnt this the hard way when working on a project.
  • I've been working with Ruby on Rails for almost 2 years now. I've watched and understood every single RailsCast on railscasts.com (the free ones).
  • I am familiar with front-end development. Very strong in HTML/CSS, not so much in Javascript.

How you intend to implement your proposal

Implementation details are included in the Timeline.

A rough timeline for your progress

I'm going to split the whole coding period into 5 iterations, roughly 18 days each. Each iteration will again be split into 3 parts.

  • 5 days - Implement a basic functional prototype (Need not be user friendly, only criterion is that I can make the feature do what it's supposed to do.)
  • 8 days - Write concrete tests, refactor along the way.
  • 5 days - Focus on user friendliness. Answer some basic questions such as - "Is the purpose of this feature evident to a new user?"

Before coding period

  • Write tests for the existing code (I'm already working on this)
  • Refactor along the way
  • Fix any small bugs already listed on GitHub, and raise issues for any others that I find.
  • Discuss with my mentor(s) about the implementation details and suggested improvements.

Iteration 1 - Authentication Methods (May 19 - June 6)

  • Install the Devise gem, and the corresponding omniauth gems for OpenID, Facebook, Google etc.
  • If needed, alter the Users model.
  • Add corresponding choices in the login page. i.e. "Sign in with Facebook", "Sign in with Google" etc.
  • Provide an option for the administrator to choose the allowed authentication strategies.

Iteration 2 - Grit to Rugged (June 6 - June 24)

  • Replace the Grit gem with Rugged.
  • Move over all the existing code to Rugged, and improve upon the code if necessary.
  • Confirm 100% test coverage.

Iteration 3 - Issue Tracker (June 24 - July 12)

  • Create an Issue model. (An issue will contain a title, description, status, and will belong to both a project and a user)
  • Create an index controller and view for a project's issues, and controllers to show, edit and delete a single issue.
  • Display the number of open issues on the project page.
  • Allow issues to be created from comments. As mentioned above, this can be implemented with a "Mark as Issue" option in a comment form.

Iteration 4 - Social Features (July 12 - July 30)

  • Add the option for a project to be made public.
  • Add a stars attribute to a project, and display alongside the project.
  • Create a public gallery page, and allow the user to sort projects according to various factors such as the number of stars, Last updated time, and creation date.

Iteration 5 - Improving Contributor Experience (July 30 - August 17)

  • Integrate with a continuous integration/delivery service such as Travis CI or Wercker and setup GitHub hooks that notify the author of a commit if the build fails due to their commit.
  • Define a development workflow (preferably based on Github Flow), and add documentation for the same in the wiki.
  • Populate the wiki with information and references for beginners.
  • Add wiki pages that explain the purpose, implementation and usage of all existing features.

Any other details you feel we should consider

My Weaknesses

  • In general, design is not a very strong point of mine. For example, I'm bad at colors. Whenever I've had to work on the front-end of a website, the first thing I'd do is copy a color scheme off some good-looking website. I can recreate something using HTML/CSS/JS with pixel to pixel perfection, but when it comes to making something on my own - it ends up looking a bit 'out-of-place'. I'm more of a front-end developer, than a front-end designer.
  • I'm not from a CS background. I have taken a data structures elective at college, but some complex algorithms and implementations just go way over my head. Currently, I don't see the need of anything that complex in GlitterGallery though.
  • I'm not an active blogger. Blogging about my GSoC activities would be a perfect way to improve this.

Have you communicated with a potential mentor? If so, who?

Yes, Emily Dirsh.

Retrieved from "https://fedoraproject.org/w/index.php?title=GSOC_2014/Student_Application_rohitpaulk/GlitterGallery&oldid=372865"