[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Ampu-dev] Proposed Context Statement

From: Lee Braiden
Subject: [Ampu-dev] Proposed Context Statement
Date: 21 Feb 2002 00:48:24 +0000

Hi Folks,

Al... here's my proposed updates to the Context Statement.  As I think
you had expected (from your mention of red pen =), I'd like to alter the
the Requirements Spec before officially putting it into CVS.

This shares some similarity to your own interpretation, mostly adding
more detail.  Forgive me for replacing the majority of what you wrote in
that section, but as you can tell from the other email, I wasn't
entirely sure what you meant by some points, and didn't feel confident
to merge my thoughts with yours for that reason.  If it's any
consolation, this whole thing is closely modelled on yours, even if the
actual words don't match very often.  We can easily merge the two
versions, as we bash out some common terminology -- hopefully the other
email will help in that regard.

Of course, comments and suggestions are welcome as always, guys =^)


We are intent on developing a tool for the support of direct decision
making by large populations for a open-ended range of issues. This tool
will enable users to create new decisions to be made, express an
interest in existing ones, and vote on them when the time comes. This
tool will support decisions to be made via direct democracy and through
a representative system using juries directly chosen to make them. The
tool will maintain a library of decisions, supporting documents. It will
also maintain the relationships between decisions, the groups making
them, and other related decisions.

When a user first conceives of a choice to be made, they create an
initial summary of the issue, adding documentary evidence if necessary.
Any possible solutions can be added at this time, along with any further
documentary evidence to support the argument for or against that
particular solution.

At this point, a jury is created, by a commonly accepted method. Jury
members are then given the chance to debate these issues, or perhaps to
request further information, such as documents, field studies, etc. 
Eventually, the jury's decision will be reported back to the group which
originally raised that issue, and the results of the decision will be
made public.

If any tasks were specified to implement the preferred solution, then a
new working group, a taskforce, will be created at this point, to ensure
fulfilment of that decision.  Methods of selecting workers for this
taskforce (such as volunteering, or contracting) would be chosen by the
system's users.  Taskforces would have full access to any documents
created or provided for their use, such as specific implementation
details.  Should any issue stall the taskforce, then it can easily
report back to the main body of users which initiated it.

Throughout the system, information and communication will be managed in
such a way that it can be shared amongst different groups.  For example,
building groups would have easy access to regulations created by legal
groups.  It is possible to override this information, so that a group
may follow established standards, but deviate where necessary. 
Similarly, it is possible to enforce certain documents for all groups,
providing a direct way of enforcing control, should it be deemed

Information within the system is automatically stored, cross-referenced,
and archived.  Therefore, all past decisions and precedents can be
easily retrieved, as can any information required to make a decision or
simply discuss an issue.

Documents can be tracked through their various revisions via a complete
audit trail, so that information deleted from the current document can
easily be proved to exist at a particular point in time.  All editing is
logged, including the date, the editor, and the nature of the editing.  

Likewise, it is simplicity itself to amend or superseed documents as a
result of new decisions.  Every individual or group who relied on the
original document will automatically gain access to the updated copy.

Lee Braiden,

Lead Developer,
A More Perfect Union.
ICQ: 24346459
Jabber: address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]