Article validation proposals/New

DiamondGeezer's Proposal: Karma Quality Editing

Each registered user has a "karma" attribute assigned to them.
Each SysOp has a karma of 500. Every designated "editor" has a karma of 400 (this would be a new attribute for each contributor)
When a new article is written, the karma of the author is increased by 5 points.
Every time an article is edited, the modifications are made to the wiki instantly, but are stored for a finite period (Bureaucrat settable parameter) and the author is informed of an edit to his/her original article. The modification is shown in a different color until the edit is accepted.
If the edit is accepted, the karma of the person who made the edit is increased by +1
If the edit is not accepted, the karma of the person who made the edit is either zero or reduced by 1.
If the edit is rejected, then the editors are informed of the rejected edit. If an editor decides that the edit is justified, then the edit is put in and the karma of the person who made the edit increased by +2. If the editor decides the edit is not justified, or if the editors do not respond to the edit at all within some (bureaucrat-set) period, then the edit is junked and the originator informed that his/her karma has been decreased.
If a contributor's karma reaches the level of the editors, then the contributor becomes an editor (if he/she desires).
If a contributor's karma reaches some low point (like -25) then the contributor's edits get bumped straight to the attention of the editors.
If a contributor's karma reaches some minimum (like -50) then the contributor's edits get immediately thrown in the bin.
If a contributor does not have an account, the IP address gets a karma of zero. If the edit is accepted, then the karma of the contributor is not increased, but if rejected, then the karma is decreased.
The bureaucrats can decide that if they have an authoritative expert, then that person's karma can be raised to whatever value up to an editor.
The editors have the discretion to punish vandalism with more negative karma.
Each article has a star-value (like the barnstars). The more stars the article gets, each star adds +1 to the author's karma (up to a maximum of 10).
There can be more than one author assigned to an article, up to a maximum of five.
If an article is deleted then 0 to -10 points are taken from the author's karma at the editor's discretion.

Discussion

This means that vandalism is discouraged, sensible contributions are rewarded, idiots get less and less attention until they effectively ban themselves. Bad articles or troll articles are a quicker way to get the contributor to give up their privilege to contribute to the wiki.

Editors and stylists (such as what Project Galatea are trying to do) would exercise weight to preserve the contents of the wiki from attack, increase the intellectual weight given to authors of particular articles.

Everybody can contribute to the wiki regardless of background, see instantly the results of their efforts and quality is rewarded.

Branchless Stable Versions

Heres a simplified proposal with a lot of flexability (copied from my post to WP):

Each article has a stable marker, as well as metadata for each revision that shows if a revision was ever marked stable. Appropriately permissioned users can move the stable marker forward to a newer version.

Versions are referred to as "stable" and "proposed" - this reflects that the "proposed" versions are more likely to contain errors, POV, ommissions, and that they don't reflect final products.

Users without accounts default to seeing the stable version, and the software is set up so that search engines will only see the stable version.

A stable tab and a proposed tab are added to the interface to switch between the proposed and stable versions.

Because the stable version is just a marker, its not possible to edit the stable version directly - edits have to take place in the "proposed" version, therefore all edits stay on the trunk, and any rework to the stable version has to incorperate the changes of subsequent proposed versions.

Hopefully this will be workable - Stephanie Daugherty (Triona) - Talk - Comment - 15:49, 24 January 2006 (UTC)[reply]

Added - This could also be adopted to the current Wikipedia:Featured Article system, placing "Featured" tags at revisions that truely stand out as the best possible work our community can offer. - Stephanie Daugherty (Triona) - Talk - Comment - 15:52, 24 January 2006 (UTC)[reply]

Added more, still brainstorming For that matter, if we do tagging, multiple tags are possible, with different levels of access to update them - featured, reviewed, stable, draft, and proposed - the "revisionlevel" of any revision could be raised with the right access, but never lowered, the newest revision with a certian tag or a higher tag is considerd that version that represents that status - if you request a "stable" and theres a "featured" thats newer, the "featured" version is returned - could work like this:

