Can I do a meta-fedwiki, please?

Could a fedwiki be the best medium to develop ideas for improving the fedwiki?

Continuing the story from last time, I spent a fair amount of time yesterday continuing to watch Marc Pierson's vimeo channel. This time it was the two videos where Ward Cunningham and others, particularly including Thompson Morrison, talk through the origins of, principles behind, and experience with their fedwikis: Fed Wiki, Ward Cunningham, Thompson Morrison; and FedWiki Session 2, Ward & Thompson – long, but highly worthwhile orientation. They gave me so much to reflect on that I had to get up early this morning to write some of the ideas down before they slipped away.

These were not what I have been used to in technical conversation. In what technical contexts would you expect to hear phrases like these?

“If we trust that we can walk together into that space of emergence, and then be inspired by each other, what happens? … It is magical, when all of a sudden you have this explosion of creative possibility … the problem is that we've learned not to trust each other. And so the trust is the critical piece that we need to walk into in order to co-create. And we can only do that if we are being authentic with each other. … Let's walk into this together and recognise that something magical can emerge that will surprise all of us.”

If you want to hear them spoken, go straight to this part of the second video, where it is Thompson Morrison speaking.

I don't want to dwell on my delight at finding this kind of talking scattered through a call centering round a piece of software, and the fact that I have only got used to hearing this in very non-technical contexts like Collective Presencing. The delight serves just to motivate me to engage, and here, I want to signal my engagement by minimally sketching out the issues that come up for me, around using and developing Fedwiki into something that works well for a knowledge commons as I envisage that. There are several issues, and although they aren't entirely separate, I'll give each one a heading. Let me stress that I'm writing from a position of substantial ignorance, so I may be mistaken – but in any case, I hope to return to each issue sometime in the future, when I can elaborate, and clear up any misunderstandings.

Page names

Anyone who has edited a wiki knows the convention: you just surround the key words in brackets (in Wikipedia and other Mediawiki wikis, it's [[ and ]]) and there appears a link to another page by that name in the wiki. If this simple convention is to be useful, the named pages need to have the vital information about whatever it is that that name refers to. I already noted yesterday that every fedwiki user can ‘fork’ their own version of a page, and the system cleverly decides which one you go to if you click on that kind of wikilink.

This relies on the assumption that the page name means the same thing to everyone. Wikipedia deals with ambiguity through ‘disambiguation’ pages, where the different possible referents of the name can be listed. For example, John Smith is a very common English name, so Wikipedia's John Smith page is actually a list of all the notable people of that name who have Wikipedia articles, who are disambiguated either by a extra forename, or a role. The John Smith that comes to my mind (it's an age thing) is John Smith (Labour Party leader).

But how does that work in a fedwiki? Hmmm …

I've been imagining how a developed system could work. Every page name could be associated with an author identifier, and I could have a way of saying “when I say John Smith I mean this one”, pointing to a particular page, without the need for me to actually have a page by that name. Or, maybe more than one page – that would be safer. And if a page I was referring to changed, the system could check with me whether that is still what I mean.

The other issue I can see is vagueness rather than ambiguity. You might have a page talking about, say, global warming, with interesting information; but when I fork it I might well want to change the name, or alternatively, start a page with a different name, but referring to yours. I won't detail that point; but it seems to me that the page name is, as people say, ‘overloaded’ with meaning, and the different functions need distinguishing and given different methods.

Ownership and merging

The next big issue in my view concerns ownership and merging. If you've been working on something with collaborators, you might want to create a joint page which represents your shared opinions. Now we understand that we don't want to get to the stage of Wikipedia, where people dispute, but what I'm thinking of is very small trusted groups of people who actually want, and are able, to reach a working consensus. Well, maybe I could simply merge all of your changes to my page, so the pages were identical; but I can imagine that as rather dissatisfying. Another possibility is that I could nominate your page as the one I want to refer to as authoritative, and mark my page as commentary. No doubt there are other possibilities.

