Home
It looks like you're having connection troubles. Reconnect now.
05/04/2010 06:38:04
Public Pad Latest text of pad adhcplanbeta Saved May 4, 2010 |
 |
|
|
 |
== Adhocracy Development Plan ==
Adhocracy has reached a point at which it has most of the functionality imagined during its original conception. While there are many tasks regarding unit and acceptance tests and the user interface and usability that need to be worked out over the following months, larger stories for future development are probably also needed.
The following document will propose one such path, which aims to implement concepts adapted from the theoretical concept of Direct Parliamentarism (DiPa).
=== DiPa - Adhocracy term glossary ===
The following is a rough matching of the terms used in Adhocracy to those used in the DiPa drafts:
proposal - Bündnis
provision - Politikfeld
(to be extended)
=== Wiki pages ===
In short, Adhocracy should be retrofitted with wiki capabilities. While the current system only allows text contributions in the form of comments (some "disguised" as description texts and provisions) hä?, a separation should be made in the future. Within the current design of Adhocracy, the following uses for wiki pages exist (more shall become obvious in the remainder of this document):
* Issue descriptions
* Proposal descriptions (to be called: proposal goals)
* Provisions
* Static pages (home page, imprint, about page)
* User home pages
==== Base functionality ====
Wiki pages should be editable by anyone and preserve a complete revision history. Inheriting from the `Delegateable` class, they can serve as delegation scopes as well as a subject for comments (which, in later versions, should also be allowed in-line, i.e. as text annotations).
How can delegation work with arbitrary wiki pages? (Sounds very confusing, perhaps over general)
==== Branching and Merging ====
Furthermore, wiki pages should support variants (i.e. branches). A variant can be created from any other variant at any time. Adhocracy must support an easy, drag and drop merging functionality to combine two branches, either modifying the existing branches or creating a new, third branch.
At any time, each page should have an active (trunk, mainline, master) variant. The active variant could be selected using a voting mechanism (see below for more info). In some cases, wiki pages must have several active variants depending on their context (c.f. Provisions). While there is some merit in restricting editing on the mainline variant (pushing development to another variant), the first wiki release could be imagined without such restrictions.
-> That is basically what Candiwi does http://candiwi.org/
==== Using existing (D)VCS ====
Implementing branching, merging etc. from scratch would present us with a significant task. Two DVCSes, both implemented in Python, should thus be evaluated as potential foundations for wiki functionality: Bazaar and Mercurial. While using either of these would significantly reduce the needed development effort, the following considerations need to be reflected as well:
* Most VCSs are oriented towards managing a tree of documents instead of a single file. They thus implement many operations that would not be required in our system. (Some as basic as `commit`)
** Isn‘t the commit operation equivalent to “save this page”?
*** true, that's why, if you have "os.write" you wouldn't need commit for single files.
* We do not, as of now, need to have remote branches, push or pull. A normal REST interface would be entirely sufficient. (However doing a backup as simple as 'hg pull' would be awfully sexy)
* Web-based merging would have to be implemented from scratch in any case.
* Both Bazaar and Mercurial are terribly slow, write operations might have to be detached into a separate thread.
** What about a faster VCS like Git?
** At least bzr allows its libraries to stay loaded, which makes operations in it much faster.
*** Git isn't a lib, thus using git means shelling out each time we want to do sth. It saadly still seems faster than bzr & hg (there is a lib for php)
**** cgit ... *google* It‘s a web frontend for git that seems to make use of libgit. Don
t know if it has a stable API + py bindings
I really like git, btw. And I'm still split on the "one repo per wiki" and "one repo per page" question. One repo per wiki sounds reasonable to me, but one repo per page? Git and probably other VCS are able to display the commit history on a per-file basis. And sometimes it is nice to have an overview over all wiki page changes.
True. If you look at the "provisions" section below, the motivation for the alternative might become more obvious.
Hm… I think I understand. What about “one repo per provision”, but allowing more than one page per provision?
Sounds interesting, Daniel and I were talking about having one page as "human readable" text and one written in "legalese" - yet this seems complicated for a first iteration. I hate how MediaWiki does Discussions. I'd much rather experiment with blog-style bottom comments and inline annotations, don't you think?
MediaWiki-style discussion pages suck ;)
Yet the best alternative seems to be things like http://book.realworldhaskell.org/read/getting-started.html and http://opencongress.org
That looks interesting, but I think that it would be nice to have some kind of… well… tree, not only a linear thread of comments. Discussions might split at some point. Agreed. There is some DokuWiki plugin for this. [http://www.dokuwiki.org/plugin:discussion] It’s useful, but a bit obtrusive.
* A custom VCS could be developed in cooperation with other groups, most notably the "Wikipedia dissidents", i.e. the Levitation project. They have identical requirements with us, minus the emphasis on voting. kompletter absatz hä? (Levitation doesn't develop a custom vcs, but severs wiki pages directly out of low layer git access routines)
==== Other uses for wiki pages ====
* General purpose wiki pages for discussion, organization etc.
** Are wiki pages really suited for discussion?
* Resource pages, containing references, data and statistics.
* User stories detailing concrete scenarios addressed by one or many proposals.
* Ordering pages. Some issues demand the concerted deliberation of various related
proposals. Wiki pages could serve as hubs to connect these proposals with a
structure that can only be created using social processes.
=== Extended Provisions Management (Politikfelder) ===
(The following section is largely a re-formulation of the core concepts of DiPa using the terms of Adhocracy)
Most of the day-to-day work within Adhocracy in some way relates to the creation, discussion and editing of the provisions concerning a certain proposal. Most of the future development should therefore focus on the improvement of those tasks.
==== Functional Extensions ====
The current implementation of provisions does not allow for a number of actions that have been requested by users: moving one or many provisions from one proposal to another, sharing some provisions among proposals, comparing different variants of a provision and voting on which variant - if any - should be included in any given proposal.
Adding such functionality becomes trivial with the introduction of wiki pages. A provision wiki page can be included in any number of proposals, each time selecting another variant as being active. Thus "Proposal 1" might include "Variant A" of the provision X, while "Proposal 2" might include "Variant B". At the same time, both Proposals could include "Variant A" of another provision, Y.
This would alleviate the need to split more complex policies into many distinct proposals to keep discussion complexity at bay.
==== Simplifying dependency management ====
Given that various proposals would maintain their own variants of a set of provisions, those entities could be used to simplify dependency management.
Administrators could prepare a set of given provisions that have an immutable base variant from which any proposals would then branch. In a general purpose law-making Adhocracy, for example, each section of the current legal environment would be represented by a provision. In other cases, such as the preparation of statutes, the legally required sections of the statutes would be used in such a capacity.
Proposing a modification of an existing norm would thus simply become a matter of branching the exisiting language and modifying it in the context of a proposal.
At the same time, these fixed points could provide the functionality implemented by virtual packages in the APT package management system: Any two proposals supporting different variants of any provision would automatically be marked as being mutually exclusive. This would remove the need for the manual dependency management which is currently a part of Adhocracy, by providing a concept of fixed resources (Daniel: "allgemeine Verbindlichkeiten").
TODO: How to implement requirements? Do we really need them? Should they be on the level of proposals or provisions?
=== Groups ===
In order to represent factions inside an Adhocracy, we will want to introduce groups. A group is defined as a set of users sharing a common goal. Groups can either be ad-hoc entities, representing a natural position within the Adhocracy or act as a virtual representation of an existing organization.
The role of groups is to
a) develop and discuss their goals if needed and
b) apply these goals to position themselves regarding the Adhocracy's proposals. Users joining a group will automatically give a global delegation supporting the decisions made by the group, which of course can be overridden at any time.
Decision making within the group can be based either on a democratic, oligarchic or dictatorial process, depending on the distribution of voting rights within the group (see below).
The goal of introducing groups will be:
* First, to allow active users to form formal factions within the system and thus aggregate support regarding their agenda.
* Passive and infrequent users will be allowed to delegate larger chunks of decision-making responsibility to a group representing their general interests.
=== Refactor poll logic ===
Three major additional use cases will have to be added to the polling code (i.e. libdemocracy):
1. (DONE) The ability to use proper delegation resolution on comment and topic up- and down-votes. Such votes currently do not properly resolve the delegation chain and thus allow for multiple votes by each person.
2. Multiple choice voting. Each proposal will have to select on wiki page variant to become the "selected variant" for the proposal. E.g. if there are 6 variants of a page (that is to be used as a provision in a proposal), a vote would be a good mechanism to determine which of these variants will become part of the language of the proposal.
This is essentially a preference voting problem and multiple approaches (including the increasingly popular Schulze method) should be evaluated in this context.
3. Intra-group voting. Inside groups, members will want to vote on how the group will position itself regarding to a proposal. This might happen with limited voting rights, e.g. giving only one or a few users the authority to determine a group's position. This could be useful for representing real-world entities such as political parties, NGOs etc. (This seems like somethign we explicity don't want, having few people determine the groups decision? -- I think drafting the official position and voting on its adoption only through its members is something highly relevant for possible use of systems like adhocracy by NGOs, as this sort of internal discourse is a very recurrent scenario within NGOs. Later on -- after successful adoption -- such a group position may be subject to votes of users outside the group.)
=== Role of Issues ===
The role of issues in this concept is somewhat ill defined. While there is certainly a need for a place to discuss and define problems, issues may overlap with provisions in their role. Since provisions would exist as separate entities from the proposals in which their variants are discussed, they could serve as the natural points of origin for problem analysis (i.e. if I have a problem regarding § 129a of the German StGB, that's where I'd complain). (= Politikfeldparlamente)
Analysis could also take place in the less formal domain of wiki pages. Here, users could detail their experiences and then link to newly created proposals as they come up.
=== More explanations and tutorials ===
Beside various media around Adhocracy, there should be two feature inside adhocracy
- Mouse over text for various buttons to explain their effects
- An explanation wiki, with tutorials and so on. This page should have a part which is localized that could display "social code" the participants have agreed upon.
=== Tags ===
While Groups appear the right solution on the long term, especially in larger adhocracies, having delegation by tag could provide a quick and easy solution.
Open Problems regarding that:
- Who controls what is tagged with what?
- When can tags be added?
- How do you remove duplicate tags "Foreign Policy" vs. "foreign" + "policy" vs "foreignpolicy"
On each proposal you can vote for and against a tag: The tag is shown if there are more "show" than "not show"; otherwise, it is not displayed. moreover in smaller adhocracies most of these issues can be easlily lifted by interpersonal discussion. People have to agree on how to tag, it's social code they have to fix it themselves. Here having a local part to the "help wiki" that explains the social code could be useful. (Tagging works best if the common tags are highly visible so people get trained to use them)
*** Things that have changed after you visited should be marked
* Allow single karma mods
Hover help texts:
* "new issue" - "Create a new issue to discuss a problem"
* "join" - "Join %(instance)s to contribute to the discussions"
* "votes" - "Lets you check your past decisions"
* "
== Stuff to talk about ==
* Trolls: how to deal with them (also consider two groups, where one would like to kill the discussion of the other group)
* How to see easily what you decided (via your delegations) and to get to the discussion)
* How to see easily how other people decided in the past so you know that you can trust their decisions (todo: defining better on what basis you should delegate to somebody)
* separated work groups, that come to different conclusions should be able to co-exist
Wie wollen wir Bildung für Kinder ...?
*** Zugang zu Bildung ***
Issue/Thema: Zugang zu Hochschulen (I1)
anderes Issue: Zugang zu Kitas,
Zugang zum Gymnasium
Im Issue "Zugang zu Hochschulen":
- Tags: hochschulpolitik, hopo, bologna, elite, ....
- Allgemeine Diskussion zur Klarstellung des Ziels/Themas:
- Sammeln von Daten, Fakten
- Grobdiskussion versch. Optionen
UND Proposals
Proposal 1: "Stipendien für die besten 10% der Abiturienten"
Proposal 2: "Stipendien nach Auswahl durch Assessment-Center"
Proposal 3: "Freies Erststudium"
Proposal 4: "Niemals Studiengebühren"
-> Proposal 1: Stipendien für die besten 10% der Abiturienten"
- 4622 Unterstützer
- Tags: eliteförderung, abi, stipendien
- Allgemeine Zielbeschreibung:
"Wir wollen genug finanzielle Mittel bereitstellen, um 10% der besten
Abiturienten...."
- Umsetzung:
Berlin - BerlHG - P25 (Provision)
Änderungsvariante 'liberal 1' (netto unterstützer: 392)
"Die Universitäten sind Berechtigt, Studiengebühren beliebiger Höhe...."
Änderungsvariante 'liberal 2' (netto unterstützer: 12)
"Die Universitäten sind Berechtigt, Studiengebühren bis zu einer Höhe
von NNNN Euro...."
Nulloption: Keine Änderung notwendig (unterstützer: 2882)
Berlin - Haushalt..
Haushaltsstelle..... (Variante XXX)
(Minengebiet, Haushaltsplanung)
-> Proposal 2: "Stipendien nach Auswahl durch Assessment-Center"
- 7372 Unterstützer
- Tags: eliteförderung, assessment, stipendien
- Allgemeine Zielbeschreibung:
"Wir wollen genug finanzielle Mittel bereitstellen, um einer Gruppe von
N Bewerbern ein kostenfreies "
- Umsetzung:
Berlin - BerlHG - P25 (Provision)
Änderungsvariante 'liberal 2' (netto unterstützer: 612)
"Die Universitäten sind Berechtigt, Studiengebühren bis zu einer Höhe
Änderungsvariante 'liberal 1' (netto unterstützer: 182)
"Die Universitäten sind Berechtigt, Studiengebühren beliebiger Höhe...."
von NNNN Euro...."
Berlin - BerlHG - P25b (Provision)
Initiale Variante "assessment 1" (netto unterstützer: 382)
"Anspruch auf ein Stipendium hat, wer im Rahmen einer Qualifikations-
prüfung....."
(keine Alternativvarianten)
Berlin - Haushalt..
Haushaltsstelle..... (Variante XXX)
(Minengebiet, Haushaltsplanung)
-------------------------------------------------------------------------------------------
Zugang 2, Umgekehrte Sichtweise (!)
Berlin /
BerlHG /
P25 /
Geltende Variante
Änderungsvariante 'liberal 1' (+392+182=460)
Verwendet in: "Stipendien für die besten 10% der Abiturienten" (+392),
"Stipendien nach Auswahl durch Assessment-Center" (+182)
Änderungsvariante 'liberal 2'
Verwendet in: "Stipendien für die besten 10% der Abiturienten" (+12),
"Stipendien nach Auswahl durch Assessment-Center" (+612)
----------------------------------------------
Was beschließt das Parlament?
a) Die Änderung des Paragrafen 25 des BerlHG (=Wiki-Seite)
b) Ein Änderungsgesetz welches den Paragrafen 25, sowie 25b, 29 des BerlHG umfasst
-> Mögl: Betrifft daher mehrere PFPs
Einstiegsszenario: Zugang zu Bildung
Ich will: Bildung für alle Kinder unabhängig ihrer Herkunft vs. Bildung nur für Kinder von Leistungsträgern
Erster Schritt: Informieren über vorhandene Standpunkte zu dem Ziel
"Bildung für alle" unterschiedliche Bündnisse (Grundeinkommen, Solidarność, Waldorf, etc )
-Beitreten oder gründen
Möglichkeit zur Einflussnahme auf die Strategie und Ausarbeitung des Zieles
Gesamtgesellschaftliche Standpunkte: Politikfeldparlamente: Bildung nur für Leistungsträger etc. (Z.B. von Bündnis Neue Soziale Marktwirtschaft)
Kennenlernen von unterschiedlicher Standpunkte und von den Gründen für die jeweiligen Standpunkte
Dadurch die Chance, mit den Vertretern unterschiedlicher Strategien und Standpunkte (Ziele) in Austausch zu treten, Kompromisse zu schließen, Unvereinbarkeiten von Zielen zu verdeutlichen
Möglichkeit zur Abstimmung in den Politikfeldparlamenten (Zuständigkeitsentitäten)
Politikfeldparlamente in n Zuständigkeitshierarchien mit n Überschneidungen (Bildung, Bildung Hochschulen, Bildung Grundschulen, Bildung Vorschule etc.)
