GSOC 2015/Student Application ahmedsaleh

• Name: Ahmed Saleh Abdelwahab
• FAS Account: ahmedsaleh
• Fedora userpage: https://fedoraproject.org/wiki/User:Ahmedsaleh

Contact Information

• Email Address: ahmedzaleh7@gmail.com
• Blog URL: http://www.ahmedsaleh.me
• Freenode IRC Nick: ahmedsaleh

Why Fedora?

I'm an open source enthusiast. I have been using Linux for over 3 years now and I use Fedora as my main operating system. So I wanted to contribute to open source through something that I like and I use daily which is Fedora.

Open source contributions

I have contributed to some open source projects that serve the community or part of the community we're living in. My first project was Bdaya NGO Admin System http://bdaya.org/systemrelease/ which is an Admin system for organizing work in NGOs. The second project I'm very proud of is Faselty Blood Donation System http://beta.faselty.me/ which is blood donation network where donors can find donation requests and those who want donors can request on the system.

Previous participation in GSoC

This is my first time to participate in GSoC.

Contributing/supporting the Fedora project after the GSoC program

I'm willing to contribute to the Fedora Project. I'm very interested in working on the main Fedora OS. For teams, I' would love to join SIGs like Gnome SIG and Ruby SIG. I also think about joining the Fedora Localization Project.

Why should you choose me?

I'm an open source enthusiast. I love contributing to open source projects and the main goal/idea of FLOSS which is to share knowledge. I have 1 year of experience in Ruby on Rails web development. I worked on some open source projects that serve the community or part of it such as Faselty Blood Donation System and Bdaya NGO Admin System. I have some experience in Inkscape which I use for designing logos. I love solving problems in competitive programming contests. I participated in ACM ECPC in 2014.

Glitter Gallery Proposal

Motivation

In 2005, Linus Torvalds wrote Git as an VCS to maintain Linux kernel project. Because it was hard to use Git, in 2007, GitHub was created and made it easier for developers to host and manage their code using Git. In 2014, GitHub reported that it has over 16.7 million repositories of code which makes it the largest code host in the world. GitHub is so great for developers but as for designers, it's so difficult to track changes in their files. GlitterGallery aims to be the place where FLOSS designers can maintain, review, and share their designs with the community.

Project Goals

• Clean UI/UX.
• Gallery for popular public projects.
• Browsing project files easily.
• Robust Commenting System.
• Integrating Sparkleshare.
• Tracking File History System.

Implementation

Clean UI/UX

A place for designers must look and feel awesome. My main focus is on the user experience part where the user can find what they want easily without the need to open new pages or tabs. I have created some mockups using inkscape. I'm not a designer in the first place, so these are just mockups to demonstrate the idea, but the actual design can be agreed on with the team:

• Gallery for popular public projects:

Viewing the most popular public projects on the system. We can view them based on the number of views or ratings. [1]

• Browsing project files easily:

Projects normally contain more than one file, so it's tedious if we want to view these files and they open in a new page for each one. I think viewing them in the same page makes it easier to browse the project. The page will be split in two; one for the project files and the other half is where the file is previewed. [2]

• Robust Commenting System:

The current commenting system requires the page to be reloaded to see the new comment. So some Ajax (Javascript) is needed to update the comments without reloading (live-update).

Integrating Sparkleshare

The main goal of using Sparkleshare in Glitter Gallery is to sync projects automatically without the need for the user to add/commit/push their changes from the Terminal. Using this kind of syncing makes it easier for designers to create more projects and encourages them to use Glitter Gallery. The most convenient way for us is to ask the users for their Sparkleshare Public Key and connect them to their remote folder in Glitter Gallery server as explained here https://github.com/hbons/SparkleShare/wiki/Using-SparkleShare-with-Github-Repos .

However, this goal still needs more research especially that it requires the user to have Sparkleshare on their local computer.

Tracking File History System

It's so vital to have a tracking history system that

• tracks changes in a file displaying changes by date.
• can revert back the current file to a previous version if needed. We can do this by putting the desired version as the current version of the file.
• has the ability to comment on each version of the file (each change).

My current vision for tracking and restoring previous versions of a project is that we store each version in a folder named by its push date then we can parse the folder name and retrieve the version we want.

This feature should be done after integrating Sparkleshare into Glitter Gallery.

Again, it's much easier to view everything in one place rather than opening a new page: [3]

Timeline

April 24 – May 25

• Familiarise with the current Code. Discuss with the mentor all the details needed before beginning writing code. Establish regular communication with mentor and setup meeting schedules. Setup project blog to monitor progress. Speeding up to code.

26 May – 30 May

• Discussing the design with the team.
• Setting the final design.
• Making Sketches for the first half goals.

31 May – 20 June

• Start coding the UI/UX related goals; Gallery for popular public projects, Browsing project files easily, and the commenting system.

21 June – 28 June

• Finishing the UI and fixing bugs.
• Writing Tests.
• Asking the community for feedback.
• Start working on integrating Sparkleshare (researching/asking/discussing).

29 June – 2 July

• Getting ready for mid-term evaluations.

July 3 – Midterm Evaluations

• Mid-term evaluations deadline.

4 July – 20 July

• Continue Working on Integrating Sparkleshare.
• Writing Tests.
• Asking the community for feedback.

21 July – 5 August

• Start Working on the Tracking File History System.
• Writing Tests.
• Writing documentation.

6 August – 12 August

• Asking community for feedback.
• Fixing bugs.

13 August – 27 August

• Improving documentation.
• Polishing the code.
• Getting ready for the final evaluation.

August 28

• Final evaluation deadline.

After final evaluations

• Asking the community for feedback.
• Release testing.
• I'm so committed to FLOSS community that I would like to continue working on Glitter Gallery after GSoC and the three months period.