Process to handle user feedback

Here is a high-level overview of how we could process user feedback (which includes our own ideas, bugs reports, etc.). Don't be scared - there are some explanations below : )



Explanations:

There are three types of feedback that we can get:


 * Bug reports
 * Suggestions/ideas
 * Questions

We would feed each of them into the corresponding section of a Launchpad, which would allow to do the triage, voting, confirmation... work, to identify the ones which requires actual development work.

Once we have identified what we would like to see done, we approve the idea or confirm the bug, give an estimate of the price, and send it to Flouzo to create a donation campaign to get the money. Politis can then choose to finance partially or totally the work, and others (users, contributors) can do the same.

At any point during the donation campaign, a contributor can start working on the task. If he completes the work and his patch is committed into the official repository, he gets the money.

If nobody choose to work on the task for a given amount of time, it is sent to RentACoder.com for completion.

Community funding
Helping with the development of the project is something that only developers can do, which greatly restraints the range of contributors. Other things can be done by people who are not developers (helping to translate, document stuff...), but this doesn't have a direct effect on the actual features of the game. Donations allow everyone to step up to make sure a specific development is being completed.

The idea is also to use it as a way to involve players in the decision-making process - for example when a player makes his first payment in the game, he could allocate $1 to a task of his choice (they will have to think hard about what is the most important for them, and it may be an incentive to come back and donate money on other tasks in the future).

Freedom of choice with tasks
One of the motivations of a member of an open source project is the freedom to choose the tasks he wants to work on. However, a tension could arise for tasks that are paid - first because people will probably appreciate to have a chance to perform the paid tasks, and second because sometimes we will need to ask employees or contractors to take care of some critical tasks, even if they would have rather chosen to work on something else.

So only people who won't care about the money will have a complete freedom of choice. Employees and subcontractors, because they need to make a living of it, will tend to focus more on the paid tasks (there has to be some drawbacks!). And, while you can't force a contractor to accept a task, employees will have the extra constraint of having a set of tasks that they won't be able to chose - the goal should always be to keep this set of "forced" tasks to a minimum, to maximize freedom of choice, but we don't see how to avoid having them.

Organization of work (from David - XXX Check for consistency)


 * The studio funds the tasks that are necessary, through community or outsourcing
 * Anyone in the community is free to developp and ask permission for check-in
 * If a task is not taken by community, studio gives it to a subcontractor
 * Complete decentralization (only the 3 partners in the premises)