[Home]AutonomiWiki

MeatballWiki | RecentChanges | Random Page | Indices | Categories
This is a proposal for a BranchingWiki that would allow independent groups of people to participate in overlapping domains.

Each group could define an AuthorizedCopy of any page, create their own micro-sites, and control their membership.

Proposed Praxis

"... the technical branch-and-merge is not the problem, it's the embedding of more complex technology into a social practise that you have to invent and foster ..." -- HelmutLeitner

According to WikiWay, "The single and total goal of the Wiki Way is the cohesion, coherence, preservation, and advancement of the wiki itself." When the WikiProject is to collaborate around a thematic focus, or encyclopaedic-knowledge, then a simpler WikiEngine will be more appropriate than AutonomiWiki.

The extra complexity of AutonomiWiki will become appropriate when the WikiMission is to form independent CommunitiesOfPractice?, where it is most important to serve the needs of the community members, and advance their process of learning; the preservation of any institutions is incidental, so the WikiIsIncidental?. Rather than IncidentalCollaboration, it is often useful to have formal membership (especially in MeatSpace groups with limited physical resources). For example, a network of WikiPedia:Housing_associations or WikiPedia:Intentional_communities may want to provide wikis that are shared by their residents. They will rarely aim to expand their own membership, but often want to collectively publish information about themselves in a creative way that is inspiring to others, but perhaps cannot commit to continuously maintain it on their own. Similarly, in political AffinityGroups?, the aims are often to keep membership low, maximise participation within the group, maintain independence, and form networks of trust.

AutonomiWiki could be put into practice by initially replacing static websites (or ContentManagementSystems?) that are currently used by small groups. It could replace the use of unified wikis for political networks that are made up of AffinityGroups?. AutonomiWiki has the benefit that its HardSecurity can be disabled by group members, and in practice we should persuade all groups to voluntarily do this at times when their community has sufficiently large membership, or friendly outside support, with the time and energy to keep the information maintained (to standards that their members have defined).

Proposed features

The special features of AutonomiWiki include:

Branching, merging, or forking wiki pages are already discussed in VersionHistory. AutonomiWiki will take full advantage of versioning by making it highly visible, and adding the benefit of Protected Branches.

Highly visible versioning

The version history will not be hidden away; instead there will be obvious ways to create and navigate between parallel versions. This will promote diversity, and avoid giving visitors the impression that there is any 'official' Trunk or Mainline version. We could display a visualisation of the branches, or include prominent statistics and links to other versions.

ConsensusGroups

In AutonomiWiki people can form groups and agree their own rules or collective policy. If they choose, they can set membership conditions, agree the duties and responsibilities for CommunityMembers, and admit or exclude people as they see fit. People can also fork information from an existing group, and modify it to fit their needs.

To make their identities visible, each group could define a logo or distinctive graphical style that would be applied to their Protected Branches.

Protected Branches

New branches of a wiki page could (optionally or temporarily) be protected by one of the ConsensusGroups, so that only group members can edit it. This will enable a group to keep control over a stream of page versions, and these could be linked together to create a protected PageCluster stream.

While the specific branches are protected, the pages are not, so non-members can create additional branches to include their changes, or to incorporate the text into their own groups.

How does AutonomiWiki compare to TeaTime?

The motivations and intended audiences differ. AutonomiWiki does appear to be technically very similar to TeaTime (including some of the early proposed features -- see the off-the-cuff thoughts mentioned in [1]). A crucial difference is that TeaTime uses a copyright mechanism similar to Meatball's, so that copies of text are made only by the on-going (default allowed) permission of the authors, while in AutonomiWiki, the required permission is granted in advance by the copyright license notice.

How does AutonomiWiki compare to ViewPoint?

The premise of ViewPoint is that writing should be refined by a privileged group of editors in order to be sufficiently interesting to attract readers. The writers' submissions are made into a public domain 'slush pile' and are merged and presented by an individual editor, who is supposed to gain recognition from visitors, eventually providing an 'authoritative channel' for other peoples' writing.

In contrast, AutonomiWiki assumes its private groups are CommunitiesOfPractice? that will actually be interesting in themselves (for example, they might be radical AffinityGroups). In their private branches, the groups can present information about their organisation and communicate about their activity -- perhaps this is what's meant by OrganizationalKnowledge? If they choose to control their group membership, and share responsibility to collectively control their own page versions, then the Protected Branches can become a definitive source of information about the group itself.

How does AutonomiWiki compare to a ReviewedWiki?

ReviewedWiki is much simpler, because there are only two versions: the authoritative 'reviewed' one, and the editable draft. There is a problem though (from the perspective of SocialAutonomy) because there is a binary HierArchy between the "review authority" and the "regular or new users".

