AutonomiWiki/Talk

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...

The "management" of a central library will eventually require more effort than simply replicating the content.
It may be preferable to simply link to the desired material and effectively chain through a set of content via a "link path" (e.g. TrailFire).

-- 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.