An edit type taxonomy for detecting/evaluating contributions better than edit-counts – differentiating copyediting, wikilink additions, removals, and expansions (each with metadata such as text-length added)

[prototyperspective]

First proposed this here: https://meta.wikimedia.org/wiki/Research_talk:Wikipedia_Edit_Types where you can find some relevant information.

Main edit types of that integrated or parallel taxonomy would include:

• copy-editing where contents were only slightly changed and/or ancillary changes like adding a reference, adding wikilinks to the existing text or adding subsection-headers were made
• expansion for adding new content (not as fine-grained as distinguishing whether whitespaces or text has been changed but detecting whether or not whole new sentences were aded)
  • here additional metadata would be how much content was added and stayed on the page (here the text of references would be removed from that; the number of refs added could also be metadata)
  • furthermore, it would for example detect how many "see also" wikilinks were added and how many categories were added; this would also be metadata
  • it would need to be able to detect if some contents of the article were just moved around in a slightly changed manner; in such cases the boundary to copyediting would be somewhat fluid
• revert for reverting other users' contents and/or removals
• newarticle for creation of new articles or turning redirects into new articles and so on
• talk for new talk page threads (and posts)

Here are some examples how this could be useful:

• make it easier to quickly understand changes at a glance or to filter them (for example on the GlobalWatchlist)
• allow for certified badges users are given, similar to plain edit-counts
• gamification, feedback and contribution-summaries: many other open collaborative contributions-based sites use these as core features of their sites. They could also give a clearer view of one's contributions and substantially motivate both newcomers and, for retainment and increasing contributions, existing editors. There is some research showing that this is part of what makes the stackexchange websites so successful and users more active there. It engages users and keeps contributing interesting. It also allows for setting personal goals like some badge.
• certified badges could enable users to prove anonymously or pseudonymously that they're contributing for some real-world benefits that is not linked to what they're doing in specific (only that it's constructive and the amount of it), it could be called proof-of-contribution
  • Maybe the usefulness of that one becomes clearer if one doesn't only consider the near future and considers things like universal basic income or degrowth or 4-day work-week proposals – ideally free/leisure time shouldn't be used for unsustainable activities and this could be used to encourage more constructive participation as well as for rewarding constructive work (not just Wikipedia-editing but later maybe open source software and science as well; this may allow for systematically rewarding and incentivizing open source software development which is currently lacking workers as well as economic support and recognition)
• users could have badges or other kinds of more relevant info than edit counts on their userpages, partly this is just for motivation of the editors themselves; this would also be relevant to these xtools stats where one can see charts about one's contributions
• better allow for campaigns where one can see fine-grained stats of a project's results or of a competition's individual participants' contributions; relevant is imo the so-far best Wikipedia contribution competition here which I think was however slanted/biased towards translating articles than anything else of the above edit types (translation could be another one)
• better recognition of users' work or any recognition at all and in a way that is reasonable and not random numbers that don't really give much of an insight to the level of constructive contribution a user has provided (like plain edit-counts where each edit can be small typo fixes or run semi-automatically using some script without any distinction from extensive edits; note that showing insights about more reasonable stats would also make users opt more for these rather than just increase their plain edit counts)

It's not only edit-types but in some sense also task-/activity-/contribution-types. Of course a caveat here is that this differentiated detection of edit/contribution-types should not incentivize nonconstructive editing such as removing lots of content or adding way more text than appropriate to an article for the sake of it (for these stats and/or badges etc), there are many ways this could be addressed and I don't think it would be problematic, just like having edit-counts doesn't create much bias whereby users opt to gain very high edit counts. It wouldn't be implemented in a fullblown way right away at first but only e.g. via some gadget and later in the default site but in very limited form and without any real-world benefits and so on, so this would evolve and get revised over time so any problems and potential problems are addressed, just like Wikipedia itself does (via the policies, templates, norms, scripts, activities, and so on that emerge there).

---

This comment may be relevant here: https://github.com/geohci/edit-types/issues/4#issuecomment-1012532894

Thanks for your work on the edit-types, I think the potential and usefulness is greatly underestimated and I hope more people work on this. It could greatly vitalize Wikipedia and catalyze a new level of constructive contributions and even the entire open movement in a way nearly nothing else can and so far I don't know of any similar approach or project.

I'll probably update and edit this issue over time as I get new ideas concerning it, and maybe somebody who sees the value of this even has the time to make some pullrequests that adds some initial version of this. I do see how there are more near-term and easier-to-implement this could be used for and that it would probably need more devs to help out for this to get built any time soon. Again, like metascience could improve science (efficiency, reliability, quality, human resources, usefulness, ...), this could increase Wikipedia editors, quality and engagement.

[geohci]

@prototyperspective thanks for these inputs and your patience with me putting together a response! I put together the start of something similar to what you're proposing but with some slight tweaks and I'd be curious to hear your thoughts:

revert for reverting other users' contents and/or removals

Yep -- this can't be determined via the library but in my initial analyses using it, I've incorporated our standard revert-detection approaches with edit metadata (edit tags; shasums) to separate out edits that either were reverted or were the revert. You can see that here in an exploratory analysis though I left patrolling/vandalism as a single category but in the future will separate them out: https://public.paws.wmcloud.org/User:Isaac_(WMF)/Edit%20Diffs/Example_Edit_Analysis_French.ipynb#Example-Analysis-of-~700-edits-from-French-Wikipedia-in-2022

newarticle for creation of new articles or turning redirects into new articles and so on

Creating new articles is best determined external from this library (because an empty parent revision could also be because someone blanked the page) but agreed that it's an important aspect to pay attention to. I haven't added functionality to detect redirects for similar reasons because it also feels best determined separate from the library. It's not impossible but it is slightly tricky: the mwparserfromhell dependency I use for parsing wikitext detects #REDIRECT as a # tag followed by REDIRECT text so I'd have to do some hacky things to check that they appear next to each other and on the first line.

talk for new talk page threads (and posts)

I haven't tweaked the library yet to handle talk pages well though that's on the list. All of it should work fine but I'd like to add explicit functionality for replies, links to user / project talk pages, and signatures. Otherwise, they'd just be tracked as lists, text formatting, and wikilinks.

• copy-editing where contents were only slightly changed and/or ancillary changes like adding a reference, adding wikilinks to the existing text or adding subsection-headers were made
• expansion for adding new content (not as fine-grained as distinguishing whether whitespaces or text has been changed but detecting whether or not whole new sentences were aded)
• furthermore, it would for example detect how many "see also" wikilinks were added and how many categories were added; this would also be metadata

I broke these down into three similar but I think slightly different categories:

• Content Maintenance: altering existing content and making smaller changes, especially stylistic. So similar to your copyediting category. As you say, hard to tell the boundary between this and expansion. I do include adding references here but am not sure that's the right place -- maybe should actually be in my annotation category below?
• Content Generation: equivalent of the expansion category you mentioned though maybe I have a slightly broader definition? In practice, this includes inserting new templates w/ parameters, adding new parameters to existing templates, adding sentences, adding tables (or cells to existing tables), adding media or caption/alt-text to existing media.
• Content Annotation: the goal here is to capture edits that are more about metadata than content (which I think you saw as additional data to provide alongside copyediting/expansion as opposed to a new category). I also include links as part of this because it feels like a similar goal of making content be more discoverable / connected. So in my version, this includes adding categories, wikilinks, external links, and templates without parameters which is a proxy for things like taxonbar and many of the Wikidata-powered metadata templates. If existing categories etc. are just being changed, I group this under content maintenance because in practice this seems to be more about style changes that actually adding more annotations.

Here are some examples how this could be useful:

Thanks for listing all of these out! I'm working right now on getting it in place where it could potentially support these or others. The main challenge is having a pre-computed dataset of edits and their associated types so tools could easily be built around it with having to compute them themselves.