Community Wishlist Survey 2021/Admins and patrollers

Admins and patrollers
25 proposals, 409 contributors, 972 support votes
The survey has closed. Thanks for your participation :)



Overhaul spam-blacklist

  • Problem: The current blacklist system is archaic; it does not allow for levels of blacklisting, and is confusing to editors. Main problems include that the spam blacklist is indiscriminate of namespace, userstatus, material linked to, etc. The blacklist is a crude, black-and-white choice, allowing additions by only non-autoconfirmed editors, or only by admins is not possible, nor is it possible to allow links in certain namespaces, certain wikis (or certain wiki-flavours, e.g. disallow everywhere except for all of wikitravel). Also giving warnings is not possible (on en.wikipedia, we implemented XLinkBot, who reverts and warns - giving a warning to IPs and 'new' editors that a certain link is in violation of policies/guidelines would be a less bitey solution).
  • Who would benefit: Editors on all Wikipedia's
  • Proposed solution: Basically, replace the current mw:Extension:SpamBlacklist with a new extension with an interface similar to mw:Extension:AbuseFilter, where instead of conditions, the field contains a set of regexes that are interpreted like the current spam-blacklists, providing options (similar to the current AbuseFilter) to decide what happens when an added external link matches the regexes in the field (see more elaborate explanation in collapsed box).

    Note: technically, the current AbuseFilter is capable of doing what would be needed, except that in this form it is extremely heavyweight to use for the number of regexes that is on the blacklists, or one would need to write a large number of rather complex AbuseFilters. The suggested filter is basically a specialised form of the AbuseFilter that only matches regexes against added external links. Alternatively, it could be incorporated into the current AbuseFilter as a specialized and optimized 'module'.

description of suggested implementation

