distributed wikis

28
Distributed wikis Brianna Laugher Freedom in the Cloud miniconf LCA2011

Upload: brianna-laugher

Post on 06-May-2015

1.768 views

Category:

Technology


0 download

DESCRIPTION

The “right to fork”, a consequence of the “hack on copyright” that is copyleft licensing, helps keep open source and open content project leaders honest. Forking is a political act as much as a version control command, and it used to be that both were a big deal. But now that distributed version control systems (DVCS) have made forking trivial, are there implications for the political act as well? How does political forking work within collaborative prose text projects (i.e. wikis)? English Wikipedia is so large as to be practically unforkable - it essentially has an unassailable monopoly, and unchecked power, in the English language encyclopedia market. One of the core Wikipedia rules is “one topic, one article”, which would seem to prohibit forking, but could we adhere to this principle and still take advantage of DVCS? Can a community be forked while keeping the shared project goals intact?Audience members will benefit from a grasp of version control, distributed version control and the workings of wikis and Wikipedia.Presented at the 'Freedom in the Cloud' miniconf, Monday January 24 2011 at linux.conf.au.

TRANSCRIPT

Page 1: Distributed wikis

Distributed wikisBrianna Laugher

Freedom in the Cloud miniconfLCA2011

Page 2: Distributed wikis

[[SPEAKER:IS]]Wikipedian c. 2005-2010

[[TALK:IS]]Strictly vaporware

Philosophising

[[TALK:ISNOT]]A demo

Concerned with technical specs

Page 3: Distributed wikis

Distribute/decentralise what?

Part Software Wiki

Interface Already existed with centralised VCS.

Barely exists, although possible. Vast majority of access via web UI.

Repository/storage

=DVCS meh

Access point Possible but not done, projects use official releases.

“marketplace of ideas” model

Community Kinda, like Linux? Not really

Page 4: Distributed wikis

● Multiple versions of articles● Opposite of “One True Version”● Some mechanism allows the best to “rise to the top” (like PageRank?)

● Isn't that like the internet before Wikipedia? …● Similar to Knol? UrbanDictionary? StackOverflow?● Problems:

● rewards older contributions● evaluating is boring ● no canonical/reliable version● does not force/reward collaboration

“Marketplace of ideas” model

Page 5: Distributed wikis

No more “One True Version”?

“A new-generation Wikipedia based on Git-style technologies could allow there to be not just one

Ocelot article per language, but an infinite number of them, each of which could be easily mixed and

merged into your own preferred version.”

– Anil Dash, “Forking is a Feature”http://dashes.com/anil/2010/09/forking-is-a-feature.html

Page 6: Distributed wikis

● Wiki = VCS + prose text project + web UI.● Copyleft license => “right to fork” => “keeps the bastards honest”.● (Software) releases : (wiki) approved versions?● English Wikipedia is 10. Can it survive to 20?

● Too big to fail?● Too big to fork?

Some ideas

Page 7: Distributed wikis

Wiki = web front-end for VCSfor prose text content

Page 8: Distributed wikis

What's missing from wiki VCS?

Page 9: Distributed wikis

● Diffs need to be per-word, not per-line ●Code contributions generally expected to be self-contained, generally in larger chunks than w/prose ●Code needs to be machine readable, (optionally?) human readable. Onus is on contributor to check machine readability

=> higher technical barrier to contributing is widely accepted

●Drive-by vandalism virtually non-existent● Prose projects rarely do “releases”

VCS for code vs prose

Page 10: Distributed wikis

Merging for code vs prose

Code for unrelated technical functions should be able to be merged

Can we make the same promise for prose?

Page 11: Distributed wikis
Page 12: Distributed wikis

Can Wikipedia survive another 10?

Sense of dissatisfaction in the community

Unlike software, a certain critical mass is needed to stave off vandalism

Page 13: Distributed wikis

Low barrier to entry(incl. anonymity)

+high visibility

+many pages

=>vandalism

Page 14: Distributed wikis

Wikipedia the monopoly

● One destination – convenient and simple for users

● Great SEO (=> project growth)

● Potential for serendipity in editor activities

● Consistency (at least superficially)

● Practically, impossible to fork● hardware/bandwidth● community

● Widespread bureaucratese, instruction creep

● Impersonal

Page 15: Distributed wikis

MediaWiki has a write API!

# Init site objectimport mwclientsite = mwclient.Site('commons.wikimedia.org')site.login(username, password) # Optional

# Edit pagepage = site.Pages['Commons:Sandbox']text = page.edit()print 'Text in sandbox:', text.encode('utf-8')page.save(text + u'\nExtra data', summary = 'Test

edit')

Page 16: Distributed wikis

“Pending changes” aka “FlaggedRevs”

Page 17: Distributed wikis
Page 18: Distributed wikis
Page 19: Distributed wikis

“Pending changes” separates

“what change I want to make”(a commit)

from“what I want users to receive”(tag as approved=”release”)

Page 20: Distributed wikis

It's almost like having a release branch

mixed in with trunk....

Page 21: Distributed wikis

Parsing mark-up :(

Templates :( :(

Free license + API – what's the hold-up?

Page 22: Distributed wikis

“WikiProjects” FTW

● Self-organised groups of editors dedicated to a particular topic (e.g. Australia) or, less commonly, focus (e.g. standardising dates)● Very informal, light-weight● Narrower focus => better opportunity for community

Page 23: Distributed wikis

Fork the UI?

(a la Twitter API)

Page 24: Distributed wikis

“Why would anyone contribute to a feeder wiki?”

Promise of Wikipedia visibility+

Domain-specific and relevant interface+

Community

Page 25: Distributed wikis

What is community?People

Intent/aims

Social norms- for interacting

- for contributing (eg. style guide)

License

Meta-planning for all of the above

Page 26: Distributed wikis

In summary...

If forking Wikipedia is too hard, what can we do to make it practical again?

Page 27: Distributed wikis

CreditsScreenshots and logos are © their respective ownersWikipedia 10: David Peters, CC-BY-SAhttp://commons.wikimedia.org/wiki/File:Wikipedia_10mark_rev_k.svg

Vandalism post-its: cdaltonrowe, CC-BYhttp://www.flickr.com/photos/30485180@N06/3490537301/

Coloured post-its: Michael Goodine, CC-BYhttp://www.flickr.com/photos/watchsmart/3227691975/

Branches: Piotrus, CC-BY-SAhttp://commons.wikimedia.org/wiki/File:Shaped_tree_branches_Tenerife.JPG

Wikimania schedule editing: Kat Walsh, CC-BY-SAhttp://commons.wikimedia.org/wiki/File:Wikimania2007_everythings_a_wiki.jpg

WikiProject Council logo: Neurolysis, CC-BY-SAhttp://commons.wikimedia.org/wiki/File:WikiProject_Council.svg

flagged revs maybe: Neurolysis/Kotra, CC-BY-SAhttp://commons.wikimedia.org/wiki/File:FlagRevsMaybe.png

pending changes clock logo: Adam Miller/Anomie/Dodoïste, CC-BY-SAhttp://commons.wikimedia.org/wiki/File:Pending_changes_clock.svg

Page 28: Distributed wikis

[email protected]

identi.ca/pfctdayelise

brianna.laugher.id.au

This work is © Brianna Laugher and licensed under the Creative Commons Attribution ShareAlike

license, except where otherwise noted.

Thanks!