GSOC 2013/Student Application Jonathanhindi

• Your name: Jonathan Hindi
• FAS Account: jonathanhindi
• Fedora userpage: https://fedoraproject.org/wiki/User:Jonathanhindi

Contact Information

• Email Address: jonathan.hindi [at] gmail [dot] com
• Telephone: +201111621607
• Blog URL: http://jonathanhindi.wordpress.com/
• Freenode IRC Nick: JonathanHindi

Application

Why do you want to work with the Fedora Project?

Fedora is one of the few successful linux distributions, I believe in Open Source philosophy and would like to support and contribute, I believe that Linux should be used by everyone, Fedora is not just a project it's a great community which is the most important in my opinion, I believe that the community is the core of any successful open source project. I am willing to gain some real life experience and meet new people and make friends from the fedora community, I am new to the community but I love new experiences. Getting involved in such a successful open source project is a life milestone to begin my professional life beside the satisfaction i'll get while contributing back to the community who helped me at the beginning.

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

I don't have any past involvement in Fedora, But I contributed to Ubuntu by reporting bugs, suggesting translations, contributed as part of the LoCo team Ubuntu Egypt by creating some needed artworks, building the team website, gave some web development sessions and co-organized public events and team activities.

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

No I didn't, It's my first year to apply.

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

Yes, I am interested to contribute in the Marketing Team or Website Team, I would be also interested to maintain the project idea I am applying for.

Why should we choose you over other applicants?

• I am eager to learn new web technologies.
• I am willing to invest my next vacation learning and building a new application which will help others (The main motivation for me is to help others).
• I will keep contributing to Fedora after the end of the Program.
• Increasing my experience in Web Apps development is my career objective.
• I have experience in Web Design and User Experience, I follow up with all recent web technologies and try to use some of them in my projects.
• I have a good financial background, as I am a Business Information Systems student.
• I have been using linux since June 2006, and I believe in this operating system and I will keep recommending it to all my friends.
• Experienced in building MVC web apps.

Proposal Description

Proposal Overview

The project idea "Fedora Financial System" can be used within the project to track and analyse the financial activities for FAms (Fedora Ambassadors), Managing Fund Requests, Receipts, Budget Proposals and generating financial reports. In this system we will try to implement the current financial process for fedora ambassador described below in respect to standardization between regions that will give Fedora Ambassadors Steering Committee (FAmSCo) a cross region reports generation.

Current Financial Process

To ask FAmSCo for budget is necessary to complete the following steps:

• Have organized/structured the event or the events that are you going to do.
• Estimate costs supported by receipts or buy orders.
• Update your user page on the Fedora wiki to make sure you are working for the project.
• Have a PayPal account (other options are available) to receive the money.
• Log in with your FAS Account on FAmSCo Trac.
• Create a new ticket.
• In the body of the ticket, explain in details the reason of the budget request. This must include to which events the budget will supply and what impact these events would have to Fedora project. Also, detail where the budget is going to be spent and attach all receipts and buy orders.
• Assign your region, the component "Budget" and the required amount.
• Create the ticket and wait for some member of the FAmSCo team to value it.

If you were approved, you will receive the money depending on the decision you and main contact of the credit card decided. Else, you must rewrite your ticket to see if they reconsider sending that money. Source

Then the current Reimbursements Process.

From the above process, a lot of steps and tools were used and here comes our role to create a standardized and all in place process for FAms to request funds, report budgets and for Budget Owners and FAMSCO (any other administrator) to be able to monitor, approve and generate reports.

The need I believe the project fulfils

• Track Cash Inflows and Outflows.
• Allocate Budget for each region.
• Generate reports and managerial level data which will help Budget Owners to allocate the right budget for next year.
• Help Fedora Ambassadors to easily request funds without following a long process, also give them the option to track approval inside the same system.
• Save evidence (receipt) in one place for easier reference.
• Replaces many Trac installations for every region with a centralised system for cross region reports generation. (Old Process).

Relevant Experience

I am a Business Information Systems Student, I have a good background in business specially accounting and finance from college. Firstly started with web design then web development since 2007, created many small websites that were static at the beginning, then built many dynamic websites using some CMSs (Joomla, Wordpress and Drupal). I am maintaining some examples in my resume hosted here.

I have a good programming knowledge specially PHP since 2008, I love to follow the best practices for each language I use, I adore keeping myself updated with the latest technologies and features.

I am currently creating my graduation project with laravel 4, unfortunately I don't have it in a public repo right now.

This is my first financial or accounting system, but not my first web app, I believe that I have the set of required skills that will help me to implement my proposal.

How I plan to implement the proposal

