From Fedora Project Wiki

Contact Information

NOTE: We require all students to blog about the progress of their project. You are strongly encouraged to register on the Freenode network and participate in our IRC channels. For more information and other instructions contact Org Admins.


Why do you want to work with the Fedora Project?

Because I liked the idea of their project Design/GlitterGallery as I've been looking forward to contributing to something similar to Github without creating a useless clone of Github. Once I saw GlitterGallery, I knew that this project is what I was looking for. I've also liked the community of GlitterGallery and I wish to be part of it.

Do you have any past involvement with the Fedora project or any other open source project as a contributor?

Yes. I've developed a web app for KDE that collects and displays reports about the activity of their projects[1]. I'm currently the maintainer of that project.
I've also sent a few PRs to some gems that I used and found problems with or improvements opportunities. I've even sent a PR to the Rails project.
I've also contributed to the GlitterGallery project over the past few weeks[2]. I've fixed bugs, added new features, increased test coverage and refactored parts of the code to use best practice.

Did you participate with the past GSoC programs, if so which years, which organizations?

Yes. I was a GSoC student with KDE in GSoC 2013 and GSoC 2014.

Will you continue contributing/ supporting the Fedora project after the GSoC 2015 program, if yes, which team(s), you are interested with?

Yes, I'm planning to continue contributing to and maintaining GlitterGallery after GSoC. I also hope to get involved with other parts of the Fedora project with time. Websites team seems the right one for me.

Why should we choose you over other applicants?

  • I believe I'm currently very familiar with the codebase. I've already submitted lots of PRs to GlitterGallery that got merged and that affected almost all parts of the project. Approximately 2k lines have been added/modified by me till now.
  • 2+ years of experience with Ruby on Rails and Git.
  • I have dealt heavily with Git repositories handling through rails apps in my project with KDE[1].
  • I love testing. I've actually submitted tests with all my modifications to GlitterGallery code. A large percent of the tests that reside in GlitterGallery's repository were written by me(and more is yet to come as I want to get to full test coverage before GSoC coding period starts.) I've learned the importance of testing by making the mistake of not testing the code I wrote at the beginning of my rails life so I know how bad it is to not test.
  • I know how to test complex projects. My project with KDE required mocking many services and preparing certain conditions for the tests. This introduced me to lots of gems used for testing and taught me lots of techniques for testing. Luckily, I used RSpec and Capybara which are used in GlitterGallery.
  • I know how to deal with version control. This doesn't only mean that I can design a good application for collaboration between designers, but also that I follow a good workflow in my contribution to the project, using the advantages of version control.
  • I try to follow best practice when possible. I've refactored some parts of GlitterGallery and planning to continue with that. This provides better code readability and easier modification. For example, I try to write a comment above each method I define and try to keep methods in their appropriate places.
  • I am planning to continue maintaining GlitterGallery after GSoC. I'm actually looking forward to becoming part of GlitterGallery's team.

[1] KDE Reports

[2] My merged PRs to GlitterGallery


Proposal

The problem

Lots of work has been done in the past couple of years to produce a web app that is similar to Github but intended for designers. The idea is that coders have lots of tools to help collaboration and coordination. On the other hand, designers don’t have much tools like that. They depend mainly on mailing lists for coordination which is not the best way. Designers need to have tools that would allow for better collaboration and coordination and thus would allow them to work more comfortably and open wider areas for inspiration and creativity. More comfortable designers would mean even better looking software which would make everyone happier. Work on the tool that would ease that, Glitter Gallery, has started but it’s not yet complete. We still have no running instance used in production.

The solution

It’s time to get Glitter Gallery ready for production and extend it with more features that would allow it to do what it’s intended for. I’d like to work on adding more features and improving the current features we have to get Glitter Gallery ready for production and attractive to designers. I’m looking forward to having a reasonable number of designers using Glitter Gallery as their tool for sharing and collaborating by the end of summer.

Benefits to the community

  • A ready to use web application that helps designers.
  • Ability to do your work locally then push to Glitter Gallery using Git without the need for the web interface.
  • Easy integration with Sparkleshare.
  • Public gallery so that everyone can watch the awesome designs without having to login with full control of who’s allowed to view and/or comment.
  • Better commenting system so that designers can get appropriate and detailed feedback on their designs to produce even better designs.
  • Enhanced view of the history of designs with discussions so that people can follow what happened and how the current design was reached.
  • Support Github hosted repos + Ability to integrate your project with an external bug tracker like Bugzilla and Github if you don’t want to use the internal issues.
  • A reputation system for encouraging users to participate and give opinions.