Standards creation

A particular case of this would be in the negotiation and agreement of standards. Now, for sure, an open ordinary fedwiki process, such as described by Ward and Thompson in the videos, could be a really helpful way of preparing the ground, understanding where each other are coming from, etc. But in some contexts, a following step is called for, for putting together an agreement. A standard is one kind of agreement, and that process is necessary at a technical level to get the Web in general, and fedwikis in particular, to work in any reliable way. I'm thinking that it would be good to have these agreements within the same technical system.

Separating the user interface from the underlying logic

This is a very big issue, but can be expressed very briefly. Let's just say that many people find the current fedwiki interface hard to learn and to use. It would open up all kinds of possibilities to separate out the fedwiki logic, complete with APIs and protocols, as something that could be implemented by a variety of front ends or user interfaces. In my view, the process of separating out the interface presentation from the underlying logic would be really valuable, even if it only served to clarify what the essence of the fedwiki is; but also, to allow everyone to implement their own interfaces – like current browsers, but probably with much more variation – would open up the fedwiki potential to a much wider user base.

Technical compatibility

There are two cases which fall under this heading in my view. One is the Semantic Web and RDF; the other is Git. I'll leave Solid, Dat (see and Holochain for another day, as I don't see the issues as clearly.

I've played a little with at least the theory of the semantic web, or linked data, or the RDF. There are quite a few tools which fit in to that ecosystem. It's one of the reasons why JSON was developed into JSON-LD. The more that the underlying logic of, and data storage in, fedwiki can be made compatible with this approach, the more tools there would be to interact with and process the information, and that could be useful in the context of knowledge commons. I may be mistaken, but I don't believe that has been explored in any depth yet.

I've never yet mastered Git, but I know enough to recognise several similarities between the logical structure of Git and that of fedwiki. I can imagine that someone could well have looked at these similarities, but I don't currently know that. In any case, I'd like to understand, what are the similarities and the differences between the two models; and is there space for either to inform the development of the other? Git is hugely popular with the programming community, through services such as Github, so if fedwiki could present itself as a kind of git for ideas, that might bring in lots of technical users and support. Github has its own approach to wikis, and I'm curious to know why they don't support a fedwiki-style approach.

Adult development

I mentioned this last time. Not to repeat myself, I just want to list it here as an issue that holds great significance to me. Seeing the current fedwiki as embedded in Kegan's 4th order of consciousness, some of the issues above relate to what I would love to see – the technology supporting the development of 5th order consciousness.

E-mail and blogs

This was some “what if?” thinking that has come up in recent days.

What if e-mail was merged into a fedwiki-like structure, just without the continued ability to edit? What you wrote could stay on your own server, but each message wouldn't need to carry around those sometimes absurdly long chains of replies. If you edited the other person's text in your reply, you could show provanence using similar mechanisms as now in fedwiki.

Blog comment threads have struck me for a long time as faintly absurd. If I comment on your blog, I'm losing control of my comments. How much better to have meaningful responsive exchanges in a fedwiki manner, where each person keeps their own contributions? I've seen it happen in some blogs already, in a fashion. But it could be done much better.

How to proceed, then?

Currently, my journal here is produced using very old-style technology. I don't even have a blog system with a comment facility. But maybe, and here in particular, we could use a fedwiki to develop these ideas? Don't you think that would make sense? In which case, as soon as I have that fedwiki up and running, I'll direct people from here. It could earn the name of a meta-fedwiki – a fedwiki about fedwikis – the challenge being that very few people so far have a fedwiki.

Meta-fedwiki, to better fedwikis, to more people engaged, to more knowledge commons, including about 5th order wiki technologies, to …

Topics: Wiki software

If you have any remarks on any of my posts, please send me e-mail, saying what you want me to do with your remarks. Are they private to you and me, or would you be happy to quote you (I will always attribute your words unless you ask me not to), and add your response (or parts of it) to the post it's about?
Creative Commons Licence