Below is a brief information about the system implementation and core features from the requirements, For the detailed information check this Wiki Page. I am planing to learn more about how we could improve the implementation to be more solid and reshaping the requirements with my mentor before the Code Start period, Check the timeline for more detailed information. As "This is a live system so we will not be clear 100% about the requirement" quoted from Buddhike Kurera

I will be using Laravel 4 which comes with an MIT licence which is GPL compatible.

• Strong Community
• MVC Framework
• Composer Friendly. Can get multiple packages from Packagist.
• Strong ORM, Called Eloquent.
• Database Migrations. Simple Version control for Database Structure.
• Come in handy with a built in CSRF protection.
• Can force HTTPS on all routes or specific routes.
• RESTful ready, Helps creating RESTful controllers, routes, resources.
• JSON packed in, can return JSON, and auto detect requests types (If JSON will auto parse it, If normal form submissions will deal with it normally to capture the inputs)
• Backed by many Symphony2 components.
• All components are Unit Tested.

Note: I can't list all laravel features, I am only listing the features that will help us in our system.

Definitions

• Regions - Fedora Ambassadors are divided into regions (APAC, EMEA, NA & LATAM).
• FAm - Fedora Ambassadors are the representatives of Fedora. Ambassadors ensure the public understands Fedora's principles and the work that Fedora is doing.
• Budget Owners - Every region have a Budget Owners who determine budget limit and approve fund requests.
• Double Entry Accounting System - In a ‘double entry’ system each value is stored twice, once as a credit, once as a debit.

System Core Features

The system will have five core backends (Access Control, Double Entry Accounting System, Fund Requests, Budgetting & Reports Generation) which is the core for all the needed front-end features, most of the described core modules below will have their own data models and controllers to conveniently interact with from the front-end.

• Access Control: (To authenticate users, allow them to do certain actions according to their roles and assigned permissions.)
  • Fedora Account System Integration (FAS)
  • Roles: We will create roles to be able to determine if that user have the right permission to perform a specific action, FAS Build-in roles will be applied here.
  • Permissions: Permissions is a set of actions which maybe shared by one or more Role(s).

• Double Entry Accounting System: (Module to record journal entries associated with accounts which reflects the paper double entry accounting system in a relational database).
  • Transaction Types:
    • Deposit: Will be used when the Budget Owner allocates budget.
    • Withdrawals/Payments: Will be used when the FAm attach the receipt to an approved Fund Request, to create the needed journal entries.
  • Accounts: Accounts to be used in any journal entry (Cash Books, Region X Allocated Budget, Region X Expense)
  • Journal Entries: Journal is a representation for both debit and credit side of any transaction (Check Posting Below)
  • Postings: Posting is where the actual amounts are saved whether to the debit side or the credit side

Less Priority, Packing the Double Entry Accounting System classes into a Composer package and share on packagist for other PHP/Laravel developers usage.

• Fund Requests: (Module to handle Fund Requests by FAm and handle approval by Budget Owners, receipts attachments. Was handled by trac tickets in the old system).
  • Each fund request will have a status field (0 -> requested, 1 -> approved, 2 -> claimed, 3 -> reimbursed, disapproved).
  • Fund Requests creation by FAm (Status = Requested)
  • Fund Requests approval by Budget Owners. (Status = approved or disapproved).
  • Receipts or Evidence attachment by FAm. (Status = claimed)
  • Budget Owner will reimburse the evidence. (Status = reimbursed).
  • Receipts amount will be issued as a Journal Entry then updating the region account balance.

Note: I am trying to follow the current reimbursement process, The challenge is that the process is not standardized for all regions, But as my mentor mentioned that they will apply a new process or model. So the above could change according to the new standardized process.

• Budgeting: (Module to let FAm submit next year budget requirements and facilitate queries by Administrators.)
  • Budget Proposals
  • Budget Filtering (Type, Amount, Region)

• Reports Generation: (Pre-set reports to facilitate data extraction for system administrators and budget owners for high level managerial data or decision making and a JSON API for custom reports generation.)
  • RESTFul JSON API for Reports Generator - Will accept report types, custom fields, date periods and users.
  • Pre-set reports implementing the above JSON API. Less Priority (Backbone.js or Ember.js for report generations without page refresh).

System UI, Front End

• A consistent User Interface for all users.
• Rich UI elements, well tested and documented using Twitter Bootstrap UI Framework.
• Custom Twitter Bootstrap theming to match Fedora Branding Guidelines.
• Ajax powered in some sections like reports generation front end (If time permits).

Tools

