Measuring merit in Wiki editing

Posted by dieterdreist on 28 June 2018 in English (English).

# The wiki The OpenStreetMap Wiki is a great resource of information, with a huge, active community (603 different editors in the past 30 days). This community is highly diversified, many people make the occassional spell-fixing, small addition or clarification or removal when something doesn’t seem completely right to them, there are people mostly translating content into their local language, people obsessed by organization and structure who reorganize and “templatetify”, specialists who care only for specific fields of endeavour, people who make elaborate proposals with subtags to cater for many details and all eventualities, or that set up page stubs for newly discovered tags, or local comunities organizing mapping and events, software and operations documentation and much more.


While the following could in theory apply to all wiki pages, it seems that most contested edits are regarding tag documentation.

With all the people editing the wiki, some edits are not in line with the general thinking for one reason or the other (as you can see for example from discussions, as the “general thinking” currently is hard to measure). Many of these (relatively few) edits are caught and fixed or reverted within a day or so, but some escape the eyes of the community and remain for months and even years. New mappers and, even worse, app developers read the pages and use the tags as they are documented, and after some time the original meaning cannot be held up any more, because too many different objects have gotten the tag as well.

Rating wiki edits

I think it would be great to have a system to rate wiki edits. Something simple like a thumbs up, thumbs dowm button and optionally a comment. This would not only facilitate finding out about the consensus of the individual wiki modification but could also be used to determine some kind of positive or negative reputation of the editor.


## Exclusions Some edits (all edits to proposal pages, includes voting on these pages) should be excluded from the rating. After the voting or setting the status to de-facto, the proposal pages shall be frozen and archived (as it is currently done). Eventually rating could also be excluded on creation of a new page by the creator (except for key and tag definition pages), but maybe it is not worth the effort of implementing it. ## Decay of negative ratings After some time (months/years) negative reputation could fade with respect to the editor (the edit would still be rated according to all votes, but the editor reputation would not or less suffer from old negative votes).

Potential abuse

I see there is also a small potential for abuse (people could rate all edits down for someone they don’t like or who is in dispute with them), but with sufficient usage it would wear out.


Unfortunately I do not know how to implement something like this, or how much effort it is, or whether there is already something that does this and could be integrated. It would be great if someone who is able to actually do it would believe this could make a lot of sense, and would help to make this happen.

Location: Quartiere XX Ardeatino, Rome, Roma Capitale, Lazio, Italy

Comment from Jean-Marc Liotier on 28 June 2018 at 15:02

Re: implementation, have you looked at Mediawiki’s Article Feedback extension ? Looks like work in progress, but this could eventually fit this requirement.

Comment from 30303020 on 7 July 2018 at 21:02

Sounds like an interesting idea even though I do not know who should do all the reviewing. During my edits, I sometimes experienced situations where singular pages seemed to be guarded by users checking all incoming changes and reverting them if they deemed them wrong. On the other hand, some pages were »left alone« and nobody cared about any changes.

I absolutely appreciate the idea of locked proposal pages after voting.

I often heard that there is not enough tech staff for the wiki, this being the reason for the failure of most innovations. I therefore think that installing a maintainer for the wiki would be a great thing along with efforts to reduce maintenance requirements.

  • One option could possibly be to connect admin/moderator jobs across and (like global user blocks or interconnected spam avoidance).
  • Some processes in the proposal process could be automated (automated voting evaluation, page protection, partial post-voting cleanup, archiving …)
  • Better implementation of watchlists: I sometimes miss changes because the watchlist displays the following change only. I did not yet found a way to permanently subscribe…

I would also suggest updating admin/sysop lists. I have the feeling that there is currently only one admin available upon user request (reviewing changes, deleting pages, etc.). I do not track the admins, so I do not know whether they are still active.

Comment from trial on 8 July 2018 at 20:39

Better implementation of watchlists: I sometimes miss changes because the watchlist displays the following change only. I did not yet found a way to permanently subscribe…

On your wiki profile page select the fourth email option, you’ll get an email when one item in your watch list changes. It works fine

Login to leave a comment