Actually the AutonomiWiki is an adaption of a ReviewedWiki, but it effectively has multiple review authorities (defined by the private groups), and it eliminates the hierarchy by giving all branches equal status -- There is no MAIN version.

Why not use a separate wiki for each group?

New wikis need a critical mass of users, so are difficult for groups with low- or intermittent-activity to maintain. To reduce maintenance, their wiki could be created in a managed WikiFarm, but the group will likely get locked-in unless they have the ability to export the data and host their own wiki, in which case they typically need a WebMaster? or administrators to configure it. So the group either becomes dependent on a single host, or they concentrate SysOp responsibility on a few members. These are not ideal for SocialAutonomy.

AutonomiWiki will try to solve this with a minimum-configuration WikiEngine that can be trivially installed, backed up, and 'forked between hosts'. RecentChanges could be federated to allow a group to move to a new location, while still interacting with other groups on the previous host.

Appropriate Uses for AutonomiWiki

It might be appropriate to create groups and private branches when:

Weaknesses

Buzzwords

AutonomiWiki is a BranchingWiki with specialised HardSecurity that is supposed to protect visitors' autonomy, rather than protect the knowledge-base. It is intended for CommunitiesOfPractice? and based on an ideal of SocialAutonomy, so might be best for AntiAuthoritarian groups. The AutonomiWiki will try to DevolvePower, limit the PoliceForce, not define formal positions to DelegateResponsibility for decision-making. It will enable people to make their own GatedCommunities, but it won't define any formal group leaders or representatives. It will protect the RightToFork (for everyone equally) so it will require RadicalTransparency? and a copyright license that allows derivative works.

CategoryUncommonWikiTechnology

Discussion

Early Discussion -- Before Sep 3

I like it. The key idea, it appears to me, is to make it easy for people to fork wiki and participate in their separate domains, thus developing (what I call) the CommunityWiki:PassagesOfPerspective. -- LionKimbro

I believe it when I see it. I remember a number of attempts at similar systems who were unable to deliver. -- HelmutLeitner

That's reassuring, because I'd rather have a challenge than a flawed vision. Can you see any major problems with AutonomiWiki or any weaknesses I've missed? -- JamBaltine

Jam, I didn't take the time to think it through (why should I, this is work for a week), but maybe follow the tracks of CostinCozianu (see also Wiki:CostinCozianu) who discussed this heavily in 2005 iirc. The resulting conflict has been ironed out in WardsWiki, as far as I see, but from the backlinks of his homepage you should find enough of his reasoning. Maybe contact him. He discussed this around the first WikiSym 2005 with lots of people. He was already a near-grandmaster at chess at the time (perhaps he is a grandmaster now) and had his logic sorted out. One hint: the technical branch-and-merge is not the problem, it's the embedding of more complex technology into a social practise that you have to invent and foster side-by-side with the technology. -- HelmutLeitner

I've observed this type of communication in practice since several of my associates participate in an extended "WikiHive?" complex that spans several sites and quite a few servers and many OddMuse SubWiki(s). A benefit is that "common" text can be centralized and can be a seamless TransClusion into several other pages. It is not yet apparent how the obvious "out-of-context" and "preservation-as-published" issues may evolve as the library of "standard" MicroContent? text grows. I personally suspect that it will not scale-up to any great extent since...

-- HansWobbe

NathanielThurston -- Thu Sep 3 09:32:02 2009

Jam, regarding "The VersionHistory may become complex and confusing; it might be hard to design a sufficiently intuitive interface": have you looked at the view of version history presented by gitk(1), and the crude [implementation] in the TeaTime test wiki?

On a related note, I would be interested in exploring the similarities and differences between my vision of TeaTime and yours of AutonomiWiki -- first, since it seems that they face many of the same design challenges, and possible that they could share a codebase; and second (inspired by NonviolentCommunicationAndPatternTheory), since my feeling is that both proposals would benefit from the mutual scrutiny.

JamBaltine -- Thu Sep 3 12:53:26 2009

Thank you Nathaniel, I'm keen to explore this with you. I will look into the gitk and TeaTime user interfaces, and then post some questions.

