Community Projects

- Communication.
This is pretty much an overall key factor. Everyone should keep up the communication, we have these forums here, for more cooperative methiods between participants, other forms of communication such as IRC etc. may be useful, but the project participants should all be kept in the loop as to progress. The matter of communication is repeated in many points below with more specifics pertaining to the particular situation, reinforcing perhaps why it's so crucial.

- Time, Dedication and Reliability/Responsibility
Whilst a 'community project' is for the whole community to partake in, regardless of quantity or at the outset, quality, and there should be no exclusion from partaking nor should there be any pressure or necessities for any participant. A community project is an entirely voluntary project, HOWEVER, It is courteous at the least, to announce where possible, that if an individual or group of individuals decides to 'take on' a particular responsibility relating to the project, then they should inform the rest of the project participants of any constraints that may arise.
:::Example: John says "I can make the 3D models" - some time later, noone has heard anything from John. it's nice to know either way, if John is still available to participate, no longer has time, or is struggling on, just taking longer than expected. Of course, personal circumstances can radically affect things, but if possible, let the community know.
Ideally, some guideline of timescale and deadline ought to be included, simply for the sake of keeping the project going and synchronising the various efforts. Though it would be unfair to make this stringent.

- Scope
With any project, even individuals can continue to enhance, introduce new ideas, or further develop almost any factor of the project as a whole. With more mparticipants, the capacity for this increases exponentially. Therefore, it s important to narrow own the scope of the project early on.
Later additions and development can be addressed once the project has achieved a greater completeness

-Quality and Framework
The abilities of the community vary immensely, and as a result, so does the efficiency or usefulness of code. However, it would be unfair and improper to exclude input from any community members** (provided within the terms of 'scope'). Therefore, an underlying framework should be planned and optimised by the (hopefully best available) participants (note plural). Whilst there shouldn't be any levels of hierarchy in a community project, experience, skills and knowledge should be respected and utilised to maximum performance. For this reason, ideas/code submitted may be optimised, re-written or amended to suit the framework.

**There may be unsuitable contributions or those that do not fit within the framework, unfortunately, not all contributions may be used or imported as offered. This occurrence must be purely decision based on merit of the submission and its relation to the framework and scope. By no means will it be any form of slight against the contributor, nor will any submissions be excluded without proper appraisal.

- Agreements/Disagreements.
At some point, there are going to be disagreements. Whether simple differences of opinion, or 'commmunity-breaking' strong arguments. In these instances, an overriding decision should be made. Whoever is responsible for such a decision should be decided at the initial conception of the community project, and all participants should respect such decisions. However, the overriding authority should only be used when the conflicts arise or it is specifically requested, the 'decision-maker' should not be otherwise able to 'rule over' what is a joint, community project.

- The Project Flow
The first step is to define what the end result product will be. Perhaps a shooter game, maybe more an adventure/strategy type. At any rate, the bare style / genre or manner of playstyle should be defined.
From this point, ideas and suggestions are likely to expand quickly, so it is necessary to agree on limitations and prevent the project becoming too complex before coding even begins. This is where the scope is defined.
Once the Scope of the project is established, the essentiall framework is idealised, a "flow chart" or "spider diagram" which resembles the core engine can be drafted and this forms the main reference for all participants.
From this reference point, the core engine, the "modular-esque" (couldnt think of a better word) code, is begun.
Meanwhile, contributions for conceptual artwork, theme scores and storyline ideas are addded.
With the code and resources available, the 'fun' begins. Media resources are combined within the code structure.
This is where synchronisation is highly important.
Once the media and codebase is complete, the first testing of what should be a complete game can begin.
Alpha testing results analysed, bugs addressed, tweaks and optimisations made.
Final additions such as extra media, front-end, configuration options etc. added
Beta Testing begins.
Beta testing results analysed, bugs addressed, tweaks and optimisations made.
At this point, the project can be considered final, or a review of earlier 'beyond scope' ideas can be made. Further testing is advised for the new additions.

This is pretty much an overall key factor. Everyone should keep up the communication, we have these forums here, for more cooperative methiods between participants, other forms of communication such as IRC etc. may be useful, but the project participants should all be kept in the loop as to progress. The matter of communication is repeated in many points below with more specifics pertaining to the particular situation, reinforcing perhaps why it's so crucial.