Wikipedia

Wikipedia:Gather/Moderation Criteria

< Wikipedia:Gather
The concept of grouping articles and labelling them already exists in books maintained by community., as well as the long requested wishlist features of watchlists which also represents the same type of content, even if the functionality is different. This discussion might better serve the point of discussing how all similar kind of content would be treated, including user books, watchlists features, and Gather collections.


Draft

Note

edit
  • Abusefilter is planned to run on created lists. The feature was launched on beta on March 30, and the purpose of this discussion is to decide early on how different user groups could act/correspond to flagging of lists. Admins are suggested to take role in flagging preview, but this could entirely change upon agreement. The whole moderation scenario could change upon suggestions and agreement.


About

edit

On English Wikipedia we want to hide collections that damage the fabric of our community or cause harm to a private individual. This is a living breathing document. Since it is a new feature it will change with usage and we encourage administrators interested in moderating to edit this article and help us reach a consensus on what is or is not appropriate with regard to collections.

Collections are a way to navigate, share and discover wikipedia articles. They are not articles and the standards that apply to Wikipedia articles do not necessarily apply to Collections. For instance, a collection with the name "The empire state building is the shortest building in the world" by user3232 should live! It is a personal opinion and clearly so. In some cases, like here some users might be creating problematic lists that would need action from the community.

* What do we want to achieve from moderation?

Ensure that legal policies are met
Adopt from policies on books deletion

* What do we want to avoid in moderation?

Overloading admins and other editors
Making the process too complex, or closed that slows actions when needed to be taken, fast.
Vandalism such as creating a list with a negative name and adding inappropriate articles to it

  • In terms of moderation, user groups could be divided into:
  • Anyone can flag a list.
  • Users with Gather-Admin Privs can view all lists including both those entirely deleted and hidden
  • Users with Gather-Admin Privs can view all lists that have been flagged more than X% of users.
  • Anyone can view lists including flagged (that have not met cutoff above)

Current Status:

edit

Moderation Criteria

edit

Our main objective is to ensure that legal policies are met, but a secondary objective is to maintain a safe community.

Open question

edit
  • What happens with flagged once, or flagged twice?
  • Users can suggest, to the list creator, or adding/deleting articles from a specific list?
  • In the upcoming sprints, forking collections will be made possible, will this help with moderation?

Proposed workflow:

edit
  1. List is created.
  2. Anyone can see it, anyone can flag it
  3. If list has X flags (or X% flags), then list is automatically "hidden-for-review"--now only Admins can see it.
  4. An admin looks only at the lists that are "hidden for review" (if they want)
    1. decides the list should be hidden
      1. Admin hides list and it is removed from "hidden for review" list.
      2. List is now in the (hidden list)
    2. If decided that the list is fine
      1. Admin marks list as reviewed and it's flag counter is reset
      2. List is now viewable by anyone
    3. Future: decides that list should be deleted. List is removed from sight by anyone except __X privilege.


Proposed admin-free workflow:
edit

Anyone can flag a list, where this will log the list in Special:Gather/review page, and deactivate it, re-directing the lists's shared URL to a page that says "this list is currently disabled". Actions are logged and could be reversed by a dedicated group, that is interested in lists maintenance tasks.

One of the risks of this approach is that you combine the worst of the current systems with a new vulnerability and a new workload. AFC and Speedy deletion are both highly vulnerable to deletionism, but with a couple of redeeming features. Editors can mark articles as patrolled/move them out of AFC, and only admins can delete - others just tag. If we allow anyone however deletionist to delete lists then we risk a similar situation to AFC - intended as a friendlier more collaborative way to create articles but which has become a less collaborative process with an even more deletionist ethos than Newpage patrol. ϢereSpielChequers 07:43, 23 April 2015 (UTC)[reply]
Possible Alternate Workflows:
edit

Community Policy is that Wikipedia is not a social network or webhost for non-work-related materials. Editors and Admins may have no interest in being a free-labor-force for policing socialnetwork / non-work-related content.

Possible Alternate Workflow #1: The Community could set up a bot to bulk-delete such pages.

Possible Alternate Workflow #2: The Community could accept this as a WMF project, and let the WMF spend their own man-hours policing Collections for illegal or otherwise objectionable content, under any criteria the WMF decides upon.