For the last few days I've been living on a large camp [1], and discussing this idea with various social groups. Something I've recognised is a consistent discomfort with computers and technology in general. Some groups use online services (email, forums, CMS) already to coordinate their activity, but they seem to exclude some people, and are seen as a burden by others. Partly this is a vague anarcho-primitivism, but I think it's also a common result of dis-empowerment from bewildering technologies. I think AutonomiWiki must try to address this problem, so I propose to keep the implementation as minimal and friendly as possible. I hope people will feel that AutonomiWiki is a simple tool that is entirely under their command, so I would like the code to be thoroughly documented and accessible so even complete beginners feel invited to read it and modify it. Ideally, I hope to move away from the divisions between 'user', 'administrator', and 'developer', so that everyone feels like an equal, independent participant. After all, AutonomiWiki is not a specialist tool, it is intended for broad group communication. So far, I've taken a look at OddMuse, and I suspect the Perl code is too dense for a beginning programmer. I suggest (reluctantly) that PHP might be more suitable, because it appears to be a popular first language and it's similarly easy to self-host.

Also, thank you for adding the astute observation about copyright and permissions to the article. You are right that AutonomiWiki was only intended for Free Cultural Works[2]. I'm not sure whether it's a good idea to prevent derivative works in some situations. This would only require a trivial change to the code, though it will significantly affect the community.

JamBaltine -- Thu Sep 3 14:02:57 2009

Lest I forget: I believe Google Wave is unlikely to make AutonomiWiki redundant. Wave looks very demanding, and will obviously not be trivial to self-host, whereas AutonomiWiki should run on old/salvaged/reused low-spec hardware, without big server infrastructure.

Also, I suspect a lot of people won't like Google Wave, as many didn't like email, instant messaging or social networks either. I think it's because all of these 'magic' technologies give people a feeling that they are passive users. When I asked people at camp, they rarely knew how the protocols worked, but they invented strange explanations, which inevitably were scary and involved corporate control.

I started to think that AutonomiWiki should be partly an educational tool to help people feel greater autonomy when they collaborate on the web.

NathanielThurston -- Thu Sep 3 14:12:36 2009

It's interesting that you mention ease of self-hosting, since TeaTime and AutonomiWiki share a dependence on an underlying distributed revision control system -- and those are extremely complex pieces of software, though they can appear simple from the outside. I had some difficulty finding a host for the TeaTime test wiki, since my host for thething.is doesn't support git or mercurial, and it seems like it's unusual for a web-hosting provider to provide such support.

Perhaps the answer is to isolate and encapsulate the complex bits of functionality, leaving the high-level / important parts easily comprehensible to everyone. For TeaTime, that would be, in particular, the code that implements WeightedConsensusVoting.

There are a number of languages available. For something accessible to the non-programmer, I would be thinking of python.

JamBaltine -- Thu Sep 3 15:44:27 2009

I would rely on white box systems (like encapsulated open-source components) if they're as simple as possible. We have to balance priorities (performance, ease of hosting, readability of code, amount of code, ...) and I think we should favour the balance that makes people feel most autonomous (hence the name). I see AutonomiWiki as a shared communication tool for democratic group activity (e.g. for coordinating action, or composing policy, or expressing opinions), and I feel that ideally everyone in the group should be equally in control of coordination.

I think we should favour simple code that is accessible to beginners, even when it makes our codebase larger. For example, I noticed A Simple VCS[3], which might be more suitable than an external dependency on git.

