Talk:Article endorsement

To me, this suggestion has one big drawback. It seems to be intended for wikipedia editors, and people familiar with wikis. (not necessarily programming though, as stated!) But the casual reader, who doesn't want to get an account and learn a lot about how to find the "best" (an endorsed) version of a page, how are they going to be able to use this scheme?
\Mike 10:44, 2004 Dec 9 (UTC)

Very nice

After looking through most of the approval or review proposals, this one strikes me as the one most fitting.

I would add one more step: A tab or other UI element that allows a reader to display the "most endorsed" version of a page, the one which has the highest number of endorsements. This may be an outdated page (many people will not update their endorsements regularily!), but the reader can compare with the current page and make up his own mind about the differences.

To combat the "many people won't update their endorsements" problem, one could weigh the endorsements by time, having their relative value fade away slowly.

Agree

I largely agree with this, see my essay: The Future of Wikipedia. This seems far superior to the article validation proposal that looks to go live. User:DavidLevinson 21:24, 22 November 2005 (UTC)

it's good

I've been thinking about this sort of thing, I'm offering my thoughts on how it could work, maybe you can incorporate some of these ideas. I use the word filter instead of endorsement.

• Create namespaces "Filter:" and "User_Filter:", these filters would be wiki articles. Of course to be much use they would have to have some protection from vandals. Particularly "User_Filter:" should only be editable by the appropriate "User:".
• Special markup needs to be implimented, I have in mind using the # mark similarly to how it's used for redirects.
• A user sets one particular filter in their preferences (there would have to be a default filter). When they load any page, the filter engine uses Pagename to determine the version to display.
• The filter engine would start with the first line of the filter page and process each line cf the following pseudo code. (assuming that larger version number=later edit date)
  • Set PreferedVersion to 0 and RequestedPage to the pagename of the page that was requested.
  • For each line in the filter page (starting at the top and working down):
    • If the line contains #INCLUDE [[PageName|VersionNumber]] and PageName=RequestedPage then PreferedVersion=MAX(PreferedVersion,VersionNumber).
    • If the line contains #INCLUDE [[PageName|FilterName]] and PageName=RequestedPage Then run RequestedPage on the filter FilterName which returns a VersionNumber then PreferedVersion=MAX(PreferedVersion,VersionNumber). As above except you're letting another filter determine the VersionNumber.
    • If the line contains #INCLUDE [[FilterName]] Then run RequestedPage on FilterName as above. More useful, as you can include the filter for all pages instead of just for one page.
    • If the line contains #RESTRICT [[PageName|VersionNumber]] and PageName=RequestedPage then set PreferedVersion=MIN(PreferedVersion,VersionNumber). Useful if you want to set a version of a page and not have the other filters chose a later version.
    • If the line contains #RESTRICT [[PageName|FilterName]] or #RESTRICT [[FilterName]] then process accordingly.

So on my User_Filter: page I could include the filters of other users I trust, or some other communally maintained filters and the filter processor would find the most recent version that matches one of the filters.

Observations:

• must have a system for avoiding circular filter calls, User A might include User Bs filter and User B might include User As filter.
• Could be used for people who don't like pictures of body parts, create a version of the penis article with no pictures then put this version as a restriction in your filter. The problem with this is that it might lead to some weird pseudoforking, User A removes the pictures and sets hir filter to this version, User B likes the pictures so reverts, User C comes along and adds some usefull information, improving the article, User A likes the improvements so removes the pictures to create a new version for hir filter, User B comes along and Reverts. Is this going to be a problem? It's essentially an issue where instead of using the filters to identify a validated version, people are using filters to have two different types of article with the same name.
• Can this be improved so that people can filter for different characteristics? Can I have a Readability, Comprehensiveness, and Reliability filter? I can't think off the top of my head how you would meaningfully combine them, but some editors might like to restrict articles that are deemed to be comprehensive if looking for material to add, where others might like to restrict readability if they're looking to do some editing. You could certainly have different levels of filters. A Strict filter which only includes PhDs and a Lax filter that includes anyone I've met who doesn't initially seem to be a moron.
• Might need a method to audit a filter. I set my filter to include User A, B, and C. then go read a filtered article that is bad, I want to see who's filter approved it so I can remove them from my filter. I guess I could change my user prefs instead of using my own filter, use each of A, B, and Cs to see who's it comes up on. But if I have 20 or 30 filters contributing to my filter then it might be time consuming.
• This could all be done off the mediawiki site (if you wanted to create a test version). Since this method doesn't actually require accessing the articles themselves (just the filters) anyone could set up an article endorsement system that fetches the appropriate wikimedia version.
• User interface should include "There is a more recent version than this click here to view" and also "This version is more recent than the one approved by your filter click here to set this as an approved version" This would minimize the manual editing of the filter pages.
• One drawback to this method is that it doesn't allow you to easily see who approves which versions in the history page (without some very intensive searches which probably aren't feasible on wikipedia's scale.)

Anyway, that's enough for now, I think that this is definately the way to go (ie endorsement vs validation).

Comments on the proposal

I'm the same person who wrote the filter stuff above. I've read over your proposal again and I have some comments on it.

• I don't like the idea of "endorse after N days". Anything automatic is a concern. I want to know that if someone leaves wikipedia for 6 months, their endorsements still carry weight. More to the point, if they haven't taken any action on a new version of an article, then they haven't endorsed it.
• I don't like the idea of "endorsing a user". Although including filters like what I wrote above is functionally equivalent to endorsing a user, "endorsing a user" seems a bit more ad hominem and refusing to endorse a user can lead to some hard feelings. (similar to the 'rate a user' proposal on article validation). It is really just a semantic difference, but it can make a big difference in how people perceive things.

Regression to the Mean? Or, to an extreme?

This proposal makes sense and I love the flexibility of it. It is very wiki-wiki. Creative!

There is, however, the risk of having all users endorse one other, so that all versions of all pages are effectively endorsed. This is one reason why you wouldn't want to have a user automatically endorse his/her own most recent edit - you'd end up with a system similar to that one sees now. The assumption that's made in any of these proposals is that all users who participate in the endorsement are dedicated to improving the quality and reliability of wikipedia contents. For this to work, users should be choosy - otherwise there's regression to the mean.

A related risk is the potential impact of identity on the NPOV. If I am, as an endorser, dedicated to X - as stated in my endorsement profile - I may write or endorse articles with that perspective (read: bias) in mind. There's a fine line between quality and content, and dedication to quality can easily become dedication to a particular brand of content. Instead of seeing edit wars within an article, you could see such wars span entire disciplines. Not necessarily a bad thing, but I'm thinking USA-style politics: democrats vs republicans. This would be the extreme.

Of course, these issues can be avoided.. i'm sure - any thoughts?

I'd imagine there's a relationship between the number of people endorsing and the behavior of individuals within the group... just because the wiki is free for all etc doesn't mean there aren't important design considerations.

declaring some users 'experts' and others mere 'users' would similarly affect how people interact with the wiki. some users would hesitate to edit a page since they're not an expert. the reaction upon finding an article stub is critical - you want people to think 'hey, i know something about this (or, at least, i can learn)' - because this thought is what motivates their contribution. avoiding this issue of assigning status is one thing the proposal for endorsements does very well.