Email Protocol for Formal Proposals
In May 2005, General Rules For Decision Making
were adopted by the Indymedia Ireland collectives. It was later acknowledged that participants on the editorial list and other organising / working email lists for Indymedia Ireland have had trouble following the status of decisions. Proposals were being lost and slipping through the collective consciousnesses due to the large volume of email messages on the various lists. Not all participants were aware of all proposals and proposals which had actually been approved weren't acted upon due to a lack of clarity about when the consultation period was up.
As a result, the following formal structure for formal proposals relating to editorial and other organisational matters was developed in June 2005 to clarify the on-line decision-making process:
The subject / title of an email with a formal proposal should contain the word PROPOSAL so that participants on the mailing list who don't have much Internet time can quickly scan through all the emails on the list and just pick out those that have PROPOSAL in the subject line.
The email body should contain a section headed PROPOSAL and a section headed DEAD-LINE / TIME-FRAME along with an explanatory section headed DISCUSSION. i.e.
[Email Subject] PROPOSAL: A concise description of the proposal
PROPOSAL: A detailed but concise proposal
TIME-FRAME: x days/hours/weeks
DISCUSSION: Other explanatory material
The TIME-FRAME for a decision would depend on the context of the decision. If the proposal is to publish a new feature, the time frame could be as little as one day. If it concerns the proposal of a new editor or a new policy in running the site, then the time-frame should be at least two weeks in order to give all concerned parties the opportunity to see the proposal and to have their say.
The DEAD-LINE is the date when time-frame for decision is up.
Any formal amendments to proposals should be preceded in the message body with 'AMENDMENT:' in upper-case letters.
The DISCUSSION should be used by the proposer the space to state the reasoning behind their proposal or amendment. Those casting a vote can also use it to add to the preceding discussion.
When replying to a formal proposal with an approval or a block, a summary of the votes cast far should be included and updated. The summary should state whether or not the approvals or blocks are conditional on certain amendments. This makes it much easier for someone without much Internet time to quickly see the current state of play. The TALLY should be updated by each person as they cast their vote and quote marks such as 'greater than' (>) symbols should be removed from the message so that the tally can easily be picked out of the surrounding text and read at a glance. This is done using the following format:
For - [list of names so far]
Against - [list of names so far]
It was also agreed that people replying to formal proposals should not quote irrelevant text such as email signatures or mailing list footers and that they bottom-post rather than top-post as it's more logical and much easier to follow email threads if the response follows the point being replied to. Irrelevant text such as email signatures and list headers just add clutter to the email body and make it much harder to pick out the important parts of an email.
Finally, it was agreed that - to avoid confusion - it would be the responsibility of the original proposer to ensure that an approved proposal be acted upon - unless someone else elects to take responsibility in the mean-time.
- 15 Feb 2006