Online Record Keeper/ORK3 Developer Documentation/Roadmap

This page documents the current roadmap for ORKv3.

High Level

• Implement a formal Release Process.
• Implement Unit Testing.
• Eliminate Bugs from Sarah Budai’s List.
• Replace yapo ORM with a more robust ORM implementation.
• Eliminate XSS and API SQL Injection bugs from API.
• Bring federation up to production-ready status.
• Change the entire underlying API interface from $request top-level parameters to the individual * elements of the $request structures.
• Implement version-controlled API publishing scheme.
• Finish Treasury User Interface and Backend.
• Finish Brackets portion of Tournament, including Glicko-2 stats.
• Implement an A&S Bracket-style in Tournament.
• Create a DB Administration UI
• Create a High-level Report UI which exposes all of the available handles for all the available Reports (customizable Reporting).
• Implement Calendar integration with Facebook and meetup.com.
• Implement the DataSet API.
• Finish Game API.
• Implement a Geo-Location-based search for Parks based on current client location.
• Implement a Peerage graph using Knight/Squire/Page Award information.
• Implement a Blazon to Heraldry converter.
• Split front-end from backend (implement actual federation).
• Mobile version of the site optimized for entering attendance.
• A Game site(s) implementing the Game API.
• A Fighting Tournament site implementing the Fighting portion of the Tournament API.
• An A&S Tournament site implementing the A&S portion of the Tournament API.
• Implement Caching.
• 3rd Party API logins.

Details

Implement a formal Release Process

The release process should follow a fixed development, testing, and production release process. In general, feature and non-critical bugs are released once per calendar quarter, as follows:

1. Development occurs on specific development environment for each developer.
2. Codes changes are merged nightly, or as soon as a stable update is available.
3. The testing server, qa.amtgard.com, is updated nightly.
4. At the beginning of the second month of each quarter, the staging server, staging.amtgard.com, is updated with the codebase released to the testing server.
5. Once staging is validated, the codebase from staging is pushed to production at amtgard.com

Critical releases follow this procedure:

1. Development occurs on specific development environment for each developer.
2. Codes changes are merged nightly, or as soon as a stable update is available.
3. Test critical updates server, critical.amtgard.com, is updated with the changes when available.
4. Once the crit server is validated, the code is pushed to staging.
5. Once staging is validated, the code is pushed to production.

Implement Unit Testing

All internal classes and external APIs should be Unit Tested.

Eliminate Bugs from Sarah Budai’s List

This is an on-going process, and should largely be prioritized over new features.

Replace yapo ORM with a more robust ORM implementation

A new XSS and injection-proof ORM should be implemented. Rollout will occur piecemeal, rather than as a single monolithic update.

Eliminate XSS and API SQL Injection bugs from API

The site should be audited and scanned for XSS and API injection exploits, and patched as critical releases.

Bring federation up to production-ready status

The Federation system should be brought up to production-ready status, and leveraged as the default configuration. The Authorization/IsLocalCall should be validated and fixed. The ORK primary interface should eat the same dog food we are asking all of our 3rd party users to eat.

This point also requires the correct implementation of Authorization/XSiteAuthorize(), or the implementation of an OAuth server.

Change the entire underlying API interface from $request top-level parameters to the individual elements of the $request structures

The current API is a parametric nightmare. All internal methods should be replaced with specific parameters in order to to eliminate the necessity of the 0-type Json API calls. The SOAP interface can remain static, or revised to match.

Implement version-controlled API publishing scheme

For each release, the API calls for that release should be locked in. 3rd party access to APIs should be via ///orkservice/<Revision Number or “latest”>/<Service>.

Finish Treasury User Interface and Backend

The double-entry code is complete, but untested. There should be two front-ends: a simplified front-end for basic tasks (adding, editing dues, check register for tracking funds), and a multi-account ledger interface for performing other accounting tasks.

Finish Brackets portion of Tournament, including Glicko-2 stats

Tournaments can be created, and I believe the bracketing is correct. The software should also provide an API and a UI for automatically generating brackets and then feeding matches based on data. The system will also track all historical matches for generating user performance stats using Glicko-2 or ELO. Seeded brackets will use user stats.