AliVE Terms of Reference

h1. Terms of Reference

h2. Background

Multi Session Operations (MSO) aimed to create a dynamic, living environment in which the player could take part in persistent missions across multiple game sessions including server restarts (equivalent to MP save games). It provided the flexibility to deploy on operations in various tactical situations with the minimum of input by the mission maker. It also catered for different game types including TvT, Coops, small teams with AI or large milsim groups whilst also delivery the support assets required for long term ops, such as Offensive Support, Logistics and website data reports for AARs.

Whilst we learnt a hell of a lot creating MSO, it grew into an unmanageable beast with lots of little offshoot projects that were never properly integrated. We spent as much time regression testing as we did developing new content - the infamous 'code soup'. ALiVE is a completely fresh start with clearly defined goals, strict coding standards, enforced discipline to stick to the agreed roadmap and ensure everything we deliver is properly integrated and as efficient as we can make it. In short, a 'professionally' managed development project.

Our mission remains to create a system that brings ArmA3 to life with the minimum of effort by the mission maker. Key concepts are an intuitive, easy to use, modular system, seamless integration and massive flexibility.

h2. Objectives

• Deliver a good quality mod that is easy to use, with regular updates and regular tangible improvements.
• Agreed Release Schedules to help focus our limited resource on +finishing+ modules that contribute to a release state that gives ALiVE the maximum publicity at key times.

h2. Design Decisions

Critical design decisions already made to save us having to go over them again (though that doesn't mean we can not or should never revisit them) including the impact of these decisions (see Design Decisions).

• Centralised DB using CouchDB (possible options for local DB for some modules)
• Profiles vs Caching
• Pre-defined vs Dynamic Objectives (The Altis Issue)
• Scripts vs Addon
• A2/A3 Support
• Object Oriented SQF

h2. Rules of Engagement

• Direction is determined by team consensus and we stick to the priorities agreed.
• There is a healthy respect for length of service and actual work done that determines weight of "vote".
• We are a laid back bunch and we work very hard to avoid dramas. If we disagree, we park it until someone else can mediate.
• We all have commitments and that is respected. There's no pressure around deadlines.
• We are not in it for the money, competition or BIF fame. We prefer to help other community mods however similar they may seem are to ours.
• We pride ourselves on being helpful, polite and prompt in our support channels. Everyone mucks in (but tag is a legitimate support methodology).
• Code/work committed needs to fit with existing plumbing and respect the work of others.
• We have a vast amount of combined experience but no single one of us knows it all.

h2. Contributors and New Team Candidates

Various levels of participation. Only full team members have a vote in the overall direction of ALiVE. Core team hold project management roles.

• Consultants & Closed Testers - Non-code contributing folks that may do a number of things for the mod (testing, art, military advice, models etc)
• Associate Code Contributors - Typically new developers or developers that simply want to donate code to the cause.
• Associate ALiVE Module Developer - Developer that has agreed to contribute and continue to work a specific module
• Full Team Member - Developer or other role working on the mod longer than 3 months
• Core Team Member - Developer or other role working on the mod longer than 6 months and with a specific responsibility.

Important concepts that prospective contributors and team members must understand:

• Any code submitted to the ALiVE codebase will be considered wholly part of ALiVE, subject to the same license and owned by the ALiVE mod team.
• Understandably everyone has their own pet project but we will stick to the current roadmap and inject fresh ideas at the appropriate time.
• All ALiVE code must be maintained in the official ALiVE code repo and no separate public code repos created (definitely not publicly available code repos), so we can maintain governance and control the maint & support of our codebase during development.