Revision metadata (or a means of discussion)

[coevolving]

Related to the Chorus of Voices (at http://design.fed.wiki.org/view/chorus-of-voices ), I'm wondering how federated wiki should facilitate conversations on evolving topics. The flags (with newer and older) and journal are on the path, but somehow are not sufficient.

This morning, I was looking up "Hexagonal Architecture" -- I term I'd never heard of, but Martin Fowler was doing an interview about it -- and ended up at http://c2.com/cgi/wiki?HexagonalArchitecture . This traces development of an idea starting in 2005 (although I'm not sure which month). This example is good, because it shows a conversation. It's not so good because it's not easy for me to figure out if the ideas have or have not stabilized, with the spurt of conversation seemingly ended within a year (with the last page edit in August 2006).

In learning by doing yesterday, I did a major revision of Frequently Asked Questions by taking a fork and revising at http://fed.coevolving.com/frequently-asked-questions.html . I might have liked some conversation before doing so -- the revisions are quite drastic -- but decided to radical, in order to make a point.

It occurs to me that, when I'm editing content, that there is a "Revision Information Log Message" in Drupal, and an "Edit Summary" in Wikipedia that I normally fill in. This is a short description of how this revision of the page differs from the one previous to it.

If I had such revision metadata, I would have provided some motivation for my edits: the text was written in first person (by @WardCunningham ) which doesn't make sense when the content shows up on fed.coevolving.com; the content is oriented more towards developers than authors (e.g. on "Is there a better place to ask questions", do you want authors coming to the hangout, if it's more oriented towards developers); and the questions and answers could be made more concise (at the risk of losing a context that was relevant months or years ago).

