Ir al contenido

Community Wishlist Survey 2022/Admins and patrollers

De Meta
Administradores y patrulleros
11 propuestas, 326 colaboradores de editores, 593 votos a favor
The survey has closed. Thanks for your participation :)



Allow rev parent id to be fixed

(Traducir)

Discusión

Votación

Permitir el uso de plantillas en el campo de motivos de los los bloqueos globales.

(Traducir)
  • Problema: En la actualidad no es posible usar plantillas en el campo de motivos cuando se efectúa un bloqueo global. Ello es así porque no existen plantillas globales y el sistema mostraría al usuario bloqueado, bien un enlace roto, o bien el contenido de una plantilla local que nada tuviese que ver con el bloqueo. Esto significa que el usuario bloqueado (y que además puede no ser el destinatario original del bloqueo) tenga que venir a Meta para conocer los detalles exactos del bloqueo que les impide editar. Por ejemplo, sería util que pudiesen mostrarse plantillas como en:Template:Blocked p2p proxy directamente en el mensaje de bloqueo.
  • Solución propuesta: Implementar un sistema para mostrar motivos de bloqueo predefinidos a través de plantillas en Meta para los usuarios bloqueados globalmente. De modo alternativo, en vez de autorizar el uso arbitrario de plantillas, crear un sistema para que los stewards puedan configurar mensajes detallados de bloqueo a través de páginas JSON en Meta (propuesto por Legoktm en Phabricator).
  • A quiénes beneficiaría: Usuarios afectados por bloqueos globales (las instrucciones que recibirían serían mucho más claras), stewards
  • Más comentarios: La extensión que permite hacer bloqueos globales contiene porciones incompletas de código para mostrar mensajes de bloqueo desde una wiki central (como Meta), véase phab:T243863 para más detalles.
  • Informes de Phabricator: phab:T243863
  • Proponente: Majavah (talk!) 13:44, 16 January 2022 (UTC)[responder]

Discusión

  • Kind of edges on global templates as a request, which skimming the Phab kind of looks like some similar concerns there, or at least which would exist if global templates were somewhere in implementation.

    That aside, templated block reasons aren't well supported in some ways even today; en:MediaWiki:Ipbreason-dropdown until recently had lint errors (and then someone moved it to plain text content model, which has its obvious downside of not tracking a link to the template in the page). --Izno (talk) 00:21, 17 January 2022 (UTC)[responder]

    I think the global block reasons can be logged in Meta, and a Meta page contains all the reasons, as stewards block user in a Meta-based interface. Thingofme (talk) 00:57, 18 January 2022 (UTC)[responder]

Votación

Permitir que los bloqueos globales opcionalmente no impidan la creación de cuentas

(Traducir)
  • Problema: En la actualidad, todos los bloqueos globales impiden la creación de cuentas. Los stewards solo pueden escoger entre hacer que el bloqueo afecte o no a las IPs usadas por usuarios registrados o no registrados (los denominados "bloqueos blandos" o "bloqueos duros").
  • Solución propuesta: Tal y como sucede con Especial:Bloquear, por favor, añádase una caja de palomilla (checkbox) en Special:GlobalBlock para permitir a los stewards elegir si, para un bloqueo global en particular, la creación de cuentas desde esa dirección IP o intervalo (rango) de IPs debe ser o no impedido, dependiendo de las circunstancias.
  • A quiénes beneficiaría: Los stewards, como usuarios de la extensión; pero todos los usuarios porque se podrá autorizar la creación de cuentas en aquellos casos en los que no es necesario impedirlo (por ejemplo, cuando el abuso procede exclusivamente de usuarios no registrados).
  • Más comentarios:
  • Informes de Phabricator: task T17273.
  • Proponente: —MarcoAurelio (talk) 19:37, 15 January 2022 (UTC)[responder]

Discusión

Votación

Allow global whitelisting of IPs subject to global rangeblocks

(Traducir)
  • Problema: Several requests for unblock cannot be handled in due time because of providers/tech depths of different organization mixing up networks which could legitimately edit the wikis with farms with open proxies, spam sources, etc. A quite common case are, also, private proxies on VPS or reverse proxies from different organizations hosted in third-party farms.
  • Solución propuesta: create a Special:GlobalBlockWhitelist page where a global block can be revoked for a certain IP or subnet falling in a blocked range
  • A quiénes beneficiaría: dozens of users caught by global blocks
  • Más comentarios:
  • Informes de Phabricator: phab:T42439
  • Proponente: Vituzzu (talk) 10:44, 20 January 2022 (UTC)[responder]

Discusión

Votación

Mostrar historial de bloqueo reciente para IPs y rangos

(Traducir)
  • Problema: Al revisar las contribuciones de una IP, los bibliotecarios deben buscar en el historial de bloqueos para ver si ha habido bloqueos recientes. Cuando se trata de rangos (especialmente /64), este problema es peor. Para ver los bloqueos de rango, los administradores deben agregar /[16,32,48,64] y luego ir a "bloquear" (no bloquear el registro porque eso solo funciona en la IP base, no en una dentro del rango) para ver los bloqueos de rango recientes. Incluso para ver advertencias pasadas a los editores en un rango, los administradores deben ir al rango, desplazarse y encontrar direcciones IP individuales cuyas páginas de discusión no tengan enlaces rojos, abrir un montón de ellas y ver si ha habido una escalada de avisos recientemente, y "luego" volver a la primera IP y advertir en consecuencia.
  • Solución propuesta: Agregar información de bloqueo reciente en las páginas de contribuciones para que los administradores la vean, de forma similar al cambio reciente en la ventana emergente de bloqueo de Twinkle, incluidos los bloques de rango. Una característica similar en las contribuciones o la página de discusión
  • A quiénes beneficiaría: Administradores
  • Más comentarios: Esto sería particularmente útil para lidiar con casos de LTA y vándalos que saltan direcciones IP para evitar acumular advertencias en una sola.
  • Informes de Phabricator:
  • Proponente: EvergreenFir (talk) 05:34, 18 January 2022 (UTC)[responder]

Discusión

Votación

Mass-delete to offer drop-down of standard reasons, or templated reasons.

(Traducir)
  • Problema: Admins have the ability to mass-delete contributions of a user seen as problematic. This usually affects a large number of pages; currently it reads 'mass-deleting contribs of user Foo'. Having a templated reason that gets replaced, or a drop-down of common reasons would help.
  • Solución propuesta: Either add a drop-down (with most common reasons, similar to QD), or provide a way that templated reasons get replaced.
  • A quiénes beneficiaría: Admins: mass-deleting pages, users: knowing more precisely why the page was deleted
  • Más comentarios:
  • Informes de Phabricator: phab:T25020
  • Proponente: Eptalon (talk) 23:37, 18 January 2022 (UTC)[responder]

Discusión

  • @Eptalon:
    Screenshot of the current last step of Nuke.
    can you be a bit more specific, what are the step-by-step directions you are currently using for this process? The "mass-delete" you mention above sounds like you are referring to Special:Nuke, provided by the Nuke extension. This extension already has the option to enter free-form text, solving the problem of admins poorly communicating. (See image below) Is there where you would also like to put a drop down box? — xaosflux Talk 00:11, 19 January 2022 (UTC)[responder]
When I delete a page, I get a drop-down with preselected ("quick-deletion") criteria. I was alluding to a simliar dropdown (in addition to freetext box you show)-Eptalon (talk) 23:29, 20 January 2022 (UTC)[responder]

Votación

Expose ORES scores in AbuseFilter

(Traducir)
  • Problema: AbuseFilters are a great way of preventing problematic edits before they happen. However, guessing "problematic" is currently done using user segmentation, common phrases used by vandals etc. We have a much better tool to determine if an edit is destructive: ORES. If we were able to prevent all edits above a certain threshold, the workload on patrollers would be significantly reduced and, possibly, would prevent some communities from requesting and all-out IP-editing ban.
  • Solución propuesta: Expose the raw ORES "damaging" score as a variable in AbuseFilter
  • A quiénes beneficiaría: Patrollers and admins would have less work
  • Más comentarios: Exposing ORES levels from the Special:RecentChanges interface (very likely, likely, less likely, unlikely) would also be OK.
  • Informes de Phabricator: phab:T123178
  • Proponente: Strainu (talk) 16:13, 11 January 2022 (UTC)[responder]

Discusión

  • I'm not an ORES architecture expert, but I think this would be a major timing issue. AF has to be real-time to work, having to wait for ORES processing would likely be a huge bottleneck on every edit/action made - since between clicking publish and your save committing the data would need to go in to and back our of ORES, then in to AF before AF can do anything with it. — xaosflux Talk 19:21, 11 January 2022 (UTC)[responder]
    Since all edits pass through ORES, this should not increase global processing time. If you’re assumption is right, this feature would require to queue edits (so they could take several seconds to be live), but it is not blocking in my opinion.

    Related feature request: Suggesting AbuseFilter by machine learning. Pols12 (talk) 19:45, 11 January 2022 (UTC)[responder]

    @Pols12: AF is an interrupt, it will prevent saving an edit or present a warning to the user - it can't wait for ORES to process and also still do this. We're not going to leave our user sitting at a "processing" screen after they click publish - and once they left that screen it is too late to present them a warning. Now perhaps AF could add scores that ORES could use for things like deferred edits, but the reverse doesn't seem feasible. — xaosflux Talk 22:49, 11 January 2022 (UTC)[responder]
    We have to increase the processing speed on the ORES, but machine learning is still possible. Thingofme (talk) 00:39, 12 January 2022 (UTC)[responder]
    The bigger problem is that right now ORES is working on revisions, not diffs. But since ores is good enough for en.wp RC stream, I expect latency issues only for the biggest changes. But if I'm wrong, maybe other solutions, such as auto-revert, can be considered. Strainu (talk) 05:11, 12 January 2022 (UTC)[responder]
    @Strainu: Am I missing something? Doesn't abusefilter processing occur prior to a revision being created, and ORES happens after a revision is created? — xaosflux Talk 14:09, 12 January 2022 (UTC)[responder]
    You're not missing anything, that's what I also meant by "ORES is working on revisions, not diffs". I suspect making an ORES API that can receive a diff will be the main software change of this project.
    However, I don't expect this to bring along any latency issues. If ORES can work in near-real-time at en.wp scale, likely it can also be scaled to handle (in the worse case scenario) double the requests. Note that everything will happen locally (i.e. the same datacenter). A few hundred milliseconds of additional delay seems acceptable to me. Strainu (talk) 15:54, 12 January 2022 (UTC)[responder]
    Well, I have heard from the Performance team in the past that AbuseFilter is one the biggest slow-downs and causes of concern. I strongly suspect even a few hundred milliseconds is asking too much. As Strainu says, ORES would need to be first be able to accept raw content rather than just a revision ID. That alone I think makes this proposal out of scope for Community Tech, but it could deserve a spot in the Larger suggestions category (intended for things we can't do or promise, but still should have visibility to the broader movement). MusikAnimal (WMF) (talk) 23:25, 12 January 2022 (UTC)[responder]
    @CAlbon (WMF) I'm not sure if you're the right person to ping about ORES, but if not maybe you know who we could talk to? I'm trying to find out whether this proposal is feasible. The questions are:
    • Is it possible to give ORES some wikitext and it gives us a score (i.e. before the edit has been saved)?
    • If it is not possible, how hard would it allow ORES to accept arbitrary wikitext rather than a revision ID?
    • In either case, can ORES be potentially a bit slow? Several hundred milliseconds, or longer?
    Thanks for any information you can provide! MusikAnimal (WMF) (talk) 17:15, 13 January 2022 (UTC)[responder]
    The primary problem is speed, and I strongly believe the lack of speed is from I/O. When a request for a prediction for a revision ID is received, ORES hits the mediawiki API to get the wikitext, parses it, converts it into a feature vector, then serves it to the model to get a prediction. That is slow, obviously. Right now that slowness is hidden by pre-caching scores.
    That said, with some changes to we could deploy a version of the model that accepts wikitext and scores it. I'll create a ticket for that and we can do a spike on it. CAlbon (WMF) (talk) 17:05, 18 January 2022 (UTC)[responder]
    Ticket created! https://phabricator.wikimedia.org/T299436 CAlbon (WMF) (talk) 18:25, 18 January 2022 (UTC)[responder]
  • This or similar would be excellent. --Izno (talk) 00:18, 17 January 2022 (UTC)[responder]

Votación

Añadir la posibilidad de eliminar tus propios archivos sin necesidad de un administrador

(Traducir)
  • Problema: Si cargo archivos defectuosos, no puedo eliminarlos ni trasladarlos sin la ayuda de un administrador.
  • Solución propuesta: Los usuarios deberían poder eliminar fácilmente cualquiera de sus propios archivos, sin tener que preguntarle a alguien. Es posible que deseen esto por múltiples razones. Por ejemplo, tal vez mejoraron en términos de habilidades fotográficas y tomaron nuevas fotos de algo, las cuales son mejores en comparación con las anteriores que subieron.
  • A quiénes beneficiaría: Cualquier usuario que haya subido archivos que requiera eliminar.
  • Más comentarios:
  • Informes de Phabricator: task T113508, task T20572
  • Proponente: Neoclassicism Enthusiast (talk) 15:36, 11 January 2022 (UTC)[responder]

Discusión

On English Wikipedia, at least, this is already covered by speedy deletion criterion G7, which allows editors to request deletion for their own work, but includes a safety: if deleting said work would be disruptive, then the deletion may be declined. This proposal merely takes the safety off of that process. As such, I can't support it. {{Nihiltres |talk |edits}} 15:55, 11 January 2022 (UTC)[responder]

the main problem is that your file may be already used on a lot of pages, and once you delete yours we get a problem... even though I want to support it... Omer abcd (talk) 15:59, 11 January 2022 (UTC)[responder]
We can perhaps allow the user to delete old versions of the file. If they have a better version, they can overwrite the file and delete their older version. This will also prevent mind-boggling events request such as this deletion request on Commons. Strainu (talk) 16:06, 11 January 2022 (UTC)[responder]
What's then to stop people with, say, reuploading File:Example.jpg as a "new version" of their file and then deleting old versions? If anything, that sounds like more of a headache. Worse, it would be trivially easy to upload a "new version" that's outright vandalistic and then complicate reversion of the vandalism by deleting old versions of the file. In the (rare!) instances where deleting old versions is desirable, users can ask any admin to delete the old versions under existing deletion policy (on English Wikipedia, at least). {{Nihiltres |talk |edits}} 16:34, 11 January 2022 (UTC)[responder]
That's a kind of vandalism that is also possible now from the end user's POV. The only difference is that it takes 2 clicks to fix instead of 1.Strainu (talk) 18:14, 12 January 2022 (UTC)[responder]
  • This could possibly be something useful in mediawiki, but I can't see it being useful in WMF wiki's that this project is mostly focused on. In most situations, once you upload a file you also attach a non-revocable open license - just like you do when you publish text. That being said, see also phab:T113508 / phab:T20572 that is related to this. — xaosflux Talk 19:25, 11 January 2022 (UTC)[responder]
    At least an extension was written in the past for this purpose: mw:Extension:DeleteOwn; however yours and ToBeFree's concerns below indeed make the proposal potentially unworkable for Wikimedia. —MarcoAurelio (talk) 19:57, 11 January 2022 (UTC)[responder]
  • Creative Commons licenses are irrevocable. Once you've published content under such a free license, you have [usually] given away your right to delete the content. This applies to Wikipedia article content and Wikimedia Commons images. Yes, the people at the English Wikipedia and Wikipedia Commons are usually kind enough to perform reasonable deletion requests by the only author of a page, but they may also decline such requests for various reasons, including "the content is good, we want to keep it". There should be no technical tool for an uploader to delete their own content in a disruptive way. ToBeFree (talk) 19:52, 11 January 2022 (UTC)[responder]
  • This would allow some kind of abuse, so we would limit it to: pages with less than 5000 links/tranclusions, 500 revisions, your own userspace and user talks, and user with the delete-self permission must have 90 days and 1500 edits. Also, if a page deleted by you, you can restore it (only in userspace) Thingofme (talk) 00:41, 12 January 2022 (UTC)[responder]
  • Bad idea. External sites may be reusing content originally uploaded to Wikipedia/Commons and provide a backlink (caveat: attribution is explicitly required by some free licenses) to the original URL. Deleting files breaks this attribution chain, which is why Commons admins will decline author-requested CSD if the file has existed for more than a few weeks. -FASTILY 02:43, 12 January 2022 (UTC)[responder]
  • What if we made it within 30 minutes of upload? That way obvious errors and or mistakes can be taken down by the uploader. EoRdE6 (talk) 21:45, 12 January 2022 (UTC)[responder]
    Yes, this is what I was thinking as well MrMeAndMrMeLet's talk 18:09, 28 January 2022 (UTC)[responder]
    +1 for if this was very time limited to correct mistakes without admins/procedural knowledge. KylieTastic (talk) 18:47, 28 January 2022 (UTC)[responder]
  • This could lead to problems in case of a compromised account. --Bischnu (talk) 12:00, 17 January 2022 (UTC)[responder]
  • As on en:wp we delete on Commons such files speedily per request. So this proposal would be a good idea if there were additional restrictions: 1) The file must not be in use on any wm project, 2) it must not be superseded by a new upload of another image, 3) the upload must not be older than x days. That would save sysops some time. However, I don't think that creating such a special user right is technically feasible. --Achim55 (talk) 18:11, 17 January 2022 (UTC)[responder]
  • This is a good idea, as per brion's two bug reports linked in the request.
    1. Renaming / deletion should definitely be possible in the day after an upload; just as basic common sense. It's silly to have an arbitrary irreversible action that you could just have done differently on creation.
    2. Renaming / deletion for a few weeks after creation also makes sense, if the file is not in use.
    3. The arguments above are well-intentioned, but besides the point: a. Deletion doesn't change the license under which the deleted versions can be reused. It just changes whether those files/versions are visible to non-admins, or transcludable on other pages. b. Deletion is reversible, so there's a limit to how disruptive this can be. Conservative parameters (no older than a few weeks, not in use anywhere) + triviality of reversal would make the convenience available to all w/ little risk. –SJ talk  22:49, 23 January 2022 (UTC)[responder]
  • There are two reasons not to do this. Firstly, deleting images that were once on a page damages the history of the page, as does deleting old versions of an image in the file history. This especially should not be done with images that were once in article space, but even in the user's own space, this may not be advisable. If the user has been doing something unconstructive with images, it is not beneficial to allow that to be hidden from the community as a whole. If there are constructive reasons for deletion that can still go through an admin. The second reason is that editors who have lost disputes or had an article deleted sometimes try to "withdraw" all their work from Wikipedia by deleting it in a tantrum. It is not helpful if they have a deletion tool to help them in that. SpinningSpark 12:25, 2 February 2022 (UTC)[responder]