From a language point of view, I suggest PHP instead of Python because of its low memory footprint. I think it can serve pages much more efficiently over CGI (as they're normally configured for shared hosting). And there are lots of beginners books on PHP, though I'm not a fan of PHP by any means! Ruby looks like the most fun to me, but also the most resource hungry and difficult to host.

Jam, are low memory footprint and efficiency of serving pages critical to the project's success? If not, I would advocate using, e.g., Ruby, for the first implementation, and worrying about computer resource efficiency if and when the AutonomiWiki becomes popular. -- NathanielThurston

Knuth said "premature optimization is the root of all evil." However, this is not premature optimization; at this stage I'm just considering the priorities, and I think they should be:
1. easy to read code that's a pleasure to study and adapt,
2. easy for any novice to install their own copy, and
3. very cheap to host
My rationale is that I think wiki should be an Open Software Service [4], and even small communities (who AutonomiWiki is aimed at) should have the resources to independently run it themselves. Coincidentally, have you seen this: [5]? -- Jam

The issue I have with PHP is that my experience with PHP code suggests that it tends to get in the way of (1). Maybe it's just that I haven't come across good design in PHP, but my impression of the language is that it was designed to be a high-throughput web serving language, and that not much though was given to the readability or adaptability of PHP code.

Regarding (2) and (3): I'm aware of at least one shared hosting service suitable for small communities, which has, among others, lisp, perl, python, ruby, tcl, and git support. I'm using one for the TeaTime test wiki, and it's extremely cheap for my modest needs (I pay only for bandwidth and storage, with no monthly minimum). Is the need to have everything run on a dedicated (non-shared) host critical?

PatrickAnderson -- Thu Sep 3 16:35:46 2009

This sounds similar to some of the goals for PlainTextWiki?.

PatrickAnderson -- Thu Sep 3 16:36:19 2009

hmm, I mean http://CommunityWiki.org/en/PlainTextWiki

JamBaltine -- Thu Sep 3 19:47:49 2009

Thanks Patrick, perhaps PlainTextWiki? or VisibleMarkup? are appropriate -- I hadn't thought about this yet.

I do reckon WysiwygWiki would be inappropriate -- even though it gives the illusion of simplicity. The suprising thing about user-friendly GUI is that the 'user' becomes very dependent on the 'developer'. And when the developer reorganises the GUI (as Microsoft did in Office recently), other people suddenly realise that they are not in control, and it fuels frustration with technology.

If AutonomiWiki hopes to break down the divide between user and developer, then I suppose there will be no concept of 'user-friendly'.

JamBaltine -- Thu Sep 3 20:03:58 2009

To push this idea further, how about allowing the wiki to document it's own code? We could enable visitors to view the code and edit the comments as wiki, so it could be fully self-documenting right down to the subroutine-level.

NathanielThurston -- Thu Sep 3 20:07:17 2009

Jam, you raise some interesting challenges, to which it may be difficult to find answers. One idea: implement clear separation of the various components of the system, and enforce the restriction of their powers, along the lines [recommended] by an old office-mate of mine, Daniel Bernstein. The idea would be to isolate, e.g., the despamming code into a module of its own (in this case, an opaque module, since publishing the despamming code would eliminate much or all of its effectiveness) -- and to demonstrate to any peer reviewer the limitation of possible effects of that code.

JamBaltine -- Thu Sep 3 21:21:57 2009

Yes, to keep it simple I think the code should be modular. I don't know whether it needs to be object-oriented though. Since the code will be short, maybe the extra language features are unnecessary.

NathanielThurston -- Thu Sep 3 21:26:51 2009

Jam, my suggestion would be to actually segregate some of the modules into entirely different executables -- e.g., have the despamming be a separate UNIX program that exits(0) if the change is "ham", and exits(1) if it's likely "spam", and to call it a "dungeon" that eliminates the possibility of it having any side-effects.

NathanielThurston -- Wed Sep 9 08:24:15 2009

I've been wondering about "Why not use a separate wiki for each group?". It seems that for the purpose of AutonomiWiki, all you really need is to make it easy to fork the wiki between hosts. Why not use one of the existing revision control system based wiki engines, and rely on the underlying revision control system for implementing the "fork" operation?

JamBaltine -- Wed Sep 9 15:47:36 2009

Yes, if you can easily fork a wiki with its history between hosts, then actually you have all the functionality you need for a BranchingWiki -- except the branches occur between the WikiForums, rather than within the same one, and you can only fork entire group wikis at once, rather than individual pages.

Here I'll try to write some initial scenarios (these are just quick first attempts at rough use case scenarios):

A community creates a micro-site to present itself

A group want to publish information about their organisation and their planned activities. They want to invite anyone to contribute to the information, but it must be dependable at all times (so it doesn't mislead visitors or misrepresent the group), and they don't have much time to maintain the website (perhaps they have limited Internet access). Using AutonomiWiki, one person defines an 'AuthorizedView' on behalf of the group, and invites other community members to join. Any member of the group can then create an AuthorizedBranch? of a page when they want the group to take responsibility for the information.

Actually I dislike the term AuthorizedView, because there is not supposed to be editorial 'authority' in AutonomiWiki. I think the name ConsensingView? [6] would be very appropriate here, to emphasise that the page is formed by an ongoing consensus process, either within a ConsensusGroup, or just by an individual over time. Similarly, we can have a ConsensingBranch? instead of an AuthorisedCopy?.

The wiki host delegates responsibility

The person who hosts a wiki has responsibility for the contents, and often they are responsible for editing any illegal/offensive material. In AutonomiWiki, every page branch is marked as the responsibility of a specific group, or an individual. If there is a dispute, AutonomiWiki allows the group or individual to be contacted and asked to make changes, or to move their branches to a different server, and to hide them if necessary, but it will not enable the wiki host to edit the ConsensingView? of a group.

A visitor submits an improvement

A visitor arrives at a group's wiki and sees that it's a mess. They want to tidy it up, so other visitors can access the information more easily (they want to be helpful). They don't want to take ongoing responsibility for the page, and they can't be bothered to read the group's agreed rules/policies. They can make the correction themselves and save it in parallel with the original (as a new branch). This alternative improved version will be offered to later visitors, but will not automatically replace the group's ConsensingView?. Later it can either be merged in by a group member, or rejected, so it is no longer offered to visitors as an alternative.

A visitor explores adaptions of a page

When a visitor is reading a page, the wiki offers the visitor a list of adaptions (all the relevant branches of the page). The branches are presented to make it clear (highly visible) who's responsible for maintaining them -- and every branch is associated with a group or individual. The visitor wants to judge the credibility of the information they're reading. They do this by comparing the current branch with others on the same topic. They can see whether other credible groups have summarised the information for inclusion in their own ConsensingView?s.

A community uses online consensus decision making

A political group that uses ConsensusDecisionMaking, in its MeatSpace meetings, wants to use the Internet to facilitate decisions over long geographic distances. In AutonomiWiki, a group member creates a page to raise a new issue for discussion. The group's ConsensingBranch? of this page describes the consensus among the members. Other branches of the page can be created (by individuals or other groups) to present their opinions, or make their own decisions on the same issue. This means non-members/passers-by can provide input, but the consensus process cannot be derailed by interlopers.

A federation is created to allow groups to scale

Every group or individual has their own ConsensingView?. To allow communities to scale-up, the groups could be viewed as 'federations', made up of sub-groups and individuals. In AutonomiWiki, a federation can invite an entire group to join. If the group members agree, then they all become part of the federation. This way a large group can form by the federation of trusted small groups. To help maintain the federation's ConsensingBranch? of a page, changes could be merged from the sub-groups' ConsensingBranch?es.

A new group is templated on an existing one

A group of people want to organise an event, based on the successful model of a previous group. They fork the previous groups branches, making a copy of its entire ConsensingView?, and link back to the original to give attribution. They can send a notification to the original group to let them know about the new derivative group, so they can be StrongLinked. Then they delete all the unnecessary pages, and adapt the remaining policies and details for their own event -- the original group acts like a template. An important thing is that previous event information remains intact for us to learn from. A good example of this is: [7]... [8] ...[9]

I think these scenarios could be satisfied with a conventional wiki (if it has an AuthorisedView?, is well organised, and is trivially easy for any member to host themselves), but I wonder whether we could make things simpler and more intuitive with a special WikiHive? -- perhaps one that helps people to efficiently copy a page, send a LinkBack? to the original, and start to adapt it independently, all without needing to ask permission.

RadomirDopieralski -- Wed Sep 9 20:31:43 2009

I had some very similar ideas for use cases when I started to work on Hatta. The 3 main goals you listed (easy to read, easy to install, cheap to host) are a wet dream of many web developers. You listed them in decreasing order of difficulty. Anyways I have one suggestion to make: become a member of a community that has a need for the use cases you listed, and work with them on a solution -- maybe initially using some improvised or existing tools, developing better replacements as time and resources allow. From my own experience it's best to scratch your own itch. To write software that is useful for a community it's best to be part of that community -- otherwise your ideas are not being tested, thus they can freely wander and go astray, never to reach the solid ground of real implementation again. PS. You might also want to look at some old ideas on the wiki features wiki, it's practically dead now, but it has some good material in it.

JamBaltine -- Wed Sep 9 23:03:43 2009

I heard about the fabled Wiki:WikiFeaturesWiki. It sounds interesting, but I think it has met its demise. Most of it seems to be missing from the internet archive. Has it ceased to be? Is it an ex-wiki? ... Oh, after more googling I found it here: [10]

Yes I do have several communities in mind. One of them is already experimenting with a system called CrabGrass?. Another group is looking into Joomla, and with another group I spent more time than I should configuring MediaWiki before I realised it was going to be an ongoing maintenance headache for them. It appears to me that all the available solutions force a community (without technical expertise) to rely on ongoing maintenance by administrators. When I did improvise using existing tools (with MediaWiki), I constructed something the community would be unable to maintain without me, and that just seems terribly dis-empowering to me, so at the moment it's on hold until I find a technology that doesn't make them dependent on a SysOp.

NathanielThurston -- Thu Sep 10 09:20:55 2009

Jam, my understanding is that it is easy to "fork a wiki with its history between hosts" using Hatta. While I too would like to enable the additional use cases, I'm not so sure they are necessary to meet the needs of the communities you mention.

I wonder if you have read DevolvePower -- and if you understand the reasons behind the seeming contradiction between that page and the fact that Sunir remains ensconced as social, technological, and administrative leader here, as well as being our SysOp.

MeatballWiki | RecentChanges | Random Page | Indices | Categories
Edit text of this page | View other revisions
Search: