[p2p-research] semantic wiki extension

[Patrick Anderson]

Samuel Rose wrote:
>
> Can you tell me why you are not a member of
> http://CommunityWiki.org/en/CommunityWikiAssemblyMemberList  were you
> denied access to joining that?

I did not apply because I did not want to become part of what I
consider a wrong direction.

I felt isolated and confused because this kind of hierarchy seems
wrong to me and yet, since I have no ownership in the server hosting
that wiki, I had no real property rights to assert my disdain.

But it is even more complicated than that because current "social
software" does not take this type of secession into consideration, and
so there would be no way of exerting such property rights without
becoming fully disconnected from the original community -- and such
disconnection would be social suicide since it would then be a stark
either/or choice instead of allowing incremental dissent.

So there is much work to be done in rethinking and reimplementing how
we organize before this problem can be realistically addressed.

I outlined my ideas about how to approach some of this complexity at
http://CommunityWiki.org/en/PlainTextWiki :


==Multiuser Concerns
* Authors own their own comments outside of the DefinitionArea.
* All users may work immediately and all changes are stored, but are
actually just votes.
* SPAM is quickly voted away (hidden by default for other users) when
too many early viewers find it offensive enough to hide or reject.
This could be a problem too?
* Changes to Definitions or to the HTML/CSS interface appear immediate
and permanent to the editor, but are actually just a vote change those
things.
* The VoteWeight of a user is increased whenever that user makes a
change that is accepted by the community.
* User implicitly vote for and against others by accepting, hiding or
rejecting comments and changes.
* SoftSecurity could be used to track VoteWeight.

==Transform lists may also be adjusted by a mixture of community and
private NameSpaces.

* INPUT files may be edited, but 'Comments' are usually not stored
within the INPUT file itself.
* Comments are usually metadata that is stored in a DataBase or in
companion files.
* The CommunityNamespace is used when rendering the INPUT file.
* The User's PrivateNamespace is used for his digitally signed Comments.
* The CommunityNamespace includes only local hosted PageNames until
some Users begin to vote.
* Voting occurs when a User makes part of his PrivateNamespace
'available' for the wiki software to read.
* The CommunityNamespace is thus 'weighted' by implicit suggestions
from Users to do things the way they like it. When enough Users decide
the word 'wiki' should link to MeatBall instead of WikiPedia, pages
are then rendered with links that point to the new preference.
* Maybe the StyleSheet could be a mix of Users preferences? Maybe too
crazy. A limited feature subset might work.

==Voting

* Any User may work immediately and all changes are stored, and appear
to be 'done' to the editor, but are actually just votes for those
changes to be made if the community agrees (but what percentage?).

* SPAM and SPAMMERS are quickly voted away (hidden by default for
other users) when too many early viewers find them offensive enough to
hide or reject. This could be a problem too.

* The VoteWeight of a user is increased whenever that user makes a
change that is accepted by the community.

* Users implicitly vote for and against others by accepting, hiding or
rejecting comments and changes.

* Identity may be optionally 'secured' through password if a User
decides to stay a while.

* Sub-communities need to be able to "carve out" their own space
without annoying others with what the old-timers may consider SPAM.
SPAM is subjective pollution?