Bonus features

  • IRC Bot to announce notifications to certain channels and to do modifications through IRC.
  • Add support for Gists.
  • An admin panel for controlling Glitter Gallery in an easy intuitive way.
  • API to allow others to integrate with Glitter Gallery.
  • A simple Android application for Glitter Gallery.

Implementation Details

Modifications to the current app

First, I’d like to make some modifications to the current app to improve the code in general and follow best practice to ease further development and enhance maintainability. Some modifications include:

Achieve full test coverage

I have started -with the help of other contributors- working on improving the test suite of the app but we’ve not achieved full test coverage yet. I believe we’ll reach that before GSoC coding period starts though but if not, then this is the first thing I’d be working on and it shouldn’t take much time since the left untested part is not huge.

Fix broken features, try to enhance the code and upgrade to latest version of Rails

We’ve been working on this for sometime too and there’s a big chance that it’ll be done before the start of coding period. This generally means ensuring that all existing code provides some feature that’s fully working, so it involves cleaning some code, moving pieces of code to their appropriate place and fixing some bugs. Issues and pull requests are parts of the application that I didn’t write tests for yet. Pull requests feature seems to be incomplete so I’m planning to complete that. Also, I want to complete features suggested in this comment.

I also want to go through all links in the app and change them to use the link_to instead of putting a static link. These would be done in parallel with test coverage since each of them complements the other. After finishing those, I’d be upgrading the app to the latest version of Rails(currently Rails 4.2). Luckily, I’ve done that upgrade before so it shouldn’t be taking lots of time.


Adding new features

Public Gallery and well defined abilities

At the moment of writing, the app doesn’t have well defined abilities. This step involves using an authorization gem (Till now cancancan is my chosen gem) to define who can access what. This shouldn’t take a lot of time since I’ve worked before with cancancan in multiple projects and I know how to use it.

These abilities would be defined so that they allow unregistered users to see public projects. Currently, the app has something close to that. I’m referring to inspire but you can’t access it unless you’re registered which is not really what we want. This can be fixed easily in the current app but we’d still need a proper authorization system to handle everything efficiently.

When someone browses the gallery, he’d want to be able to sort the projects according to the number of followers or such factors. We might want to introduce another field to projects, something like a reputation system(more on that later). I’m thinking of also defining some way to measure the activity on a certain project to have a list like “hottest right now”. These would encourage more people to participate, create and give opinions.

Some users would want to allow anonymous comments and others would want to keep comments restricted to registered users or even prevent comments, or make comments not shown until they confirm. This would be an extra feature I’m planning to work on if things were done early and I became ahead of schedule where each project has a set of settings that users can control to their desire.

Better commenting system

This might be one of the difficult parts of the project. Currently, the app has a single Comment model that’s used to handle all types of comments. We’re not using polymorphic associations because some of the objects that are commentable have no models, for example: files and commits. I’m thinking of using tableless models and make use of polymorphic associations, this would anyways ease the use of gems and introduction of pingback support. There is also need for supporting threaded comments.

I’ve done some research to find suitable gems to help achieve a nice reliable commenting system. There are a lot of options:

For pingback support: The best option I found till now is Socialization gem’s mentionable. Other features of Socialization gem can also be useful. We already have following functionality. Switching to a gem seems like a good choice for me. Discussions with the mentors can lead to a final and better solution. It is also possible to have Github similar editor for comments with support for mentioning using jquery-atwho-rails.

For threaded comments: I’ve recently added a “Fork Network” feature to Glitter Gallery. This was introduced using Ancestry gem. Just as it was applied to Projects, I can apply it to Comments and thus be able to show threaded comments. I prefer to use gems when possible though for everything, especially when the gem is actively developed. acts_as_commentable is most famous solution for a comments system. However, there are other solutions that can be used in our case, acts_as_commentable_with_threading is acts_as_commentable with support for threading. Another cool gem I found the_comments. I find that one cool because it adds the functionality of reviewing comments before they’re added which would be useful for controlling comments on public gallery. Till now my choice is acts_as_commentable as it seems the most reliable and we can extend it to our match our needs.

