- Table of contents
- Justification
- Development process
- Conclusions
- References
Justification¶
Scope¶
The openSUSE Travel Support Program is sponsored by SUSE but managed independently by the openSUSE community by means of the Travel Commitee. The main goal of this project was to create a web based application to manage the requests and reimbursement in a convenient way.
Since other free software organizations (like GNOME, KDE or the Document Foundation) have similar programs, the original idea was to write a generic application including all the common features in order for it to be used, extended and adapted to fulfill the needs of any organization.
Functional requirements¶
The functional requirements can be summarized in three main goals:
- Close control over every single request and reimbursement with clear information for every involved person.
- Information about the status of the process.
- A well defined process and interface for applicants, committee members and administrative staff.
- Email notifications of any change and when some action is needed.
- Email reminders if a particular request or reimbursement gets stuck in the same status for too much time.
- Good management of the program as a whole, both from an operative and from an economic point of view.
- Fully structured information.
- Useful reports.
- Fixed or approximate budgets per period or per event, both as minimum warranted available amounts or as maximum limits.
- Working as a stand-alone application but with an optional integration into the existing openSUSE infrastructure
- Integration into the openSUSE authentication system
- Bidirectional integration with openSUSE Connect
Technical requirements¶
From a technical perspective, the main requirements were:
- Full functionality available through web interface and through a REST json API.
- Themeable and responsive web interface.
- Flexible user system with pluggable backends (so the application can be integrated in previously existing users infrastructures).
- Robust control over information access and full log of information modifications.
- Fully documented with information automatically generated from the source code (diagrams, API documentation, etc.)
- Good tests coverage.
Development process¶
Milestones and tasks¶
Following and iterative and agile approach, the project was divided into several milestones which are summarized below:
- Requirements capture and initial documentation
- Document the requirement meeting: issue #215.
- First prototype with the basic workflow
- Implementation of the general infrastructure: issues #105, #121, #122, #123, #211
- User management and access control implementation: issues #104, #106, #108, #109
- Request process implementation: issues #111, #113, #114, #115, #116
- Reimbursement process implementation: issues #117, #118, #120
- API and code refactoring: issues #196, #245
- I18n: issue #125
- Documentation: issues #126, #127
- Deploy a test-drive installation: issue #246
- First finished version with basic workflow
- Fixes to requests, openSUSE integration and deployment
- Landing page with user guide: issues #253, #371
- Enhancements to the request process: issues #107, #112, #327, #329, #330, #366, #340
- Audits, full log of information modifications: issue #256
- Support for invitation letters management: issue #370
- Added "final notes", to allow feedback on finished (canceled or accepted) requests: issue #254
- Importing profile information from openSUSE Connect: issue #333
- Bento theme: issue #332
- Integration with openSUSE login system: issue #328
- Deployment on openSUSE infrastructure: issues #331, #335, #365
- Support: post-deployment fixes
- Only one task was needed. Add request creation deadline to events: issue #424.
- Reimbursement polishment
- Reports and alarms
- Corner cases and alternative workflows
- Request from Travel Committee members
- Payment in advance (as opposed to reimbursement)
Achieved goals¶
The application has been successfully used to manage the request process for the openSUSE Conference 2013, with 15 accepted requests from a total of 24 and with no reported bugs, issues or complaints from any user. The reimbursement period for this event starts at July 22th. Although the request process worked smoothly, the reimbursement one is way more complex from both technical and administrative points of view, so the final result cannot be evaluated until the reimbursement period is over.
Regarding the functional goals, all of them have been achieved to a great extent, although some functionality is still missing.
- The tool provides a close control and accurate information for every single request and reimbursement for all involved users, with email notifications of every step. Email remainders about stuck operations are not yet implemented, but already planned in the currently open milestone.
- Good management of the program as a whole is also granted, with fully structured information and a very flexible expenses report with several filters and grouping options and with the possibility of exporting the result to a spreadsheet. Soft and hard budget limits per period and event are not yet implemented.
- The application can work both stand-alone and inside the existing openSUSE infrastructure
All the technical goals have also been met.
- The web interface is fully functional and the REST API has been completely developed. The latter could need some refinement in the future, since it have not been used in a real production environment.
- The themeable and responsive web interface is based on Bootstrap, the most widely used framework for web front-end development. The interface was developed in a very generic way so it should be really easy to extract a "bento" theme for Bootstrap from the current TSP app allowing to theme any Bootstrap based application according to the openSUSE look&feel.
- Devise, the most widely used system for user authentication in Ruby on Rails, was used to ensure connectivity. An openSUSE backend was developed. So integrating future Ruby on Rails applications into the openSUSE authentication infrastructure should be almost trivial.
- All the database changes are logged by the application.
- 85% of all classes, functions, methods and modules are fully documented (according to yardoc, the tool being used for generating the documentation).
- Automated test have been developed for most of the functionality, including unit tests and integration tests.
Pending issues¶
The development is not over yet.
- Some minor issues still needs to be closed in order to finish the two open milestones.
- As exposed in the "achieved goals" section, there is no interface yet for specifying budgets and limits for events or periods.
- The definition and implementation of the milestone titled "corner cases and alternative workflows" will be probably delayed until the end of the openSUSE Conference 2013.
On the other hand, some generic tools and libraries have been developed during the process, like the Bento theme for Bootstrap or the openSUSE backend for Devise (both mentioned in the "achieved goals" section). Some work should be invested in extracting them as individual projects with its own documentation in order to be really reusable by other people in other projects.
The people in charge of the GNOME’s Conference Travel Subsidy Program are currently evaluating the tool as they have very similar needs. We are waiting for feedback from them.
Resources¶
The whole project was developed by only one programmer. Chiliproject was used to track the development effort. The table below shows the approximate number of hours invested in every milestone, according to the information registered in chiliproject with some manual adjustments. The table does not include administrative tasks like writing reports or managing the chiliproject issues.
| Milestone | Hours (aprox.) |
|---|---|
| Requirements capture and initial documentation | 8 |
| First prototype with the basic workflow | 68 |
| First finished version with basic workflow | 14 |
| Fixes to requests, openSUSE integration and deployment | 61 |
| Support: post-deployment fixes | 2 |
| Reimbursement polishment | 31 |
| Reports and alarms | 22 |
| Corner cases and alternative workflows | 0 |
| Total | 206 |
A considerable amount of effort has also been invested in promoting the tool: presentations, blog posts, test-drive installation for the GNOME project members, etc. This effort is not considered in the current report.
Conclusions¶
References¶
Updated by ancorgs over 10 years ago · 36 revisions