The project charter serves as a high-level yardstick for the continued development of Project Phoenix. We are going to measure new features and development practices against this yardstick.
### Driver
Project Phoenix is a modern, adaptable, and easy-to-use API offering essential functionality for prototyping, developing, and deploying cutting-edge VR applications.
### Constraints
We acknowledge the following constraints:
***manpower** for infrastructure development is scarce
****average*****proficiency** is limited by 'time on the job'.
### Floats
The main float of this project is its **scope**, i.e. the amount of features that go into it.
Hence, we aggressively triage features based on *value added*.
We *prefer doing few things very well rather than doing many things mediocrely.*
This is how we read *essential* in the driver.
To a lesser extent - see risks below - **time** is also a float: Project Phoenix has to reach a first usable status ASAP. Yet, we rarely have to deliver a feature *f* at quality *q* by date *t*.
We manage ***individual*****proficiency** by continuously
* giving room to improve *software craftsmanship*,
* giving room to acquire highly specialized knowledge,
* supporting technically focused team spirit.
### Main Project Risks
* Time to Market - We will loose developer support exponentially the longer it takes to deliver a minimum useful feature set.
* What is the minimum useful feature set?
* How fast can we possibly get there?
* Project Overload - Daily business, research work, teaching responsibilities, and infrastructure development are difficult to reconcile in a 24h day.
* Feature Creep - Lacking focus on essential functionality will result in code rot.
* Lack of Discipline - By [*the broken window theory*](https://en.wikipedia.org/wiki/Broken_windows_theory) lacking adherence to coding practices and quality standards will lead to code rot.
* Quarreling to no avail - Hypothetical arguments based solely on subjective opinions rather than solid facts and/or experiments cost valuable time, create friction, and blur focus. Keep the emotion out of your pitch!
* The VR landscape is changing rapidly. - We might get overtaken by the world at large.
* Consumer VR hardware
* Consumer VR market, i.e. end user applications, games, game engines etc.
* New rendering modalities (ray tracing in Optix, OSPRay)
* Legacy code base - A trivial 'forward-copy' of existing code fragments will not be sufficient to achieve our driving goal of a modern, easy-to-use code base.
