A few thoughts (not rules, just thoughts) about the Davis Wiki from one editor:

Short Version

  1. Don't be disrespectful of other editors.

    1. Establish an Identity, because words that are stood behind are more valuable.

      b. Don't remove the contributions of others. If you disagree, respond to what they had to say.

Longer Version

  1. Anyone can edit this wiki, but with that freedom comes some responsibilities:

    1. Editing is an act of publishing. Any comment or edit is being both released under the Creative Commons-By license and recorded in that page's edit history. Once published content is "out there", you can't call it back, but you can apologize for it and move on.

    2. You may choose not to use your real name, but don't assume that in the future someone won't connect your pseudonymous account to your real name. It is a bad assumption and if it make you feel free to say things you wouldn't stand behind with your real name, maybe you ought not to be saying them.

      1. It would be in poor form to "out" an anonymous user. This doesn't apply in any way to pointing out sockpuppets.

  2. This is a place for creation. Removing content goes against that goal in most cases. The exceptions are removing content that does nothing to aid in the purpose of the Wiki such as spam. This also applies to deleting your userpage when leaving Davis.

  3. Banning people should be a last resort. Attempts should be made to help them understand how things work on the Wiki. The Wiki however should not allow itself to be abused by those who show no interest in learning and communicating.

  4. Pages without links are sad. Add a link to them, or if that isn't practical reconsider if they should exist.

  5. Pages that don't have links pointing to them are sad. Create a relevant link and point to the orphaned page.

  6. Don't interrupt someone who is successfully working at a task to tell them that it is impossible.

  7. Join in and help the Gnomes... if you don't who will?

  8. Anyone whose first edit includes the phrase "I created this account just to..." did just that and has a much lower likelihood of ever turning into a positive member of the wiki community.

Purpose and Nature of a Community Wiki

A community wiki is useful and healthy if it serves several goals:

  1. It must have information that is accessible and useful to the members of the community that it serves. This means that:

    1. There should be a variety of information that includes:

      1. Information about current businesses and services in the town — useful as telephone book replacement / superset

      2. Historical information about the town — because the wiki is a great way to capture this and understanding town history helps build community and places current events in context.

      3. Shared interest pages. If you build catapults chances are someone else in town would be interested watching you fire it.

      4. beautiful trivia and things that make the community unique.

    2. There must be both structure to the information and a useful means of searching the information.

      1. This applies to both the naming structure of pages and to the manner in which template oriented information is stored on those pages.

      2. This also means that pages should have meaningful incoming and outgoing links. Tools for checking for the presence or absence of these should be able to filter out links to editor personal profile pages.

    3. Content reuse makes information more powerful. Enter once, use many, make it easy to edit the base information from secondary use locations. If a page gets created about something on fourth street, then the fourth street page's [[OnThisStreet]] macro should be able to list it properly and filter it out if it is marked as [[departed]]. The same sort of thing applies to businesses and business type category pages. It should be possible to pull specific metadata into table presentation for each business type category page.

    4. Information and other edits must be able to be attributed to the source of that information (a single identity). You need to be able to go and see who claimed that there is a mermaid swimming in the town square fountain.

  2. It should facilitate building community in the community it serves.

    1. It isn't possible to do this without editors establishing identity. This doesn't require the use of real names, but real names should always be an option. Think about a community wiki like you would any other organization in town. Are you able to join the chamber of commerce and be anonymous, the Rotary Club, or a church, etc.? If the wiki is a reflection of the community and a tool within it for strengthening that community then individual identity is an important part of building relationships and trust. The Davis Enterprise doesn't accept anonymous letters to the editor.

    2. Editors without identity don't contribute toward the goal of building and strengthening community. In some cases they have minimal negative impact on this goal and in other cases they do damage against it. Every additional editor without identity contributes to the sense that it is ok to not have an identity. Anonymity has an important place on the internet, but its use in a community wiki requires a lot of responsibility and there is no way to "hand out" the ability to be anonymous to only responsible people.

    3. It is preferable to cultivate editors rather than attract people who only leave comments. Reconsider the presence of a comment macro, or break comments out into a new data structure and keep them separate from the content of the page. Comments from those without identity tend to diminish the ability to build community.

  3. OpenID?

  4. The more people from the community who contribute in a positive manner to it the better.

  5. Multiple mediums should be encouraged.

    1. Text is highly editable and can be collaborative.

    2. Photos add well to content.

    3. audio is less editable and leads to more presentation / response back and forth, but allows for powerful content to be captured. (think going and getting oral histories from non-computer using members of the community)

    4. video is less editable but is also powerful like audio

    5. GIS data and the presentation of that data is important. Ideally a tie between openstreetmaps and localwiki would be great, but with the option of using openlayers so that the data could be mapped on top of a variety of base maps including Google maps.

  6. The process of integrating new editors shouldn't place a burden on existing editors.

  7. It should be easy for new editors to begin.

    The balance between the prior two is interesting. One solution is to not enable bad behavior by introducing a quick ramp up to full access. If a freshly created account has full ability it encourages the creation of accounts for abusive purposes. On the other hand if a newly created account needs to introduce themselves first there is a minimal barrier for entry for new editors, but enough of a barrier that it makes sockpuppeting more difficult. If a new editor's edits don't go live automatically until they have made 5 good edits then it steps that up a little more. A new editor would need to introduce themselves (establishing some identity) and they can then make edits, but those edits go into the page as an unapproved and therefor not generally viewable change. They would show up flagged on Recent Changes and would either need to be approved or rejected by another editor. If a number of edits are made by editors without reviewing the proposed edits then the proposed edits would auto-approve (say after a minimum of an hour and 10 edits by at least three separate editors).

  8. Where possible WYSIWYG should be used for editing

    1. WYSIWYG editor should not allow presentation changes that detract from the content. Changing the font for instance. There is a fine line between allowing things like bold, italics and background colors for tables and creating a tool that will be badly misused by someone who wants to make the wiki page about their business look just like their website. Allow as much as possible, but avoid items that can only lead to abuse or inaccessible content. Don't allow black text on a black background, provide a [[Spoiler()]] macro instead.

  9. Edit comments should be searchable. Find all edits made by X where the edit comment includes "spam".

  10. Quick edits should have edit comments, or be integrated back into the main edit method.

  11. The stats page needs to work

  12. There needs to be a set of open APIs for accessing and working with the content. Perhaps look at http://en.wikipedia.org/wiki/Content_Management_Interoperability_Services or something like it.

  13. There needs to be healthy and clear channels of communication.

    1. This means between established editors

    2. and between established editors and new editors

    3. It needs to be possible to engage people in conversation (interactive) as well as leaving messages for them.

      1. Either needs clear visual (and alternative) indication that a person is trying to interact with them. Humanize the process of communication where possible.

      2. Interactive conversations... should they be recorded, automatically open, or what? Consider this the same as taking a person aside at a public function and chatting with them? With no indication that such communication is or has taken place a new editor might get the same "welcome/talk" from several people. That argues for the conversations to be recorded and public.

      3. As much as possible don't use e-mail. Allow editors to opt into a variety of notifications (and easily opt back out) e-mail, rss, etc. Don't ever expect an editor to be using any of those tools.

  14. When making a proposal it is better to get it out there in a less polished form and let the community participate in its improvement than to wait and present a fully formed proposal that doesn't leave any room for others to participate in its development and thus generate some sense of ownership in it. Rough drafts are a healthy starting point.

    1. If all you can do is point out what is wrong with an idea and you aren't willing to put your own improvements or alternative suggestions out there... you aren't willing to be wrong, and a willingness to be wrong is key to forward progress in a collaborative environment.

Add tags