Wiki Community/Future/Spammers and Newbies

InfoInfo
Search:    

  1. Flow description 1
  2. Flow description 2
  3. Reputation Based Editing
  4. Scalable point based reputation system with automated feedback
  5. Flow description 2, Lite version
  6. Flag new edits approach
  7. The “Vote” (read: informal poll)

A page for discussing Wiki Community/Meritocratically Exposed Functionality:

After a long time of considering the manner in which new editors are given full access to the wiki from their first edit I think it is time to start designing another model for integrating new editors into the community. I started with Welcome to the Wiki and then went to realname and then to identity, but these tools are only education after the fact for those who ignore educational resources about how to be a good member of the wiki community.

I propose that in the future new editors should not be able to make any edit until they have introduced themselves and had their intro given the thumbs up by another established editor. Then they should be able to suggest edits using the edit tools that full editors use, but their edits won't go live until approved by established editors. After say five good edits then they can edit.

I don't know if one would have to earn additional abilities or if those steps would be enough. —JasonAller

interesting Daubert

There would have to be a clear cut way of telling people (via automation, some sort of animated grey out etc) so folks don't get perturbed and just give up on the wiki —StevenDaubert

I understand the value in what you are proposing. But I have a bad feeling that it would discourage people from participating at all. If the bar is high to participate, people won't take the time, and we will lose much value from good contributors. Meanwhile, people who are malicious will wait through the test, and then start being malicious. I've sometimes given up on reporting problems with things that I use, because being able to use the system to report the problem caused me more pain than the problem itself. This would have the same problem. Metamoderation, a la [WWW]http://slashdot.org/ is one way to do this without being too restrictive. Allow someone to start editing. If they edit well, great. If they do not, they lose points. (Karma on slashdot.) If your score falls too low, you can not edit for a certain time. After a while, you get a point back. If your score drops too low again, the time doubles. Eventually, editing becomes impossible. But the barrier to entry is kept low. (Dealing with multiple accounts is another issue, which this does not solve. But it does solve part of the problem.) —IDoNotExist

Or alternatively, we could just ban malicious editors. Reverting is easy. We all can recognize maliciousness. If someone is malicious, it's easy enough to prevent them from editing. But I'd rather give someone new the benefit of the doubt first, or I think we will scare off most new editors. —IDoNotExist

Another thought - a system that requires validation and moderation by established editors puts quite a burden on those editors, and also creates problems in synchronization of conversations. ie. Someone might reply to a comment, but the reply might not be posted for an hour or two, by which time the thread will have moved on, and possibly will have disappeared entirely. There would be some fairly substantial technical challenges in getting this to work in a non-disruptive manner... —IDoNotExist

In addition to the points that IDoNotExist has stated, I think the strategy you pointed out, Jason, ruins the equality of the wiki. You (and others) post on people's pages all the time telling them to edit the entry instead of just making a comment because the Davis Wiki is a community "run by people just like you." If you make it clear from the start that it's a hierarchy as opposed to a place where everybody is equal, you will scare off the well-meaning editors take away the equal opportunities for everyone. - JenniferCook

Flow description 1

  1. new editor becomes aware of wiki

  2. decides to participate

  3. sees create new account or login

  4. clicks create new account

  5. is shown wikispot introduction unless wiki they came from has edited their own welcome. Look at how [WWW]http://stackoverflow.com/ handles the process

  6. proceeds to sign up form

    1. picks username

    2. provides email address

    3. asked to fill out their introduction, examples are provided via link

  7. is sent e-mail as soon as some editor has seen their introduction on recent changes and responded to it.

  8. is free to make edits, banner on page reminds them that their first 5 edits are not going live until another editor reviews them.

  9. once those are approved they are a full editor


Flow description 2

  1. new editor becomes aware of wiki

  2. decides to participate

  3. sees create new account or login

  4. clicks create new account

  5. is shown wikispot introduction unless wiki they came from has edited their own welcome. Look at how [WWW]http://stackoverflow.com/ handles the process

  6. proceeds to sign up form

    1. picks username, is given feedback if their pick ends in numbers or includes certain phrases

    2. provides email address, explain that it must be valid e-mail to proceed

    3. asked to fill out their introduction, examples are provided via link

  7. is sent e-mail as soon as some editor has seen their introduction on recent changes and responded to it. These show up in recent changes as new Users/ page, but with different colored event tag

  8. is free to make edits, banner on page reminds them that their first 5 edits are not going live until another editor reviews them. They must collect their 5 approvals from different editors for them to count. So if someone approves their first five edits, then they still need to make 4 more that will be approved by 4 other editors.

  9. they make their first edit, it goes into Recent changes as "suggestion" or with some other edit tag.

  10. anyone who glances at it and doesn't think it abusive can click "approve" and it will be live on the page. If someone tries to edit a page with a pending suggestion they need to either accept or reject the suggestion. if rejecting a suggestion you have to explain why.

  11. repeat that process a couple more times and then grant them full editing


Reputation Based Editing

Since IDoNotExist didn't like the first suggestion I'll throw out another way to do it. New editor starts with zero reputation points. As they gain them by actions they get more and more access to what they can do. Personally I think this is more cumbersome to map onto the wiki process, but I'd like to demonstrate to IDoNotExist how brainstorming works.

Reputation Points Ability Gained
0 make edits
10 vote on other editors actions
25 upload photos
50 make new pages
100 revert pages
250 delete pages and edit home page
500 Change Logo for a day

Each action on Recent changes can be voted up or down by editors who can vote.

Don't tell me why this won't work, suggest something better.

Scalable point based reputation system with automated feedback

  1. Each user starts with x points.

  2. Gain points slowly over time for editing without having your edits flagged. (Say, 1 point per day on days when you make at least one edit.)

  3. Lose half your points for posts that are flagged.

    1. (The number of points lost might go up if lots of people flag your post, or be low if only one does).

  4. If your score drops too low, you can't edit for t time. The value of t doubles when you drop below certain thresholds. Eventually, this prevents you from editing at all.

  5. To flag (limited to editors with enough points), you select a flag reason from a drop down menu.

  6. If someone flags your edit, the reason is placed in a box above the next page you view. You will know immediately why someone has flagged your edit. Links to more info can be included.

    1. This keeps editors from having to type out reasons every time. This provides all the needed information every time, as well as corrective feedback, without editors having to spell anything out individually.

  7. Editors can be flagged for malicious flagging, to prevent abuse.

  8. Points do not affect *what* you can edit. Only how often you can do so.

  9. Edits from low scoring users can be highlighted or marked with an icon to indicate that they come from a source with a poor reputation.

  10. Note that this method allows someone to show that they can improve their behavior over time by acting positively, but effectively bans them automatically if they behave poorly. The value of x can be tuned so that you can unintentionally make mistakes as a new editor (as many people do) and not lose the ability to edit, but if you continue to behave maliciously, you lose your ability to edit very rapidly.

One issue with this method is that if they create a new account it is given the default trust and then we end up with RealComputers01, RealComputers02, RealComputers03... —JasonAller

Flow description 2, Lite version

"I propose that in the future new editors should not be able to make any edit until they have introduced themselves and had their intro given the thumbs up by another established editor. Then they should be able to suggest edits using the edit tools that full editors use, but their edits won't go live until approved by established editors. After say five good edits then they can edit."
In principle I think that Jason's suggestions are excellent. Keep it as simple as possible, whatever is easiest to implement, and modify it later if needed. Thus I think reputation points are too complicated.
I don't know that they need to introduce themselves, but I see the advantage of requiring the first few edits be vetted by another editor. That could reduce the worst edit problems: the drive-by anonymous postings, and the business owners/managers who try to manipulate their pages inconsistently with the spirit of the wiki. See if the edit-approval probation accomplishes what you're after.
So a slimmed-down version of flow 2 above:
1. Sign up and choose a user name. If they use a pseudonym, editors provide link to the reasons-to-use-your-real-name page.
I agree that requiring an email address is a good idea. There are anonymous options for people who want that, and they're probably already aware of those. But I think that just the act of requiring an email registration could reduce the worst edits.
2. Try to edit; get the notice that the first five have to be approved; editors see it in 'recent changes' as suggested above and act on it. Explain rejected edits; probably a page of FAQ's would suffice.
3. After five edits are approved, they have free run of the board. —DonShor

7. Editors can be flagged for malicious flagging, to prevent abuse. That will make it interesting. Frankly, I'd be tempted to flag about 75% of the anonymous negative comments that get posted. I think that's about the percentage of either retaliation or malicious business competition posts that we get. —jimstewart

My input:

1. The point system could work both ways, allowing established editors to downgrade malicious editors, but also giving malicious editors to ability to downgrade established ones.
2. Edit wars are annoying enough. In my opinion, the point system would provide nastier, more abrasive ammo for edit wars.
3. Jason's proposal is a manageable, but I personally don't think its necessary at this time. Sure we do have small problems on here, but I've always enjoyed seeing wiki editors come together to find solutions.
4. I appreciate the open-forum aspect of Daviswiki. The freedom to edit any page on Daviswiki fosters healthy discussions and a collaborative and egalitarian community. I want to keep it that way.