Proposed Versions are the current work in progress.
Draft versions are tagged by any logged in user.
Stable versions are tagged by any logged in user that meets the appropriate criteria (probably total edits, time editing, community consensus or come combination of the three)
Reviewed versions have withstood a serious peer review and all signifigant deficiencies have been fixed.
Featured versions have survived each of the above processes and have met the criteria and consensus for Featured Article status.

These versions could easily be numeric "approval levels" internally, making it easy to code - each class of users has a maximum level they can tag at, as well as a level of tag that they see by default when viewing articles.

Comments? - Stephanie Daugherty (Triona) - Talk - Comment - 16:03, 24 January 2006 (UTC)[reply]

Branchless stable version - Kevin's mods

Article (stable-version) - URL:"http://en.wikipedia.org/wiki/Mathematics/stable"

Click where a thumb would be to flip to thumbs up(approve), click again to flip to thumbs down(disapprove). overall rating is shown in horizontal bar. Current stable version (highest rated) is highlighted. (sorry about the bad image editing)

Same as above before "Added...."., with the following modifications:

Each article has a stable marker, said marker cannot be moved explicitly, but is calculated by wiki software, as the version with the most approve minus disapprove votes:
- Votes are approve/disapprove (or no vote)
- Votes are made & shown in edit history and diffs.
- All logged-in users can vote on any article.
- Only the most recent few (say, 5) (approve or disapprove) votes per user per article are active, older votes are expired to "no vote".
- Votes older than the xth (say, 3rd) most recent stable version, where the voter has not voted since said stable version, are expired (set to no vote), to prevent people not participating from causing stick.

Semi-automation. Also, there will be a software aid: "Stable" versions are generally just that: stable; they haven't been edited in a while. An automated mechanism could go through the history and mark revisions with a tentative measure:

k * e^(-c*age) * e^(d*[time before next edit])

where c is the decay rate (more recent versions should be prefered) and d is the stability unit. both c and d could be inferred statistically per article, since some article are edited a lot(high d) and others not-so-much(low d), and some articles are about current events(high c), and some are about dead events(low c). Revisions with a high such measure are candidates for the next "stable" version, to be selected by community approval.

Furthermore, on the history page, one could filter versions to see only the top handful (say,8) of stability scorers (and the current stable version), with current vote counts, and then look at the diffs, and vote. Kevin Baas^talk 22:27, 24 January 2006 (UTC)[reply]

And admins could set pages to automatic instead of semi-automatic. In automatic, the software will determine stable version based on the stability score, rather than community vote. This would be usefull on pages such as "current events". Kevin Baas^talk 23:06, 24 January 2006 (UTC)[reply]

Oh, and on the history page, little graphic bars showing the stability measure and approve-disapprove. (different colors). This is trivial to do. It's just a 1-pixel image given a certain height, and whatever width you want. Kevin Baas^talk 18:25, 26 January 2006 (UTC)[reply]

Validation by community assent

en:Wikipedia:Community assent is only for policy and guideline pages. There is a goal to allow those that want to be bold to work together with those that want consensus first and still maintain stableness in the policy and guideline pages. This stableness is achievable with this guideline for validation, which establishes a deliberative consensus over a specific version.

The basic idea is to mark a specific version of the policy or guideline page for nomination, and someone else must second the nomination. Once there is a second, a copy of the specified version is placed on a new subpage, and discussion continues on the new talk page for consensus about that specified version. The process is based on some parts of en:parliamentary procedure combined with ideas to implement stable versions of articles.

If consensus fails on the new talk page, the subpage will eventually be deleted. Before its deletion, a summary of the reason why it failed will be added back at the original talk page under the nomination or, if the nomination has been archived, simply appended with reference to the nomination.

If consensus maintains supports of the version, an appropriate measure is made to effectuate the assent. This may simply mean that the subpage remains protected from edit and deletion, and a link is added on the original page for reference to the current version assented by the community.

This allows for development to continue on the original page, which is always considered instruction creep until there is community assent. Since "votes are evil," the subpage allows an appropriate place for the consensus to evolve. Even with community assent established, it neither means there is a final decision nor that everyone has individually consented.

