Project Westfall Accelerated Development Program
==============================================================================

This program is designed to drastically decrease the amount of time needed
to get Project Westfall to completion. It does so by leveraging the power of
a large group of people with varying levels of intelligence, skill, and
enthusiasm to accomplish tasks, ranging from the mundanely simple to the very
complex.


Problem Quests
-------------------------------------------------------------------------------

The most central element of the system is the problem quest (also known as a ticket).
Each one would contain an issue along with any descriptions, hints, and a problem
rating. The lifecycle these quests would be as follows:

1. A bug is submitted by a community member (developer or non-developer)
2. A senior developer reviews the bug, determines it's validity, elaborates on
    the description (if necessary), creates a task list with all goals that need
	to be met in order for the quest to be completed, and gives the problem a
	rating
3. A developer finds the quest, accepts it, and it is marked as theirs and added
    to their quest log
4. The developer fulfills all the goals of the quest and submits their work via
    Github with a link back to the ticket.

	Alternatively, if no work is submitted by the time given with the ticket, it
	is freed again and anyone is again allowed to accept it.
5. Their work is reviewed on Github by a senior developer. If all goals are met
    and the work is satisfactory, it is accepted and the quest is closed, giving
	them their rewards. Otherwise, the developer either stalls it, giving a reason
	so the developer can fix it, or rejects the work entirely, causing the ticket
	to again be open for anyone.

General rules:

 - The ticket must contain all problems associated with it's content. Bugs related
    to one boss, for example, cannot be split over multiple tickets.
 - All criteria need not be completed at the same time. Submission of any work
    towards the criteria will reset the ticket's timer. However, if the time does
	run out and ticket is returned to the tracker partially completed, the rewards
	will be split over the relevant authors by the criteria's weighting.


The ticket's model is as follows:

 - A unique, non-recycled ID that is used to identify it on the web app.
 - A relationship to the relevant quest, NPC, etc. by ID.
 - A number of criteria associated with it.
 - The person currently working on the ticket, if anyone.
 - The person who submitted the ticket.
 - The developer who reviewed the ticket.
 - The ticket's validity (valid, invalid, awaiting approval, unknown)
 - Any comments on it.
 - Any senior developer provided hints.
 - A quest level, determined by the lowest difficulty of the uncompleted tasks.
 - The ticket's status (under review, needs a developer, in development, rejected, accepted)
 - A log of events, with dates and relevent people (10/11/11: Someguy submitted the ticket., etc)

The criteria's model is as follows:

 - A task, to be fulfilled
 - A weighting, given as a percent (all criteria percentages for the ticket should add to 100)
 - A level, based on the nature of the task (see quest level tiers below)

The comment's model is as follows:

 - The author who wrote the comment.
 - What information is contained within the comments (opinion, evidence, etc.)
 - The rating of the comments (comments would be rated by other researchers)

The Research Lab
-------------------------------------------------------------------------------

Any tickets which lack enough information to be deemed as valid or invalid or have
their goals determined and finalized would be moved to the Research Lab. It is here
that community members would be able to provide any information or opinion on the
ticket, and be rewarded for it.

These rewards would come in the form of research experience and levels, completely
seperate from development experience and levels, because someone who is good at
finding and verifying information may not necessary be a good developer, and a good
developer may not necessarily be good at verifying information.

Here, community members would also be able to rate other comments. The amount of
points the comment goes up or down would depend on what level the researcher is on.

Like tickets on the development tracker, tickets on the Research Lab tracker would be
given a difficulty level. Any good information that contributes to the ticket's
eventual rating of valid or invalid would give the author of that information
research experience proportional to A. the level of the research ticket, and B. the
rating of their comments, so a very useful comment on a difficult ticket would give
more experience than a less useful comments on the same ticket, or an equally useful
comments on an easier ticket.

Quest Level Tiers
-------------------------------------------------------------------------------

Levels:   Description:                       Example:
---------------------------------------------------------------------
1  - 10   The simplest of database fixes     Changing a quest's level
10 - 20   More in depth database fixes       Adding proc data for a spell
20 - 30   Simple script changes              ACID, gossip scripts
30 - 40   Advanced script changes            Basically any C++ scripts
40 - 50   Core fixes and "WoW mysteries"     Packet related bugs, code optimizations, etc.


Lessons
-------------------------------------------------------------------------------

Complete lessons would be provided for every level and every possible type of fix. Once
a developer is proficient in one area of mangos and has shown it by achieving a certain
developer level, they are automatically recommended to the next lesson. Of course, if a
developer wishes, they can read as many lessons as they would like to, and do any tickets
that are available, regardless of level.

These lessons would be very specific. For example, the loot system would have it's own
lesson discussing the ins and outs of the loot system, such as references, criteria, etc.

These lessons would include:

 - Complete information on the piece of mangos being studied (table, class, API, etc).
 - When this part of mangos is most likely involved in a problem.
 - How fixes should be approached for the most correct solution.
 - A case study of something that was fixed using the techniques of the lesson.
 - A short quiz at the end with questions related to the lesson, which would award XP.