I [who?] was provoked into writing this following discussion with Dil Green about writing in Fedwiki. His complaint I thought was a bit unfair, but as with any such encounter, it is important to dig deep and not react with easy defensiveness.
The complaint was that there is a need to change something – say an email – in one place and then to make it available (updated?) everywhere else.
When you have multiple copies of a piece of information across many folders or domains (they are effectively the same in federated wiki), it becomes unmanageable when you have to keep multiple copies updated.
My first thoughts were defensive – yes we know that! Or – it is not true that other writing environments provide that! Both are true, but that does not make them right.
With regard to the first reaction, we naturally think (coming from hypertext theory) – about Transclusion. It is relatively easy to add transclusion to wiki, for instance with the About Frame Plugin – anyway that is not our focus… we can do that later – we may say to ourselves. After all transclusion has a bad name.
On the second thought – yes we cannot think of mainstream writing environments that enable transclusion… and well that is what a database is for and wiki works with data… That is just wrong.
There is an obvious writing environment that solved this problem decades ago – wiki. A conventional multi-tenanted wiki allows anyone to update a wiki page – say containing an email address – and it is then available to everyone else – in a canonical place. Problem solved (in the usual fuzzy pragmatic way that wiki solves problems). Wikipedia is a form of social transclusion.
Thinking about this leads us to the conclusion that there are two sides to wiki (any wiki), both of which are equally important: - multi-tenanted Consensus based writing - solipsistic Federated Writing
Wikipedia lacks federated writing, and federated wiki lacks consensus based writing.
# Babies and bath water
Understanding these two sides of wiki, leads us to the realisation that both are needed and invaluable when it comes to creating a functional writing environment that truly expresses the strange social magic of wiki – that is the social power of writing together.
We need consensus based writing added back to our version of (federated) wiki. Providing a transporter to bring in content from Wikipedia, or any mechanism of simply moving data between one site and another is not sufficient to express the synergy required to leverage both aspects of writing in wiki. We need closer integration.
# Pragmatix
There are only two things we need to create in terms of software functionality to realise these goals: 1. Federated wiki server supporting Multitenancy 1. Soft prevention of forking (wiki-client modifications)
With regard to the first we need to have something like roster-based control of group authentication to wiki. Anyone, or anyone in this roster can write to and edit this Social Wiki…
As regards the second, the Wiki Client needs to recognise the provenance of the type of site a wiki-page comes from, and disable simple forking of the page. This may seem counter-intuitive.
The need is to discourage casual or inadvertent forking of what has been authored as a consensus based canonical resource. When a group of authors get together to create a canonical resource, it is damaging to their intent when causal writers inadvertently fork these pages to their site.
The intent was to provide a piece of shared content, that the community can benefit from by working together to refer to collectively. Communism is not always a bad thing. It is a tool to be leveraged by a community where appropriate.
That is not to say that we prevent forking, that would be an infringement of liberty, for no good purpose. Expressing the intent to share in a certain way should not be expressed by preventing something to happen. Making it a conscious decision, that is a bit harder to do is what is required. This is why we have modal dialogues.
The appropriate question when an author tries to fork a consensus-page would be:
Are you sure you want to fork this resource? It's intention is to be a shared space where we collect information in a single space.
At the moment simply attempting to correct a typo on such a page results in an implicit fork action, copying the data to your own server. This results in much confusion for inexperienced federated authors, and inadvertent duplication of data for even experienced authors.
Preventing fork actions for consensus pages, and instead requiring authors to visit the consensus based wiki and login to make the changes there, would solve this problem.
The json is always available, and the license would remain Free Culture. Transporters or other tools can provide a side-channel for authors to fork this content when they explicitly want to.
Alternatively we can provide a dialogue of some form – say with a customised version of the Ghost Page mechanism. Either way this is easy to add, not essential to create at this stage, and authors that want to fork can easily do so manually.
# Conclusion
There are multiple ways to write in wiki. The current implementation has explored in depth the unique role of federation and forking in creating a new form of Federated Writing environment.
It is time for this experiment to come full circle, federated wiki needs to incorporate the consensus writing capability of the original wiki, and this functionality can be added while retaining all the present benefits, and with only small additions to the code base.
## A different potential approach Getting Two sides of wiki together
# See also