Please see en:Wikipedia:Community assent for further reasons and details of the coherency poll and deliberative consensus. Dzonatas 01:01, 4 March 2006 (UTC)[reply]

Article Branches + Display Precedence by Voting

I suggest not having one article, with its versions recorded, but instead having an arbitrary number or articles (branches), each with its versions recorded. (See e.g. Concurrent Versions System for such a branched version control)
Each article has a display precedence value, the article branch with the highest value is shown as default article (front branch) when an article is looked up. The other article branches are accessible by extra clicks (the higher the value, the easier it should be to access/display that article branch)
The display precedence value relates to user popularity, measured by voting (possibly modified by some time decay)

Thus the concept of the article would be gone.

Instead we would have the possibility of having alternative articles (article branches), a major improvement, as even in a field like mathematics there are often alternative ways to write something up (otherwise we wouldn't have hundreds of different calculus textbooks). As each article branch would have its own history, it would allow to have different teams of authors working on their view over a long time.

While article branches are technically equal, they all would compete for the easiest display/user access - to be the front branch.

The user is the souvereign, he decides which article branch is the best by voting. (An addition could be an external reference counting ranking, a la Science Citation Index or Google's page rank algorithm)

My original proposal can be found under Wikipedia:de:Benutzer:Marc van Woerkom/Alternativen. --Marc van Woerkom 02:03, 8 July 2006 (UTC)[reply]

Organic verification

I love wikipedia.

I want wikipedia to be: 1. open 2. comprehensive 3. accurate

There is an inherent tension between quality(as seen by an expert) and openness. A critical aspect of our wiki is its popularity, Now, if the structure of wiki is changed to make one particular version of an article more authoritative, by definition: some guy who changes something will see his change automatically reverted, or invisible or hidden under some link or etc, this is a very undesirable thing because the ONE thing that has made wiki so powerful is a new user typing: "TESTING TESTING" any change to wiki that prevents this first dip in the water is fatal... take it away and the curious user will lose interest and we him... and as big as wiki is, don't kid yourself wiki will always need new blood. So... what to do about accuracy?

I think everyone would agree with the following: the essential problem is: we don't have enough experts with enough time to go through every change, find the bad ones, revert them, AND have enough time to find and fix up bad article AND put meat on stubs. What we need is a way to improve the situation.

I am a believer in techno solutions but all improvements must be focused on the psychology of the users. I believe that JW is a visionary. In the features and policies that he has adopted; but much more importantly in the ones he hasn't adopted, he has resisted (so far) the urge to "protect" wiki thus giving it its power.

Finally I’d like to present my own proposal, which although small, has been mulled over for a long time. (please note that the wording, format or options in this proposals are just general suggestions and should be changed to whatever seems better), but essentially:

you (any user) open an article and see bad quality... you click on a link asking "does this article need improvement?"... you select options indicating the article has problem(s)... the article goes into a category of less-than-perfect articles and automatically gains a header stating "this article has been reported as not being of high quality". and it will stay that way until someone makes ANY non-minor edit to the article... at the same time a link on the main page points users (or just experts) to problem pages.

Notes:

this is not the same as the recent changes, watching reported articles is much more efficient at finding real problems.
users will become a lot more involved
bad editors will get quick feedback on their work without the need for a tough skinned expert with plenty of time to come along and battle it out with them just for the stubborn guy to revert everything tomorrow.
good expert editors can rest easy as their work will be protected by the common sense of the silent majority who will not get involved in edit wars but can make a great difference if the process is convenient
there is no positive vote. wikipedia is incompatible with positive selection. anyone trying to build a method of validation based on positive selection will always hit mountains of rules, loop holes and disaffected users. it is impossible. its an inherent aspect of wiki.
any single vote can put an article in the less-than-perfect category. though alternatively the number of people reporting the article could push it higher and higher up the bad article ladder
this feature is very easy to setup and would not change the structure of wikipedia in anyway

thank you for your time --58.106.21.27 12:01, 23 August 2006 (UTC)[reply]