[MG] Mapping Participation in Drupal

[conseo]

Hi,

> 
> > My main concern from days of old has been the centrality of the
> > pollwiki.  I don't really want to register my content there.  I got
> > hung up on this before.  I am merely attempting to understand this
> > central service, the pollwiki, as we move ahead (beyond crossforum)
> > when I say that I really do want to do drafting in Drupal.
> 
> Drafting is not unique to the pollwiki, so it's not a centrality
> thing.[1] The users can draft in any medium they choose, on any site,
> in any format or language.  Grep "free-range drafting".

This is crucial and definetly the only perspective that has a future imo. When 
working on something as serious as drafting (which can take many hours of 
text-editing a day if you get serious involved in an issue) you really don't 
want to reinvent the wheel and lock users in your particular webinterface even 
if it is something like Drupal. I have written a blog-client for KDE for this 
reason, which's successor is really successful nowadays. Many people don't 
like web rich-text editors of Wordpress or Drupal.
Allowing free-range drafting is not something that should be postponed to the 
future and it is not in Votorola, therefore I like it. Drafting has nothing to 
do with the pollwiki or the pollserver. It is a distinct technical process 
which has more to do with text-editing so it can be easily seperated and 
should therefore interface with any way that text-editing and merging is done 
already, for example also things like latex/html +git or even code + git. That 
way we can plug it in and change it to the needs of the users easily and can 
even bring different communities together.

> 
> I'm trying to answer your other concerns about the centrality of the
> pollwiki in the other thread.[2] We might end up with an open voting
> network that's 100% decentered to the users (pure P2P), but we can't
> start it that way.  We need central nodes here and there.  What I
> suggest [in 2] is that nothing will go into our own little center (the
> prototype pollwiki, or whatever we choose to call it) unless people
> understand the need for it and agree to it.
> 
> Remember too, the central bits are going into a *wiki*.  We're making
> this as radically open as possible given current technology.  We'll
> always be pushing the edge of that boundary.

In fact Michael runs his pollwiki on his low-bandwidth home-server. A 
MediaWiki + Semantic-Media-Wiki and the database server is really not heavy in 
current terms of hardware. You can cheaply buy embedded linux home servers 
that would easily handle a server for a few hundred users (not concurrent) and 
this improves as we speek. We can also easily package it and build an 
appliance which can be run on any Linux host seperately.
We should not define low-level technological needs before we get a use case, 
but rather keep the architecture focused and open. As long as we allow vote-
mirroring we actually are P2P, because the servers run P2P in a decentralized 
network. It is not really a drawback that you need an admin to care for the 
servers. Everything else is unrealistical atm. as no other web-service is 
truely run P2P. Maybe Diaspora will gain some experience in this direction, 
but even they expect you to install it on a LAMP-stack and don't show of 
something reliable yet, so we are not worse then that in fact. 
Don't get fooled by the term Wiki. It has nothing to do with a central project 
like Wikipedia. The pollwiki is only for us to have a sane and easily editable 
semantic db at hand. This allows very flexible querying and plugging in of e.g. 
different drafting media and keeps possible applications generic. It has very 
well defined generic hooks and interfaces so other web-services can interfere 
with it. You can for example link position pages from the Wiki to Drupal and 
therefore use Drupal as the web-frontend + drafting and never see the Wiki. 
Crossforum can directly link to the drafting medium, in this case Drupal. 
Rather imagine it as a DB server then a web-interface. Of course since it has 
a web-interface and the semantic-media-wiki is very flexible you can use it as 
the drafting medium and web-interface which is only a plus, but not its core 
feature or a lock-in of Votorola. Since the Wiki is heavily open it also 
allows pulling even of competing admins at any time and the content is never 
really under the control of the admin (which is different with Drupal). So [1] 
does not depend on a friendly administration but only on the users need you 
represent when forking. It is therefore handling the voting data (drafting) 
like FOSS code or creative-commons content like the Wikipedia's is currently 
managed.
 
[1] http://zelea.com/project/outcast/dep.xht#wiki

conseo



Originally posted to the mailing list of the Metagovernment Project:
http://metagovernment.org/mailman/listinfo/start_metagovernment.org