If the revision metadata had an anchor on the page (e.g. http://fed.coevolving.com/view/frequently-asked-questions#revision-summary ), I could link to those comments on the current or prior pages in a back-and-forth conversation.

In a Federated Wiki, I can see how the "Talk" page in Wikipedia could be obviated with a change in collaboration style. If I don't like the way a page is written (e.g. Frequently Asked Questions), I can fork it and make an assertion about how I see the article could be approved. There are a variety of cases that can happen after that.

(1) The originator (i.e. http://fed.wiki.org/view/frequently-asked-questions ) could like that content, and fork it back. Suppose that on fed.wiki.org , that there are additional changes that I like. I think (and am not sure) that if I then fork that page again and don't do revisions, I'll get a flag with "same" to show concurrency.

(2) The originator on fed.wiki.org doesn't like the revisions I've made, and could refork the content to restore the original content, making the fed.coevolving.com version show up with an "older" flag. If I continue to disagree, I could just ignore fed.wiki.org, continue to edit that new branch on fed.coevolving.com and we'll have two pages with the same name in the federated wiki.

(3) The originator on fed.wiki.org doesn't respond, because he or she is too busy to notice the change, or is no longer actively editing his or her wiki. Of course, other people might choose to use the source on fed.wiki.org as a reference, in which case we'll have multiple forks all from the same origin.

In thinking through the bigger picture of Chorus of Voices, I've ended up considering Song Structure, as at https://en.wikipedia.org/wiki/Song_structure_(popular_music) . The elements are described as introduction, verse, chorus (refrain), bridge, collision, solo. I see the original content on fed.wiki.org as verse 1, to which I've now sung a verse 2 on fed.coevolving.com ... and am wondering about how we get to a chorus.

In technical terms, a fork may be followed by a join; a branch is followed by a merge. When I "forked" Frequently Asked Questions at fed.coevolving.com , did I actually first do a branch (i.e. curating the content onto my web domain), and then a fork (by revising the text)?

In the interest of collaboration, I'm looking for ways to ease the join (or merge). This conversation could happen offline from the wiki federation, but it could be helpful to others (as in the discussion on Hexagonal Architecture) if it is somehow preserved on the web.

[WardCunningham]

Twin pages are identified as 'same' when the last edit timestamps are identical. This happens when pages are published by copying them to a public site as I do with code.fed.wiki.org. You won't see same-twins because you won't see the source site behind my firewall.

I discuss this publication strategy here. http://code.fed.wiki.org/view/welcome-visitors/view/exploring-federated-wiki

This is the code that bins the twins. https://github.com/fedwiki/wiki-client/blob/master/lib/refresh.coffee#L161-L163

[WardCunningham]

I liked your reorganization of the FAQ and forked it replacing the old copy I had on ward.fed.wiki.org. You may not have noticed this unless you had my site already in your neighborhood. My copy wouldn't otherwise be noticed as a twin.

Your awareness of my work would be different should I fork my edits back onto fed.wiki.org. (I can do this because I also login to that site.) Since your copy has fed.wiki.org in its journal you will always have fed.wiki.org in your neighborhood when you have viewed your copy of the FAQ.

[WardCunningham]

There is room in actions for more metadata. Imagine that there were 'mood' choices in the footer and every action were marked with the current selection. That would be interesting, eh?

We could also create a new plugin for comments. Maybe they wouldn't show unless the page was served from your logged-in site. When I fork your page to my site, then I get to read the meta commentary.

Maybe comments also show when recalling versions of a page. The editing of comments would show in the journal anyway. They might show differently so they would be easy to spot. A lighter gray?

[WardCunningham]

Two twins can be merged by interleaving the journal actions starting after the common ancestor. I haven't actually coded this yet because I haven't felt a strong need to merge.

An interesting interface would be to shift-click a newer-twin flag and have the journal instantly update. This could be a trial merge that shows up as a ghost page, ready to be 'forked' back into the origin if it looks good.

[coevolving]

Responding to https://github.com/WardCunningham/Smallest-Federated-Wiki/issues/423#issuecomment-46088483 ...

pages are published by copying them to a public site as I do with code.fed.wiki.org. You won't see same-twins because you won't see the source site behind my firewall. I discuss this publication strategy here. http://code.fed.wiki.org/view/welcome-visitors/view/exploring-federated-wiki

On your "Exploring Federated Wiki" page is "Production Methods".

I'm authoring these pages on a private instance of federated wiki running on my laptop. This has the environment always with me. [....] In a better world I would author in browser local storage or on the live site depending on what was conveniently available. Sync could be automatic or dependent on my approval for publication.

Yes, I would like to see that "better world"! How might we implement that? Would it be a possible to have a button so that edits are in "local browser only" or "browser connected to server"? Is this a simple matter of programming now, or is an architectural change required?

[coevolving]

Responding to https://github.com/WardCunningham/Smallest-Federated-Wiki/issues/423#issuecomment-46088951

I liked your reorganization of the FAQ and forked it replacing the old copy I had on ward.fed.wiki.org. You may not have noticed this unless you had my site already in your neighborhood. My copy wouldn't otherwise be noticed as a twin.

Thanks. Yes, the FAQ page didn't show up in my "Recent Changes", but the "newer" flag to ward.fed.wiki.org did show up. The procedure of "forking" a page does work! I've made some additional small changes.

To be precise, is the label of "forking a page" actually correct? When I press the flag button, am I not just branching the page, to curate a copy for myself? The action of curation doesn't change the content, it just brings a copy over from ward.fed.wiki.org to fed.coevolving.com . The fork technically occurs when I edit the curated copy. I can't observe on your view, about whether the "newer" flag comes up after I do a curation, or after I do an edit.

[WardCunningham]

The local storage was for a long time tied to a checkbox in the web page footer. Here is the initial commit.

https://github.com/WardCunningham/Smallest-Federated-Wiki/commit/34844c3ce98733f3c8ea4a6fc3ff2dcc926914a3

We took the checkbox out when we made login/out more convenient. If you logout then your changes are stored locally. If you log back in you still see the local versions where you have them. You can 'fork' them back to your logged in server. A fork from local to origin storage shows up without color in the journal.

We use the term 'fork' to mean a variety of things, pushes, pulls, branches, clones and, yes, forks. Before github, 'forking' an open source project generally meant making a copy so as to gain ownership in different hands. We use the flag as the button icon to suggest staking claim to the page. We call the colored squares flags and consider them an emblem of ownership.

[coevolving]

Responding to https://github.com/WardCunningham/Smallest-Federated-Wiki/issues/423#issuecomment-46089254 , there are two separate ideas.

There is room in actions for more metadata. Imagine that there were 'mood' choices in the footer and every action were marked with the current selection. That would be interesting, eh?

The revision metadata would require an entry field that would show up only during editing. A productive way for readers to surface that revision metadata would be to mouseover the icon for more details. Thus, instead of only "edit 43 hours ago", the mouseover could show "edit 43 hours ago, Added new diagram and fixed grammatical error".

The "mood" choice reminds me of Christopher Alexander's patterns, where the number of asterisks reflected his confidence in the maturity of the pattern. Unfortunately, even one-asterisk patterns were published in hardcopy, so the path for continuing evolution was cut off.

We could also create a new plugin for comments. Maybe they wouldn't show unless the page was served from your logged-in site. When I fork your page to my site, then I get to read the meta commentary.

As a blogger immersed in Wordpress, "comments" appended to the bottom of a post connotes either concurrence with the original content, or clarification questions that are easily resolved. A conversation has back-and-forth threading that is more challenging to represent. (Observe how I'm responding within the limits of Markdown in this response)!

Some people might like a comments plugin, but I would put it as a lower priority. The federation of wikis allows for richer interaction ... although currently there's a barrier to entry, as each author needs his own wiki (or a friend with a wiki farm) to participate. The barrier to entry may not be a bad thing, as I believe that federated wiki targets the 5% of people who are inclined to write content, while still satisfying the 95% who want to read.

[coevolving]

Responding to https://github.com/WardCunningham/Smallest-Federated-Wiki/issues/423#issuecomment-46091663 ...

If you logout then your changes are stored locally. If you log back in you still see the local versions where you have them. You can 'fork' them back to your logged in server. A fork from local to origin storage shows up without color in the journal.

Well, that's something really missing in the "How to Wiki" page! I may tackle that when some semantic/interpretation questions I have are resolved.

[WardCunningham]

Oh, I would make comments move around the page as freely as any other content. I was thinking of Word's comments, not blog comments.

[WardCunningham]

Here are some pages that might help with semantic/interpretation questions.

http://ward.fed.wiki.org/view/abstraction-of-method/view/upper-name-hierarchy/view/special-page-names/view/where-numbers-live

[coevolving]

Responding to https://github.com/WardCunningham/Smallest-Federated-Wiki/issues/423#issuecomment-46091663 ...

We use the term 'fork' to mean a variety of things, pushes, pulls, branches, clones and, yes, forks. Before github, 'forking' an open source project generally meant making a copy so as to gain ownership in different hands. We use the flag as the button icon to suggest staking claim to the page. We call the colored squares flags and consider them an emblem of ownership.

As a newcomer (with an author's orientation overriding a developer's orientation), I would like to suggest that we consider using a different label than "fork" in specific places. The mouseover on the flag icon says "fork this page". To a non-technical person, that mouseover label is not meaningful, and is intimidating. If I was sitting with you at a dinner table, and asked you to fork something, I might have to watch out in fear of getting stabbed.

In the "How to Wiki" page, there's a friendlier "How to Copy" label. However, in primary school (not to mention the legalese that comes with every copyrighted book, movie and software we experience everyday), copying is not an encouraged activity.

I notice that "curating" is popular term on Pinterest, that is less threatening. "Reshare" or "share this" doesn't quite get the idea of taking something from someone else and bringing into a personal collection. Information is a non-appropriable asset, so when I have it, it doesn't mean that you can't have it too.

Other terms that may be just as clumsy (via a thesaurus lookup) are "replicate" and "clone". It would be nicer if we had a friendlier term like "borrow", as we do with libraries.

[WardCunningham]

One editor so enjoyed fork's gruesome overtones that he (she?) titled an interview, "Wiki Inventor Sticks a Fork in His Baby". The reporter was concerned that I would be upset. I wasn't. wired

[coevolving]

On the weekly call, talking helped to clarity what was meant by "conversations" and "comments". http://fed.coevolving.com/view/digest-2014-06-18

[almereyda]

Thanks for the notes, @coevolving! That's a big deal for me.

---

Below some comments to the text; as we don't have annotations yet:

I have to add to the discussion, that we have good experiences with Docker and Etherpad. As Wiki leverages on a much more simpler build process (sudo npm install -g wiki) it should be fairly easy to dockerize it. We're also playing with Hypothes.is or similiar tools that emerged from the Open Annotation W3C circles.

If you want to spare the time to install it, have a look at sites that run etherpad-lite. If you want to see how others integrate it into their environments, check the Third party web services that have support for Etherpad-Lite.

But right now I'm not so sure why conversations need a real time component - wrapping and versioning the paragraphs ends up messy again, I think.

Please also be aware that there are already some ideas, if not for comments, on Operational Transformation within Wiki https://github.com/WardCunningham/Smallest-Federated-Wiki/issues/194.

One last word to the mouse click behaviour : please let's consider freezing wiki pages, so I can easily select and copy parts of a paragraph without refactoring it. Then annotation would be possible. I admit the ease of dragging and dropping paragraphs is seductive, but it's not that often happening.

Also, sometimes, when I would like to copy a paragraph, I can only move it. The implied fork of a paragraph from a Wiki I don't own is also not correctly represented. A reload would only show the result. That doesn't feel too natural to me, esp. between different wikis. A Ctrl keyboard shortcut for local wikis could be enough. A non moving paragraph at a remote page + a copy at the cursor during the event of a drag could be of great help.