There is also the need to support referencing a specific region of an image in a comment. For the backend, I’m thinking of having a model ImageRegion for example that holds a number, type, starting pixel, width and height of the region; Or the radius of a circle. A comment has_and_belongs_to_many image_regions and thus we can simply add and retrieve referenced regions. Javascript can then be used to allow commenters to specify the region of the image they want to reference and using an AJAX request, an ID for that region gets inserted in their comment. I’m not yet sure if it would be better to have predetermined regions for each image or allow the users to select any region freely(within regular shapes restrictions) and a new ImageRegion is added. Need to get input from my mentors and designers to know what would be more comfortable for them. For showing the referenced regions of the image, I can also use Javascript so that when a viewer hovers over the special ID in the comment, he sees a marker around the specified region or the rest of the image is faded so it’s more clear.

Enhanced history view

It’s possible to write comments on almost everything in Glitter Gallery. One of these things is the files. An improvement I’ve introduced in the past period is the ability to view the files that were added/modified in a given commit. A commit can have comments, I’m thinking of displaying these comments(at least only the root ones with the option to expand) within the log of the project that shows the commits.

Since our log shows full commits, which can contain changes to multiple files not just a single file, I’m thinking of introducing another type of history; That is, the file history: A view where you can see the different versions that the file had with the commit sha under each one and show comments on each of these versions. This history wouldn’t be something easy to add as there isn’t any efficient method to bring up the history of a certain blob using Rugged. We’d have to go through the full list of commits and see if it has touched that file or not but I don’t think this would cause a big performance issue. I’m thinking of using gitlab_git gem, it uses Rugged and still does the same thing under the hood but with some optimizations. I think we might need to use more of its functionalities later in the project so it might be better to start using it but this is to be discussed with the mentors.

What I mean by a “file history”: https://github.com/glittergallery/GlitterGallery/commits/master/README.markdown

We’d just have comments in between those.

Another thing that is to be added to the log view and the history view is the ability to get the diff between two commits or files. Showing diff for images is not like showing diff for files. For this, I find design-with-git gem that was suggested by Sarup very suitable.

There are a few points that need to be discussed, whether we should show comments by default or hide them and show some button under the commit that fetches them using AJAX. For this it might be a good idea to start with that simple button idea but later introduce some option in user settings that allows the user to choose whether to see the comments directly or not. If we want to give more control, we can allow that options to be specific/project. Anyways, I prefer to start simple and extend later after we finish everything else. Another thing to consider is how to order the history, from oldest to newest or the other way. It would make sense to show history from newest to oldest to see the final version at the beginning, but to follow the discussion and the progress, it might be easier to view oldest first. The best thing to do in my opinion is to provide both. A simple dropdown menu to switch between the 2 modes can be helpful and we can later extend that to set a default value or remember the latest selected one for each user.

Support Github hosted repos + Ability to integrate your project with an external bug tracker

After providing local repo support, we might still want to give users the choice to host their repositories on Github while using Glitter Gallery to browse, comment and rate. There are 2 ways to go about this. The first one is to keep a bare clone of the repos hosted on Github and do a git pull before every request to a resource in that repository. This would prevent us from having to deal with Github’s rate limit but it would take extra resources. The other way is to use Github’s API to fetch information on request; This would save resources but we’d have to deal with Github’s rate limit. The rate limit for most resources is 5000 requests/ hour for each user. I believe this would be enough but we’d have to ask all users to use OAuth and get a token for each one to allow them to view Github hosted repositories. I think all designers would have a Github account so it might not a big issue. For me, I’d go with the option of using Github’s API and asking the user for OAuth using Github only if he tries to access one of the repositories hosted on Github. github_api gem is what I’m planning to use if we choose the option of Github’s API.

Glitter Gallery has an internal issues system. For each project, there’s a section for issues where you can report a new issue and tag it as a bug or a feature. This system would be improved by the updates to the comments system(pingback support, improved editor and referencing certain parts of images.)

Also, I’m thinking of using acts-as-taggable-on gem to allow for better tagging on issues; We need to have labels, milestones and status so a gem like that can be of much help. I think we should also support assignees for the issues.