Votación

Reminders or edit notifications after block expiration

(Traducir)
  • Problema: Vandals frequently continues their behavior after blocks expire. ClueBot will start at level-1 warnings for IP editors after a block expires. So, after blocking an IP, admins must keep a tab open to follow up on that editor's edits once a block expires to watch for continued vandalism. The longer the block is, the harder this becomes. Watching talk pages doesn't help, though that's a checkbox in Twinkle's block popup window.
  • Solución propuesta: Provide admins with option to be alerted if an editor resumes editing within a select time period after a block expires.
  • A quiénes beneficiaría: Admins
  • Más comentarios: This would be immensely helpful for tracking LTA cases. To distinguish this from Community Tech/Add a user watchlist, I'd request that this only be done on IPs and only available to admins, which I think Twinkle could manage. An alternative idea would be a "review edits" page for admins that shows diffs like Review Changes log but for recently blocked IPs.
  • Informes de Phabricator:
  • Proponente: EvergreenFir (talk) 05:43, 18 January 2022 (UTC)[responder]

Discusión

Votación

Recordar el criterio de borrado anterior

(Traducir)
  • Problema: Al eliminar manualmente una gran cantidad de páginas por el mismo motivo, tener que abrir el menú desplegable y seleccionarlo una y otra vez es engorroso y propenso a errores, especialmente si se tiene en cuenta que el motivo de eliminación no se puede cambiar.
  • Solución propuesta: En lugar de establecer siempre por defecto "Otro motivo", el motivo seleccionado por defecto debería ser el que se utilizó en la eliminación anterior. Esta característica puede ser configurable en en las preferencias de usuario. El cuadro de texto debajo de "Otro/razón adicional" debe seguir llenándose de la misma manera que sin esta característica.
  • A quiénes beneficiaría: Bibliotecarios.
  • Más comentarios: Esta característica podría generalizarse para otras acciones de registro (como traslados o protecciones). Sin embargo, podría decirse que el beneficio es menor para aquellos.
  • Informes de Phabricator:
  • Proponente: Fytcha (talk) 15:48, 22 January 2022 (UTC)[responder]

Discusión

Votación

Revert edits and warn vandals from recent changes

(Traducir)
  • Problema: Vandalism takes lots of time to identify and revert.
  • Solución propuesta: Being able to fight vandalism without leaving the page you are on; for example pressing diff brings a drop-down that will allow you to rollback/revert and see the diff view on the same page and being able to warn after rolling back without going to the user talk page. I often find edits that are not vandalism and I waste around 30 seconds finding it isn't vandalism and going back to recent changes.
  • A quiénes beneficiaría: Vandalism fighters/Admins
  • Más comentarios:
  • Informes de Phabricator:
  • Proponente: Zippybonzo (talk) 18:30, 10 January 2022 (UTC)[responder]

Discusión

Votación