• Git as a version control system.
• GitHub to push commits regularly.
• GitHub issue tracking system for bug reports and feature requests.
• Laravel 4, PHP MVC framework, with database migrations and strong ORM.
• MySQL Database (Can be changed anytime because Laravel support many database drivers).
• Twitter Bootstrap as a UI Framework.

Rough Timeline

I'll be using a mix of the iterative fashion development and prototyping techniques . It will allows me to manage my development stages and quickly prototype a working feature.

Weekly Process

• Define Requirements (e.g. Models, Tables, Controllers, Views, Database Migrations)
• Draw Mocks or Define Classes (According whether the work is in the backend or frontend).
• Communicate with Mentor to confirm Requirements, Mocks and Classes.
• Start Implementation
• Test and Communicate with Mentor for comments.
• Bug Fixes and Comments Enhancements.
• Code Refactoring/ Revisit
• Documenting & Blogging: Will be documenting and blogging challenges while implementing and then finalising the documentation after applying latest enhancements.

Notes:

• The above iterative process will give me the chance to communicate with the mentor at least 2 times each week.
• Will make sure that I don't waste a lot of time in a certain process.
• Give the chance to quick see a working prototype, then adding enhancements.
• I believe that shortest processes are always better than longer ones.
• The above will be applied after the coding start period.

Development Phases

The development will go through 4 Phases from end of May to end of September.

Phase 1: May 27 to June 16

• Community Bonding Period
• Study the Current or New Financial Process for Fedora Ambassadors.
• Determining System Flow, Processes and Use Cases
• Clear out any problems and choose the best solution from alternatives.
• Idea should be refined and clear now.
• Final Features Determination
• Learn how FAS works, (Study APIs)

Note: After this phase everything should be clear on how we are going to implement the project and ready to move to the implementation process.

Phase 2: June 17 to July 26

• Week 1: June 17 to June 24
  • FAS Integration - (Try to get FAS roles)
  • Setup needed roles connections (Between FAS and Our System)
  • Assign needed permissions for each roles.
  • Setting Region Data-models

• Week 2: June 25 to July 2
  • Developing Double Entry Accounting System Part 1
  • Transaction Types
  • Accounts

• Week 3: July 3 to July 10
  • Developing Double Entry Accounting System Part 2
  • Journal
  • Posting
  • Ensure that Part 1 and Part 2 works fine together.

• Week 4: July 11 to July 18
  • Fund Requests Module
  • Fund Requests Creation Interface
  • Fund Requests Approval Interface

• Week 5: July 19 to July 26
  • Receipts Creation (Attachment to Fund Requests) Interface
  • Receipts Reimbursements Interface (Queue and Approval)
  • Receipts Reimbursements Journal, Posting and Account Balances.

Note: Mid-term evaluation will be submitted from July 29 to Aug 2

Phase 3: July 26 to September 3

• Week 1: July 26 to Aug 2
  • Budgeting Module
  • Budget Proposals Creation Interface
  • Budget Proposals Management Interface

• Week 2: Aug 3 to Aug 10
  • Reports Generation Module Part 1
  • Building REST API
    • Account Types
    • Filters (Date periods, Users & Custom Fields)

• Week 3: Aug 11 to Aug 18
  • Reports Generation Module Part 2
  • Pre-set reports implementing REST API Part 1

• Week 4: Aug 19 to Aug 26
  • Pre-set reports implementing REST API Part 2
  • Twitter Bootstrap Theming Part 1

• Week 5: Aug 27 to Sept 3
  • Twitter Bootstrap Theming Part 2
  • UI Enhancements
  • Test & Fix Round 1

Note: Everything should be implemented now and ready for fixing bugs and code refactoring.

Phase 4: Sep 4 to Remaining

• Week 1: Sep 4 to Sep 11
  • Deploy to Testing Instance
  • Test & Fix Round 2
  • Code Refactoring & Cleaning

• Week 2: Sep 11 to Remaining
  • Fix Bugs
  • Complete Documentation
  • Package the System and Prepare Installation & Read Me Files.
  • Code Refactoring & Cleaning

Other Information

Mentors

Buddhike Kurera and Charindu Thiwanka, I already talked with Buddhike many times, Charindu was ccEd most of the time.

Miscellaneous Information

• I have a Spare Computer
• 95% Uptime Internet Connection, If it fails I am locating the near Co-Working places & cafes. My friends could help too.
• I have an ideal 3G Modem, Which I can activate anytime by phone, If Plan A didn't work.
• I will be pushing commits to Github regularly so if something fails we will be in the safe side.
• I am going to set a free testing instance on PagodaBox or OpenShift
• Timezone GMT+2:00, Cairo, Egypt.