Possible Alternate Workflow #3 - proposed by WereSpielChequers: Make this more like newpage patrol so that we know which lists have been patrolled, which lists have been deleted and why.

  1. All new lists appear as unpatrolled when first created unless they are created by an editor with the admin or autopatroller right.
  2. All New lists go through recent changes patrol so they can more easily be processed.
  3. Any confirmed editor can patrol any list unless they created it, but your patrols are logged so we can spot the people who should be told to stop patrolling
  4. Any editor can flag a list for admin attention with one of a number of the speedy deletion criteria, including G10 - attacks, G3 - vandalism and G7 - creator requested.
  5. When a list is tagged for deletion the list creator is automatically sent a talkpage notice.
  6. Lists tagged for speedy deletion appear at CAT:SPEEDY so that admins can easily process them
  7. Lists are deleted not hidden and as with any other deletion the deletion reason is recorded
  8. Admins can "salt" list names if there are good reasons to prevent their re-creation
  9. When an admin deletes a list they can still see who created it so if appropriate they can block or warn them.
  10. In compensation for all this unnecessary work that the devs have foisted on the community they should do something useful such as fix some of the phabricator and Bugzilla requests that would halve the number of edit conflicts and thereby make this site much more friendly to newbies.

Possible Alternate Workflow #4 proposed by WereSpielChequers : Make this more like a watchlist. Change them so that only you can see your lists, so nobody cares what other people's lists contain.

The current lists could be made private or public --Melamrawy (WMF) (talk) 10:23, 15 April 2015 (UTC)[reply]
They need to be Private only. Remember these are not currently in userspace where we give people quite a bit of slack, these are designed to look like they are in mainspace, so all mainspace deletion criteria should apply. ϢereSpielChequers 08:24, 16 April 2015 (UTC)[reply]

Lists Protocol

edit

What we hide:

edit
  • private, personal information (such as social security numbers)
  • threats of violence, sexual exploitation, theft, vandalism, or other financial harm.
  • shaming, bullying or harassing private individuals
  • hate speech(?)
  • collections where the title and description are not consistent with the content and the content could cause offense: i.e. "Happy bunny pictures"--> collection with images of torture
  • collections with "Wikipedia" in the title or description that suggest the collection represents the official position of the encyclopedia
  • collections where the name or description contains personal details e.g. an e-mail address or telephone number or postal address or other similar sensitive information.
  • statements that are false
  • opinions we disagree with - you may consider that certain notable people are ugly, but don't use Wikipedia to publicly display your list of people you consider ugly

Reasons we do not hide:

edit
  • statements that are false
  • opinions we disagree with
  • collections that are trivial or meaningless
  • collections that are humorous
  • collections that with "Wikipedia" in the title or description that do not suggest the collection represents the official position of the encyclopedia (e.g. "Wikipedia articles I helped with")

Messaging

edit

In this sprint, we will be working on notifying users where their lists in hidden.

  • When you hide a collection, email or put on the owner's talk page the following message:

Hi,

I am an admin for Wikipedia and am helping to keep Wikipedia a positive, safe place for everyone.  I hid your list from public viewing because it was ___

If you have any questions or concerns, please respond to this message within 72 hours.

~~~~

NB Make a note of the user name before you hide a list as you may not be able to find it afterwards

Unhiding

edit

If you unhide a collection, please email or put the following on the owner's talk page:

Hi,

I am an admin for Wikipedia and I unhid your list, because it does not currently violate our standards of conduct for collections.  I apologize for any inconvenience caused by your list being hidden. ~~~~

Alternatively before overturning another admins action and unhiding a list you might want to check with the hiding admin why they hid this - remember unlike blocks you can't leave a hiding rationale so you would need to check with the admin concerned. You also need to check what else the editor has had deleted, sometimes you need that bigger picture to understand the pattern ϢereSpielChequers 08:19, 16 April 2015 (UTC)[reply]

Valid use of this feature

edit

These are some potential valid uses of this feature or an enhanced version of this feature

  1. Editors could create a list in their userspace such as "articles I started" or "articles I took to FA"
  2. Wikiprojects could create lists as a sub page of the WikiProject showing "FAs tagged to this WikiProject", current "collaborations of this Wikiproject" or "Articles in the deletion process and also tagged to this WikiProject"
  3. Editathons could have sub pages with "articles worked on in this editathon", "created in this editathon" or "talkpages where issues were resolved in this editathon"
  4. Readers could curate groups of pages they were interested in as subpages of their userspace (this would require scrapping {{db-U5}}).

Comment: It's hard to see any real value for editors here. It's trivial and infinitely more flexible to make lists using [[law]] [[science]] [[religion]].

Also, {{db-U5}} explicitly does not apply to anything related to our work here, nor to any user with non-negligible contribution history.

Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Gather/Moderation_Criteria&oldid=859519105"