Tech process / changes

This process doesn't attempt to discuss the means to reach consensus, just the mechanical process of getting technical work done. The way we would reach consensus for tech issues should be the same as any other decision.

It's also really important to have put forward thought out proposals instead of "hey we should do X cause it'd be cool". Proposals should be labelled and obvious.

1. The request is posted to the tech list [imc-aotearoa-tech@lists.indymedia.org]. This is to see if the proposal is possible technically, and if the tech people have the knowledge to create it. Tech people shouldn't object to it for reasons other than these at this point.
2. If the request is possible, then a proposal is made to the general list [imc-aotearoa@lists.indymedia.org].
3. If the request isn't possible, then it gets added to the wishlist on our wiki. The reason for the proposal being dropped should be labeled there. This is the proposer's responsibility.
4. If the request is approved on the general list, it gets added to the TODO list on the wiki. This is done by the tech people. TODO items won't necessarily be completed chronologically.
5. If the proposal is turned down on the main list, it gets added to the wishlist on the wiki. It should be marked that the proposal is possible, but consensus was not reached. This is the proposer's responsibility.
6. When a alteration to a file is made, it's name and line number[s] altered are noted on the files altered page of the wiki. Don't forget to comment the code for anything more than aesthetic changes.

-- StrypeY - 04 Dec 2005