description of suggested implementation

  1. Take the current AbuseFilter, create a copy of the whole extension, name it ExternalLinkFilter, take out all the code that interprets the rules ('conditions').
  2. Make 2 fields in replacement for the 'conditions' field:
    • one text field for regexes that block added external links (the blacklist). Can contain many rules (one on each line, like current spam-blacklist).
    • one text field for regexes that override the block (whitelist overriding this blacklist field; that is generally more simple, and cleaner than writing a complex regex, not everybody is a specialist on regexes).
  3. Leave all the other options:
    • Discussion field for evidence (or better, a talk-page like function)
    • Enabled/disabled/deleted (not turn it off when not needed anymore, delete when obsolete)
    • 'Flag the edit in the edit filter log' - maybe nice to be able to turn it off, to get rid of the real rubbish that doesn't need to be logged
    • Rate limiting - catch editors that start spamming an otherwise reasonably good link
    • Warn - could be a replacement for en:User:XLinkBot
    • Prevent the action - as is the current blacklist/whitelist function
    • Revoke autoconfirmed - make sure that spammers are caught and checked
    • Tagging - for certain rules to be checked by RC patrollers.
    • I would consider to add a button to auto-block editors on certain typical spambot-domains (a function currently taken by one of Anomie's bots on en.wikipedia).

This should overall be much more lightweight than the current AbuseFilter (all it does is regex-testing as the spam-blacklist does, only it has to cycle through maybe thousands of AbuseFilters). One could consider to expand it to have rules blocked or enabled on only certain pages (for heavily abused links that actually should only be used on it's own subject page). Another consideration would be to have a 'custom reply' field, pointing the editor that gets blocked by the filter as to why it was blocked.

Possible expanded features (though highly desired)
  1. create a separate userright akin AbuseFilterEditor for being able to edit spam filters (on en.wikipedia, most admins do not touch (or do not dare to touch) the blacklist, while there are non-admin editors who often help on the blacklist).
  2. Add namespace choice (checkboxes like in search; so one can choose not to blacklist something in one particular namespace, with addition of an 'all', a 'content-namespace only' and 'talk-namespace only'.
    • some links are fine in discussions but should not be used in mainspace, others are a total nono
    • some image links are fine in the file-namespace to tell where it came from, but not needed in mainspace (e.g. flickr is currently on revertlist on en.wikipedia's XLinkBot)
  3. Add user status choice (checkboxes for the different roles, or like the page-protection levels)
    • disallow IPs and new users to use a certain link (e.g. to stop spammers from creating socks, while leaving it free to most users).
    • warn IPs and new users when they use a certain link that the link often does not meet inclusion standards (e.g. twitter feeds are often discouraged as external links when other official sites of the subject exists; like the functionality of en:User:XLinkBot).
  4. block or whitelist links matching regexes on specific pages (disallow linking throughout except for on the subject page) - coding akin the title blacklist
  5. block links matching regexes when added by specific user/IP/IP-range (disallow specific users to use a domain) - coding akin the title blacklist
Downsides

We would lose a single full list of material that is blacklisted (the current blacklist is known to work as a deterrent against spamming). That list could however be independently created based on the current rules (e.g. by bot).


Modular approach: make the current AbuseFilter 'modular', where upon creation of a new filter, you can define a 'type' of filter. That module can be a module like the current existing AbuseFilter, or specialised modules like this spam-blacklist filter described above.


Discussion

Voting

Create an extension for fixing parent IDs

  • Problem: As of MediaWiki 1.31, when revisions are restored, they will keep their old parent IDs. But this also means that it is impossible for revisions whose parent IDs have changed from undeletions in previous MediaWiki versions to revert back to having their original parent IDs.

Also, other problems with rev_parent_id could occur too:

  • Undeleting revisions that were deleted prior to MediaWiki 1.5 could cause all of them to have rev_parent_id 0 (see the history of Template talk:Db-g1/Archive 1 on Wikipedia, for example).
  • Undeletions of revisions deleted prior to MediaWiki 1.5 and imports could cause the restored or imported revisions to all unexpectedly have the latest revision ID at the time of the undeletion or import as the parent ID (see the histories of Joshua Claybourn, Talk:Netherlands, and California on Wikipedia, for example).
  • Page deletions in MediaWiki 1.18 and earlier did not fill in the ar_parent_id column, so undeleting revisions that were deleted in MediaWiki 1.18 or earlier could cause unexpected results (see the histories of Eshay and Sembcorp on Wikipedia, for example).
  • Importing could cause the imported revisions to have a parent ID that does not correspond to the one on the original source wiki (see the history of MediaWiki:Gadget-formWizard-core.js on Wikipedia, for example).
  • Who would benefit: Users patrolling page histories for size differences
  • Proposed solution: Create an extension for fixing parent IDs and install it on Wikimedia wikis. The following are the (collapsed) descriptions from the Phabricator tasks:
Extended content

T223343:
When revisions are imported, we should attempt to preserve the parent revision from the source wiki. This means that if rev_id m has rev_parent_id n or 0 on the source wiki, then rev_id m' would have rev_parent_id n' or 0 on the target wiki, where the primes mean the corresponding imported revision IDs on the target wiki. If the parent ID on the source wiki is a deleted revision ID or has a different rev_page, then we would either have to fallback to using the preceding revision ID as rev_parent_id or insert dummy "ancestor" rows into the archive table.

T223342:
Before creating the extension, we should make the "populateParentId" script in MediaWiki also populate missing ar_parent_id fields, at least for those archive rows that have a non-null ar_page_id field, where it is assumed that the equivalent of "has the same rev_page" for the archive table is "has the same ar_namespace, ar_title, and ar_page_id combination". Dealing with the null ar_page_id case is a bit trickier, because we need to know when each revision was deleted, so it is best to leave ar_parent_id null for such deleted revisions for now.

We now keep the old parent ID when restoring revisions, but this previously wasn't the case. We should start fixing rev_parent_id for all old restored revisions.

First, the extension needs 2 globals named "$wg(ExtensionName)119date" and "$wg(ExtensionName)131date". These should respectively be the date the wiki started using MW 1.19 (when deleted revisions started to have parent IDs saved in the archive table) or later and the date the wiki started using MW 1.31 wmf.15 (when undeletions started to keep the old parent ID) or later. We also need 2 tables named "backlog_temp_page" and "backlog_temp_revision". The former will have columns named "btp_id", "btp_namespace", "btp_title", and "btp_timestamp". The latter will have columns named "btr_id", "btr_rev_id", "btr_btp_id", "btr_old_parent_id", "btr_new_parent_id", and "btr_table".

Next, we need to create a script that will dump some pages and revisions (including deleted ones) into the 2 tables. All pages that have a "restored page" log entry with a timestamp on or earlier than the "$wg(ExtensionName)131date" global will be dumped into the "backlog_temp_page" table, with "btp_timestamp" being the log entry's timestamp (the earliest one if there is more than one such entry). The same will also be done for pages with later "restored page" log entries if they also have at least one "deleted page" log entry with a timestamp on or earlier than the "$wg(ExtensionName)119date" global, as well as pages with import log entries. Again, if a page has more than one "restored page" or import log entry, or both, then it will only be added once to the table, and "btp_timestamp" will be the timestamp of the earliest such entry. Targets of merge and move log entries from titles already in the table will also be added to the table, with "btp_timestamp" being the timestamp of the earliest such entry, and this will be done recursively. Merge and move log entries with timestamps earlier than the "btp_timestamp" for the source page will be ignored. Once the "backlog_temp_page" table is completely filled, it is then time to fill in the "backlog_temp_revision" table. All live and deleted revisions for pages in the "backlog_temp_page" table will be dumped into the "backlog_temp_revision" table, with "btr_old_parent_id" and "btr_new_parent_id" both initially being the current value of rev_parent_id or ar_parent_id, and "btr_table" being either "revision" or "archive".

If there is a page that one thinks also needs repair, but is not automatically added to the "backlog_temp_page" table, then one can just visit a special page named "Special:FixParentIDsRequest" to request that the page be manually added to the table, and another administrator will then approve or decline the request. After approving the request, all of the page's live and deleted revisions will then be dumped into the "backlog_temp_revision" table, following the same rules as the above script. If one thinks that a declined request should have been approved, then one can just make another request for the same page, and the new request should then be approved by a different administrator from the one who declined the original request.

While the extension is ongoing, it needs some hooks. When a page listed in the "backlog_temp_page" table is deleted, the "btr_table" field must be changed from "revision" to "archive" for all rows corresponding to the revisions that had just been deleted. When such a page is undeleted, the "btr_table" field must be changed from "archive" to "revision" for all rows corresponding to the revisions that had just been restored. When such a page is moved, the new title must replace the old one in the "backlog_temp_page" table, and the old title will be re-added to the table if it still has some deleted revisions. In the latter case, the "btr_btp_id" field will be replaced with the ID of the newly inserted "backlog_temp_page" row for all rows in the "backlog_temp_revision" table corresponding to the deleted revisions for the old title. Finally, when Special:MergeHistory is used with a source page that is already in the "backlog_temp_page" table, the target page must be added to the table if it is not already there, and the "btr_btp_id" field must be updated for all rows corresponding to the revisions that had just been merged. When all revisions are merged, the source page will be removed from the "backlog_temp_page" table if it does not have any deleted revisions.

Finally, we need a special page named "Special:FixParentIDs". The special page will require a page from the "backlog_temp_page" table to be fixed. Then, all of the page's revisions from the "backlog_temp_revision" table will be listed on the special page, with the timestamp, author, edit summary, and "minor edit" status shown. For each revision, there will be 2 radio buttons below it. One of them will say to keep the current parent ID, and the other one will say to change the parent ID to whatever the user thinks it should be. There will also be 2 buttons named "Save settings" and "Fix page". The former will only update the "btr_new_parent_id" fields, while the latter will also immediately fix rev_parent_id or ar_parent_id for all of the page's live and deleted revisions and remove the page and its revisions from the "backlog_temp_page" and "backlog_temp_revision" tables.

After completing a request to fix parent IDs for revisions from a particular page, messages will be left on the user talk pages of the affected editors to let them know that the parent ID has successfully been fixed for one or more of their edits.

The message will look something like the following in English (as usual, the four tildes will automatically be replaced with a signature and a timestamp):

== Check out the following page: Affected page ==

Hi, {{ROOTPAGENAME}}. I would like to let you know that I have fixed parent IDs for one or more of your edits to the page [[Affected page]]. The affected revision ID(s) is/are the following: (List of affected revision IDs).

Please check the history of the page to confirm that the size diff numbers have successfully been fixed. ~~~~

{{ROOTPAGENAME}} is used here so that it remains displayed correctly if the user had been renamed or if the message had been archived. Also, if the user talk page is a redirect to another page, then the message will be posted at the target page instead, and the possessive pronoun "your" will be replaced with the possessive form of the original editor's username (which might, for example, be a bot username). For usernames that do not end with "s", "'s" will be added automatically; for those that do, one must decide whether or not "'s" should be added. For imported edits with usernames having an interwiki prefix, no message will be posted.

Other languages will of course need a translated version of the message.

With the example "User:Calliopejen1/Bronces de Benín" below, Millars would receive messages on both the English Wikipedia and the Spanish Wikipedia that say that the parent ID had been fixed for four of his edits on the respective wikis. Also, since User talk:Xqbot (enwiki) and Usuario discusión:Xqbot (eswiki) redirect to User talk:Xqt (enwiki) and Usuario discusión:Xqt (eswiki) respectively, Xqt would receive messages that say that the parent ID had been fixed for one of Xqbot's edits on the respective wikis. The size diff number would then change from a "heavy" red negative number (-12,550) relative to the old parent ID to a "light" green positive number (+24) relative to the new parent ID.

Summary:
First, all rows in the archive table that have an associated page ID (ar_page_id) but no parent ID (ar_parent_id) will have their parent IDs populated. After that, all page titles that were imported, deleted in February 2012 or earlier and also have at least one page undeletion log entry, or undeleted in January 2018 or earlier will automatically be added to a new table. Targets of merge and move log entries with sources in the table will also be (recursively) added to the table. One can still request for a page that was not automatically added to the table to be added manually if needed. Such requests are needed, for example, when one has a page with suppressed edits that were migrated from the Oversight extension.

If one finds a page from the table that has at least one revision that needs to have its parent ID fixed, then one should go to Special:FixParentIDs/Page title ("Page title" should be replaced with the page's actual title) and start implementing the required parent ID changes. After the changes have been saved, the authors of the affected revisions will then be notified of the changes. A log entry notifying of the change will also be created.

Discussion

  • Sample usage (from my comment on T223342):
The following example shows that for imported revisions, rev_parent_id might require fixing on both the source and the target wikis.
The subpage User:Calliopejen1/Bronces de Benín on the English Wikipedia was imported from the page Bronces de Benín on the Spanish Wikipedia. There is also a move comment that says "fusión de historiales", which, of course, is the Spanish translation of "merging histories". This together with the negative size diff for the edit at 23:23, 21 July 2010 by Xqbot suggests that we should fix rev_parent_id for some of the the edits between the 2 moves by Millars. The strategy is to separate the revisions containing <nowiki>'ed categories from the ones that contain live categories until the Xqbot edit.
The following fixes should therefore be done:
  • Revision ID 526466627 on enwiki and revision ID 38879757 on eswiki should both be fixed to have rev_parent_id 0 to make them show as page creations on Millars' contributions on the respective wikis.
  • Revision ID 526466630 on enwiki and revision ID 38881146 on eswiki should be fixed to have rev_parent_id 526466626 and 38879182 respectively.
  • Revision ID 526466631 on enwiki and revision ID 38884289 on eswiki should be fixed to have rev_parent_id 526466629 and 38881051 respectively.
  • Revision ID 526466643 on enwiki and revision ID 38956953 on eswiki should be fixed to have rev_parent_id 526466630 and 38881146 respectively.
  • Revision ID 526466644 on enwiki and revision ID 38975104 on eswiki should be fixed to have rev_parent_id 526466641 and 38922039 respectively.
  • Finally, the rest of the revisions' parent IDs should be left unchanged on both wikis.

— The preceding unsigned comment was added by GeoffreyT2000 (talk)

As just a side note, for anyone not technical, this is going to be incredibly difficult to understand and probably should be rewritten for that audience if it is going to get any votes. --Rschen7754 19:23, 16 November 2020 (UTC)Reply[reply]
I honestly think this is going to get basically 0 votes. It's an exceedingly technical change that impacts <1% of all editors. --Izno (talk) 21:48, 16 November 2020 (UTC)Reply[reply]
This is very difficult to understand even for someone who does understand technical stuff. As far as I can tell, there's two things being proposed here. One of them is "fix T38976", which is a reasonable proposal, and the other is "support pages containing parallel histories", which doesn't seem to solve a real problem (just don't do that, and you can fix any pre-existing pages with parallel histories using selective undeletion without any new code being written). Also note that w:User:Calliopejen1/Bronces de Benín no longer exists. * Pppery * it has begun 00:14, 17 November 2020 (UTC)Reply[reply]
@Pppery parallel histories would be incredibly useful for a whole hist of things. See T113004 for some. But it's a massive undertaking that would probably be outside the wishlist's scope. Tgr (talk) 03:37, 13 December 2020 (UTC)Reply[reply]

Voting

Watchlist of users

  • Problem: Vandals are hard to follow, as are new users.
  • Who would benefit: Better control of new users and vandals.
  • Proposed solution: At the very least, for administrators, it would be necessary to have a "user watchlist".
  • More comments: When we are reviewing articles, many times we see a user who has done something wrong, or has entered wrong data. We write a message to him in his discussion, and we watch the edits he makes for a while, to see if he has improved in his attitude. However, when you have written to many users, it is almost impossible to follow them all, so a watchlist of each user's edits would be interesting, at least for administrators.
We could have a star on the users, as we do with the articles, and have a "user watchlist" where a list of issues will appear separated by user, to see what each one has done. When we consider that a user is doing their job well, we can remove the star, just like we do with the articles. Thanks.

Discussion

  • This was previously declined (5 whole years ago) as it was seen to be a major tool in 'harassment'. Basically, it would be trivial to write a script that does just this (User:MER-C just did that): collect the last ### edits of a set of users, sort them out, and display them in a watchlist-like-manner (that could be a user-script in my on-wiki .js, it could be on my own computer and no-one would see that I would 'script' except maybe CheckUsers). For N00bs: I can do the same things with a folder of bookmarks of user-contributions for these users and just every morning check them (as I do with my watchlist). Yes, having this might be a nice tool to harass users ('what have my favourite victims been up to') but that can be done anyway in undetectable ways.
Having this tool has some big benefits in 'following problematic users' (suspect spammers, socks, COI editors, etc.). To mitigate harassment one could make the user-watchlist-lists visible to users with advanced rights (e.g. that admins can see who others are following, though probably better only CheckUsers/Stewards can see it).
I think it is time that the community re-assesses this, and possibly we have a commmunity discussion on solving possible concerns. --Dirk Beetstra T C (en: U, T) 06:29, 25 November 2020 (UTC)Reply[reply]
@Samwilson: and @Beetstra: Thanks a lot for your feedback. Have a nice day ;) --Vanbasten 23 (talk) 09:20, 25 November 2020 (UTC)Reply[reply]
@Vanbasten 23 and Beetstra: I've moved this back to its category, so it can be voted on. (I'm using my staff account now, but am the same person as User:Samwilson above.) —SWilson (WMF) (talk) 22:25, 1 December 2020 (UTC)Reply[reply]
The right to use this feature could be limited to admins (and editors), or it could be withdrawn from users who use it abusively. -- Aspiriniks (talk) 21:24, 8 December 2020 (UTC)Reply[reply]
  • This ought only be implemented if for administrators only, and only usable on accounts with under a certain number of edits, as Bilorv suggests. Though I do often think of such a tool for keeping an eye on vandals, it could so easily be turned into a harassment tool. CaptainEek Edits Ho Cap'n! 03:32, 10 December 2020 (UTC)Reply[reply]
    • @CaptainEek: I strongly doubt whether this is becoming a harassment tool if you give visibility to the watchlist (e.g., admins can plainly see who you are watching, or have access to a Special:WhoWatchesWho which is bidirectional, or even a Special:WhoWatchesMe .. meh, even add a 'approve' for named accounts if someone wants to follow them - then in case of (group-)mentoring they will likely approve, but for regulars that will not happen, or they can later 'unapprove' if they at first did not have a problem with it). I have currently a watchlist of Wikipedia pages of my interest, which contains some filters and user contribs. This tool is literally nothing else than that. Whether I have 3 users that I 'follow around' through three clicks on bookmarks, or that I have one tool where I have all of that in one page is all the same. I really see no difference in harassing an editor through looking at their Special:Contribs every hour or by using this tool every hour. Can someone please explain me how this is (becoming) a harassment tool (pinging oppose !votes, I'd like to hear your reasoning: @MarioSuperstar77, Keepcalmandchill, Putnik, and NMaia:)? --Dirk Beetstra T C (en: U, T) 05:47, 10 December 2020 (UTC)Reply[reply]
      • I certainly think some checks and balances would be necessary, I like your suggestion of a needing approval, or making the watch watchlists be public/seen to admins. My fears would be that both our vandals and our veterans could use this tool for ill. Vandals could throw together a list of the admins they hate, and then use it to follow them and harass them, or keep an eye on who is active so as to evade them. Much harder to do with 50 contribs pages, but easy if its in one place. For veteran users, I can imagine it worsening feuds and disagreements and encouraging edit stalking. When two users don't quite like each other, and are on the other's watchlist, they would be more likely to follow the other around, and I can see a lot more IBans being handed out. I'm not fully against this, I too would like to be able to put vandals and hooligans on a sort of watchlist, but I do think a lot of preparation/rules are needed to ensure it doesn't become a tool of evil. CaptainEek Edits Ho Cap'n! 18:57, 10 December 2020 (UTC)Reply[reply]
  • To further alleviate the concern of harassment: make it a right, ‘canwatchusers’, that is not standard given out to anyone. People who can show a use for it on a wiki can then be given this ability (mentors, spam-fighters), or wikis can decide never to give it out. The right can be temporary for mentors, who can only use it for the time of an event. —Dirk Beetstra T C (en: U, T) 04:29, 20 December 2020 (UTC)Reply[reply]
  • Needs to be re-thought - for mentors/education/etc, allow users to specify who can "watch" them and for how long. For vandalism, make it a user-right, perhaps one that is NOT bundled into the "admin/sysop" bit. I have no problem with Stewards, Oversighters, ARBCOM, and others at that level being able to watchlist editors and make decisions about who else can watchlist people for vandalism control. On projects with many sysops/admins like en-wiki, I would be reluctant to include this in the "admin" bucket of rights. On projects with fewer admins, this might make more sense. There should also be a "global-watcher" user-right that is included in steward and some other highly trusted global- user-groups. I can also see value in having an "bot" account have this user-right to prepare off-wiki reports for use by highly-trusted abuse-fighting editors. Davidwr/talk 15:29, 21 December 2020 (UTC)Reply[reply]

Voting

UNDO (rollback) by UserName

  • Problem: Sometimes User make destruct change in one day in many articles (like Bot) - and Admins (Patrollers) must undo User actions (5-10 articles typically, but meet - 30 per day) article by article - it's expansive loose of time
  • Who would benefit: Admins and patrollers
  • Proposed solution: In list of "User contributions" make special UNDO-button for Admins (Patrollers). Maybe have choose Undo by DAY ACTIONS of user, or BY SIZE of change (for example: from 300 Bytes to 325 Bytes (diffs max 1 Kb))
  • More comments: It's need consensus by 2 Admins or 3 Patrollers (for example: it's mean: 2 admins must press special UNDO-button for User actions)
  • Phabricator tickets:
  • Proposer: Всевидяче Око (talk) 22:15, 17 November 2020 (UTC)Reply[reply]

Hi! I read Manual:Combating vandalism Всевидяче Око (talk) 10:55, 18 November 2020 (UTC) (added later)Reply[reply]

Discussion

Hi, Nihiltres! Extension:Nuke, near, because it's delete all articles in summary diapason - we need Undo same changes (or rollback same changes). But really this code can be useful for begin base. Thx)
With respect -Всевидяче Око (talk) 10:10, 18 November 2020 (UTC)Reply[reply]
Hi, Camouflaged Mirage! In Manual:rollbackEdits.php or mass rollback.js I don't see "summary diapason" (size of change, date of cange,- only User by IP). Both script's delete all changes(. We need little more flexible script) with partial deletion
With respect -Всевидяче Око (talk) 10:55, 18 November 2020 (UTC)Reply[reply]
Hello, if it's partial deletion (or reversion) of an user / IP contributions, I will suggest manually as if we need to quantify a specific range, it's more likely we have to look into the edits, so why not do it by hand. Best, Camouflaged Mirage (talk) 16:14, 18 November 2020 (UTC)Reply[reply]
HI! "..destruct change...30 per day)... must undo User actions article by article - it's expansive loose of time". If Your do this time by time - Your konow whot about it. ) With respect -Всевидяче Око (talk) 01:30, 21 November 2020 (UTC)Reply[reply]
If You are read upper: "It's need consensus by 2 Admins or 3 Patrollers..." - it's how one of variant, or can propose Your too. With respect -Всевидяче Око (talk) 14:28, 13 December 2020 (UTC)Reply[reply]
Yes, it is partially possible - but not at all. For example, when 1 administrator or 1 patrol has seen this revision and do action, other administrators or patrols may see it as a specification message (or as some may suggest yours). And we need remember about ethically action. With respect -Всевидяче Око (talk) 11:11, 19 December 2020 (UTC)Reply[reply]

Disculpen que pregunte esto, pero quisiera ayudarles a controlar las cuentas, etc. Asi como lo hacen sus bots. me podrian decir si es posible. Gracias

Voting

Automatically detect edit-warring

  • Problem: Bringing edit-warring to the admins' attention currently requires editors that have the time to go through a fairly bureaucratic process.
  • Who would benefit: Editors who wish edit-warring to be more strictly enforced against, and administrators/other editors who wish to enforce it more strictly or just arbitrate conflicts.
  • Proposed solution: Add a function that automatically compares every new revision against all those of the last 24 hours, and then flags to the administrators or other editors if it detects the same text being added or removed more than three times (as per the three revert rule).
  • More comments : There could still be a separate process for making formal complaints, and this could simply be a way to get attention that there is a conflict brewing, preventing things from getting out of hand earlier. Further comment: it seems that the current process for edit-warring complaints is extremely inefficient, with complaints being archived without any attention having been given to them. Therefore, perhaps this function should automatically give short blocks for first time breakers (24hrs) and longer ones for repeat offenders (72hrs and more). I think having complaints not addressed at all is extremely disappointing, and perhaps a reason for editors to stop contributing.
  • Phabricator tickets:
  • Proposer: Keepcalmandchill (talk) 04:19, 17 November 2020 (UTC)Reply[reply]

Discussion

Voting

Ability for sorting Special:UnreviewedPages by time

  • Problem: It is a long-time request from patrollers/reviewers, that items on Special:UnreviewedPages should be able to be sorted by creation date, so the very old items can be handled with priority, organize campaign for them etc. The list is sorted alphabetically now, which is not very useful.
  • Who would benefit: reviewers/patrollers, admins
  • Proposed solution: Offer an option to sort the list by time
  • More comments:
  • Phabricator tickets: T45857
  • Proposer: Samat (talk) 14:10, 29 November 2020 (UTC)Reply[reply]

Discussion

Voting

Discourage External Spam that Exploits Wikipedia

  • Problem: Many spamming scammers use Wikipedia references to add credibility to their scams (usually 419s).
  • Who would benefit: Wikipedia would have less spurious traffic reflecting the interests of scammers and potential victims would benefit by being warned against scams. Wikipedia's reputation would be enhanced by taking a clear position against criminal use of Wikipedia.
  • Proposed solution: A flag option to create a banner saying that This article is currently being referenced by scam email. The link to Wikipedia should not be taken as evidence of the truth or accuracy of email which is referencing this article. The basic implementation would allow someone to report the spam email to Wikipedia and select the kind of crime it represents. Most of the examples I have seen appear to be 419s, so in that case the warning message should include a link to the article about 419s, but others are phishing scams or various other crimes. The warning should persist for a while to allow for delays in people reading their email, but the basic idea is that spammers would stop abusing Wikipedia because their scams would be quickly negated at the Wikipedia end. The person reporting the spam email could trigger the warning, or it could go through a review process to confirm its spamminess.
  • More comments: This kind of abuse has been going on for many years and "Live and let spam" is obviously great for the scammers. If they weren't making money by exploiting Wikipedia's reputation then they would stop doing it.
  • Phabricator tickets:
  • Proposer: Shanen (talk) 04:06, 25 November 2020 (UTC)Reply[reply]

Discussion

  • @Shanen: This sounds like it could be a template that's placed on such articles (such as those used when articles are the subject of active news events etc.), and not something that requires anything technical or software development. Am I understanding it correctly? —Sam Wilson 06:07, 25 November 2020 (UTC)Reply[reply]
@Samwilson: [Is that the correct way to flag it to your attention?] Sorry, but even after many years of making minor contributions to Wikipedia, I do not understand Wikipedia well enough to be sure that I understand your terminology accurately enough to answer correctly. I feel the answer is "Sort of yes", but the "template" would need a couple of slots for filling in the blanks. As I would imagine a possible implementation, the person reporting the spam would submit the email, preferably with the headers, and the Wikipedia-side server would parse it for Wikipedia links or references. Then it would probably ask the person who is submitting the report for help regarding the category of crime, unless the report was passed to someone else, perhaps a member of the Wikipedia abuse team. After that, the warning notification would be added to the front of the article in question (for the appropriate period of time, perhaps two weeks in the case of an email-based scam). Not sure if this is the best way to reply to you. Maybe I should try to include a copy in your personal talk page? Shanen (talk) 16:31, 26 November 2020 (UTC)Reply[reply]
@Shanen: Yep, the {{re}} template is a great way to get people's attention; no need to separately mention on their talk page. :-) Thanks for clarifying. This sounds like there are some technical development tasks here, so I think it's fine to proceed to voting (the week after next). —Sam Wilson 02:43, 27 November 2020 (UTC)Reply[reply]
  • I feel that this is likely to cause individuals to distrust it to a fairly high degree, even though it's by no means the article's fault. It also needs someone to review the emails, which would drench OTRS (speaking as an agent, I at least wouldn't want this added), a standard process for timed removal, and so on. I would be against its addition. Nosebagbear (talk) 15:46, 2 December 2020 (UTC)Reply[reply]
  • This is an encyclopedia. It might be similar to spoiler warnings, which have since been discontinued. Firestar464 (talk) 05:01, 9 December 2020 (UTC)Reply[reply]

Voting

Enable the ability to rollback to specific version


  • 問題: 现阶段回退功能无法将指定页面回退到某一个已知的且未被删除或监管的版本
  • 有益於誰:拥有回退权限的用户
  • 提案的解決方案:
  • 更多評論:它可能是一个有用的功能。另外,我不确定这个提议是否在这次调查的范围内。如果不在的话,很抱歉打扰。我对Community_Tech#Scope的理解不是非常好。
  • Phabricator請求:
  • 提案者: --Yining Chen (Talk) 10:34, 17 November 2020 (UTC)Reply[reply]

Discussion

Voting

Mark all consecutive edits by same user as patrolled

  • Problem: Often users (especially unregistered and new ones) make lot of consecutive edits that can be rollbacked and checked in the history diff at once with a single click, but those will result unverified unless every single edit is marked as such one by one, which is tedious. As a result, no patroller uses this feature on my wiki.
  • Who would benefit: patrollers, mostly.
  • Proposed solution: "mark N edits as verified" link or something like that, in recent changes, history and such, just how it's available for rollbacks.
  • More comments:
  • Phabricator tickets:
  • Proposer: Wedhro (talk) 11:02, 22 November 2020 (UTC)Reply[reply]

Discussion

Voting