Bottom line, leave things as they are. —jefftolentino


Good points about a reputation system possibly leading to another version of edit wars (god, we don't need that!) and the need for better ways to get the attention of new editors. Thus, I think it's worth considering Don's "slimmed down" version of Jason's proposal. As long as we can find better way to integrate new people into the community that's easy on gnomes and easy for new editors, I am for it. —cp

Flag new edits approach

  1. People make account pretty much as usual.

  2. People edit selected wiki as usual.

  3. If that user has less than 10 edits, or if wiki_edits_global/wikis_edited < 5, then their edit appears as light blue or lime green or something on the Recent Changes page (IWRC too).

  4. Other wikizens pay attention as needed, and help to introduce people to the wiki who have screwed up their first few edits.

This has the advantage of being decently easy to implement, too.

The point of this proposal is: Bullshit barriers to entry turn me off, and I wouldn't start to contribute to a community that has them. Even account creation turns me off, and we already have that. The wiki needs to continue to grow, despite the huge content here, and we need more super-active editors who actually live in Davis.

Having a reputation point system sounds like a Wikipedia style bureaucracy, which is far too annoying for a small community like ours. I feel that I should remind you all that Barnstars are only awarded on dwiki for Excellence in Trolling. Reputation is a very person-to-person thing, and if you don't know a person's reputation then you should go out and meet him/her in person. This is a local wiki, after all. —BrentLaabs


Look at the guy editing the rodness page now, it should be made clear that your user name is also a page with which people can communicate with you. Sagat also took a while to figure out that the name was a page, and that is after I told her in person... —StevenDaubert

Whatever approach is implemented should block individuals such as kato from their ability to continue deleting pages. I think requiring email registration and a limit on early edits would probably accomplish that. —DonShor

I have wanted to code an Allerbot for sometime now, it would have certain functionality like welcome newly registered users, and give them small wiki primers. It could also auto protect / create a talk page / inform parties if a certain formula is met, (multiple deletions, etc, it could be fun) My code just isn't the sharpest Daubert.

Re: back-and forth deletion, perhaps some limit could be established, e.g. if user delete the same page X times within Y hours, the system automatically places a deletion moratorium on that page (for all users, lest our vandal-suspect uses multiple IPs or creates new accounts) for some period of time and must be unlocked be an admin, or if admins are unavailable, frees itself from the list after Z days (unless vandal-suspect tries to blank out the page content in the meanwhile). [N.B.: if this sounds clunky, I'm inclined to agree, but I just want to throw some ideas out there] —EBT

The “Vote” (read: informal poll)

To summarize the proposals so far, we have:

  1. Flow description 1

  2. Flow description 2

  3. Flow description 2, Lite version

  4. Reputation Based Editing

  5. Scalable point based reputation system with automated feedback

  6. Flag new edits approach (as described by the heading of the same name above).

  7. This is the same as #6, but with additional Gnome tools (and clarification of intent): Add informational tools to easily spot new users or questionable edits (like "same ip, different user") on info pages, add new management tools to combat real world issues (such as "revert all changes in the last 24 hours by this account"), but have no mechanical restrictions on content or editing that distinguish editors when editing content. Or, to sum it up: On the content side, all editors are equal and content is open to all, as it is now (i.e., no change). On the information and reporting side (Info tab, Userinfo and Recent Changes), add more options for filtering and flagging, preferably customizable.

  8. Do nothing.

  9. Flag edits made by new editors on the content of the page itself (not just in Recent Changes)

  10. Show up at new editor's houses with a bottle of scotch. Or at least have community cooperative shared learning sessions where people support each other. Share, learn, enjoy, talk. Kick the editing community off the durn wiki and inject the community of people in. Find a place, bring a laptop, tell people. And grow1 from there.

  11. Allow special privileges to donors during fund drives. (i.e. maybe any edit war can be temporarily "won" by out-pledging "offending" editors. Just an idea. Might be fun.)

These are all labeled with headers in the above text. Please add any that may have been missed. Out of respect for your fellow editors, please be sure that you've read and considered all of the options and what may have led to their proposal before expressing a preference. Then "vote" below.

Why are we voting? This isn't an editorial issue. It's not like we can just decide this and then it will be magically implemented. The idea here is to come up with ideas and discuss them, not dictate what is in the next version of the software. —WilliamLewis

This is a Wiki Spot wiki. Wiki Spot is a 501(c)3 non-profit organization that helps communities collaborate via wikis.