With these improvements and others that could be requested by the community, the issues system would be attractive to use but some teams who consider switching to Glitter Gallery might already be using a bug tracker like Bugzilla. That’s why we still want to support integrating projects with external bug trackers. As a starting point, I’d like to add support for Bugzilla. Luckily, I’ve used Bugzilla’s API for a long time. I’m very experienced with it, especially with the fetching of data part. I’ve already used the API to fetch list of bugs and show them(with pagination) and to fetch a certain bug with its comments. I didn’t use the pushing of data part before but I’ve read about it and I believe that it wouldn’t be of any problem.

We might also want to support Github issues although I believe it’s better to have all the needed features in our issues system and no one would need to use that integration. However, I’ve read parts of the API and am willing to work on providing that integration if it’s needed. It isn’t much different from Bugzilla’s API.

A reputation system

This is one of the important features in my opinion. We want to encourage people to participate and give their opinions which would help produce better designs and encourage designers to give more. After providing the essential features for this app to be used for sharing designs and doing what it’s intended to do, the next step would be to add the feature of giving a quick opinion about projects and files. If we use the socialize gem as I suggested before, we would have the like module but I’m thinking of a more complex system. I’m planning to use activerecord-reputation-system to build a strong reputation system. First, I’m thinking of making almost everything reputable, though with different options. For example, comments and issues can only be upvoted and downvoted. Blobs and projects can be rated on a scale from 1-10 for example. I’m thinking of also giving each user some attribute like contributions that are determined based on the ratings their work had received and the upvotes for his comments and issues. I’d have to discuss more about what needs to be the final result here with the mentors and the designers to arrive at something that’s as efficient as possible. This is something that I’ve never built before so it might be a little challenging but I expect it to be beautiful when produced.


Timeline

I believe I’d always be ahead of this schedule as I’ve developed some new features in a short period for Glitter Gallery while I was in college time. During vacation, I can work for longer periods and I wouldn’t have anything else to do so I believe I’d be able to implement features quicker. For this reason, I’ve added the Bonus features, so that if I finish earlier than expected, we can bring the most important features from those bonus features and I can start working on them. I’m also expecting to receive suggestions from the community, which would have higher priority than my ideas.

4 April - 27 April Continue to work on the app during my free time adding tests, refactoring code, fixing bugs and completing simple features. Some exploration of gems and possible choices and features.
28 April - 24 May Discussing with the mentors and the rest of the community the best choices in the features and trying to have a definite structure of all the new options and features. Continue work on adding tests and refactoring code.
Coding period:

25 May - 31 May

Continue any refactoring and testing that’s not yet complete.
1 June - 7 June Finalize all refactoring, testing and completion of old features.
8 June - 14 June Start working on the production local repo support.
15 June - 21 June Finish the local repo support with security and hooks set.
22 June - 25 June Adding instructions to the app for integration with Sparkleshare and handling any problems that may arise with the integration.
26 June - 3 July Midterm Evaluations. Use this period to get feedback from the mentors and community about the work done so far and what could be done to make the process better. Also, inviting the designers community to start working on a project using Glitter Gallery as it should be ready for use at this point.
4 July - 10 July Defining abilities(might be completed while refactoring), introducing the public gallery and start working on better commenting system.
11 July - 17 July Finish the commenting system. If there’s extra time, write tests for the history view.
18 July - 24 July Implement the enhanced history view.
25 July- 31 July Support Github hosted repos + start Improving the existing issue system and adding the possibility of integration with Bugzilla and Github issues
1 August - 7 August Finish the integration and start building a reputation system.
8 August - 16 August Finish the reputation system and any remaining part.
17 August - 20 August Pencils down - Writing any needed documentation for parts that need such documentation and fixing any minor issues.
21 August Final Evaluations.
28 August - 15 September Showing the final project to the community asking for ideas to improve it or changes they want to see. Discussing next steps

After the project is released, I’d keep monitoring its behavior and performance, helping designers get used to it and making improvements requested. I’d work on fixing unexpected bugs and adding features that I see need for.

I’d try to keep the community updated with my progress most of the time so as to keep the project meeting the community’s needs. I’ve set up a blog and I’m planning to write in it about my progress during the program: https://ahmedabouelhamayed.wordpress.com/tag/fedora/

I’d also try to keep the design community updated through periodic messages to design-team list.

Retrieved from "https://fedoraproject.org/w/index.php?title=GSOC_2015/Student_Application_aaboouelhamayed&oldid=408422"