Extensión:Moderación
La extensión Moderation provee protección contra el vandalismo en wikis pequeños y medianos.
Este es uno de los métodos de protección anti-vandalismo más efectivos y tiene muy poco impacto en usuarios legítimos.
Introducción
- ¿Cómo funciona?
- Cada edición (o imagen subida) por un nuevo usuario es enviada a una cola de moderación.
- Hasta que el moderador apruebe esta edición, la página no sufre cambios. Ediciones pendientes no están ni en el historial de la página ni en CambiosRecientes.
- El usuario puede ver su edición y continuar editando su propia versión de la página.
- ¿Cómo moderan los administradores?
- Una nueva página especial es proporcionada (Especial:Moderación). Se parece mucho a CambiosRecientes, pero tiene botones de "Aprobar", "Rechazar", "Aprobar todo" y "Rechazar todo".
- Las ediciones rechazadas se van al archivo de rechazados.
- Las ediciones aprobadas se aplican normalmente.
- Se mantienen registros de "quién aprobó qué". Sólo los moderadores pueden verlo.
" Si un conflicto de ediciones se detecta y no puede ser resuelto automáticamente, el moderador tiene un botón de fusionar para aplicar la edición manualmente.
- ¿Por qué es bueno?
- Los nuevos usuarios no se desaniman por captchas molestos, verificaciones de número telefónico, etc. Ellos editan normalmente, como si lo hicieran en MediaWiki sin moderación.
- Los bloqueos se vuelven prácticamente obsoletos. Y los bloqueos no son buenos (considere la posibilidad de golpear a un usuario legítimo con un bloqueo de rango, o la incapacidad de permitir buenas ediciones de un usuario no muy adecuado que a veces tiene la necesidad de vandalizar una página o dos).
- Se desaconseja el vandalismo por "querer ser notado". Nadie se sentaría durante 5 horas buscando proxies nuevos para enojar al administrador, si se sabe que todas esas acciones no son un problema.
- Los métodos de vandalismo como "destrozar una página de dos cuentas para evitar la reversión con un solo clic" ya no son efectivos.
- Los sitios web pueden operar en redes anónimas como TOR o I2P.
- Users can hide their mistakes from appearing in the revision history and even from moderators by fixing them in time.
- Since any edit is only permanently recorded upon approval, users can correct botched edit summaries.
Alternativas
¿MediaWiki tiene otros métodos contra el vandalismo? En resumen - no realmente.
MediaWiki fue desarrollado para Wikipedia. En cualquier momento, Wikipedia tiene cientos de voluntarios dispuestos a revertir vandalismo en tiempo real. Casi cualquier otro wiki a parte de Wikipedia no tiene ese tipo de ventaja. La idea integrada contra el vandalismo de MediaWiki es que el vandalismo lleva más tiempo que revertirlo. Normalmente es cierto, pero esto hace un mal trabajo al desaconsejar el vandalismo, y los administradores todavía tienen que revisar si hay vandalismo seguido, incluso si revertirlo no toma mucho de su tiempo.
Hay tres métodos conocidos para luchar contra el vandalismo:
- Hacer difíciles todas las ediciones. Por ejemplo, Lurkmore.to impone un captcha fuerte en todas las ediciones de nuevos usuarios, y se requiere muchas ediciones para finalmente ser capaz de editar sin el captcha. Por lo tanto el vándalo tiene que pasar mucho tiempo en hacer algunas ediciones.
- El contra obvio es que todos los usuarios legítimos tienen que pasar el captcha también, lo que podría desalentar ediciones menores como corregir errores de ortografía.
- Hace cumplir la verificación de usuario - por ejemplo, iniciar sesión vía Facebook. Si la red social verifica que todos sus usuarios tienen un número de teléfono válido, entonces cada intento de vandalismo requiere que el vándalo vaya a la tienda y compre una nueva tarjeta SIM. Este método es extremadamente efectivo, aunque elimina las ediciones anónimas y rechaza a los usuarios que no tienen una cuenta en ninguna red social aceptada.
- Un fuerte contra de este método es el impacto en la privacidad de los usuarios. En países no democráticos, editar una página de política puede acabar en que el gobierno trate de identificar y perseguir al usuario. Por ejemplo, Lurkmore.to fue contactado por la "fuerza especial anti-extremista" rusa con demandas de revelar información sobre los autores de páginas sobre Ramzan Kadyrov y el cóctel Molotov.[1]
- Mitiga los resultados del vandalismo. Por ejemplo, un usuario puede crear 100 páginas con títulos ofensivos, pero todas ellas pueden ser eliminadas con dos clics en Extensión: Núcleo . La extensión Moderation pertenece a esta categoría.
¿Esta extensión es estable?
La extensión es estable. Ha sido implementada en producción en la Uncyclopedia rusa (absurdopedia.net) desde noviembre de 2014.
La extensión tiene un banco de pruebas automatizado con cobertura significativa (phpunit y Selenium): Cada cambio en Moderation es automáticamente probado en:
- la versión de MediaWiki más reciente
- Latest LTS versions of MediaWiki (such as 1.43 or 1.39) that haven't been declared obsolete
Por favor lee los archivos $limitations, [$todo TO-DO] y $wont para todos los problemas conocidos. Siéntete libre de contactar al autor si tienes alguna pregunta.
¿Cuál es la diferencia entre Flaggedrevs y Approved Revs?
Extension:FlaggedRevs y Extensión:Approved Revs ocultan las malas revisiones solo a los lectores. Las ediciones de vandalismo seguirán existiendo en el historial y en CambiosRecientes, y todos los editores se toparán con ellas cuando intenten editar la página que fue objeto de vandalismo. Por lo tanto, los editores tendrían que revertir el vandalismo rápidamente.
Por otro lado, Moderation elimina por completo las ediciones vandálicas: las revisiones no aprobadas simplemente no se crean en el historial de la página, etc. Esto asegura que no solo los lectores, sino también otros editores no verán las ediciones vandálicas en ninguna de las páginas.
En resumen, (1) FlaggedRevs es para control de calidad pero no ayuda contra el vandalismo persistente. (2) Moderation es específicamente contra el vandalismo y lo vuelve completamente inefectivo.
Moderation | FlaggedRevs/ApprovedRevs | |
---|---|---|
¿Los lectores ven el vandalismo? | No | No |
¿Los editores ven el vandalismo? | No | Yes |
¿El vandalismo permanece en el historial de página? | No | Yes |
¿Se puede rechazar rápidamente todas las ediciones por usuario? | Yes | No |
¿Otros editores pueden mejorar ediciones no aprobadas? (no vandalismo) | No | Yes |
Instalación
Para versiones modernas de MediaWiki (1.39+), sigue las siguientes instrucciones:
- Echa un vistazo a las fuentes con
git clone https://github.com/edwardspec/mediawiki-moderation.git
y extrae los archivos en el directorio «Moderation
» dentro del directorioextensions/
existente. - Añade el siguiente código en la parte final de tu archivo LocalSettings.php :
wfLoadExtension( 'Moderation' );
- Ejecuta la secuencia de actualización, que creará automáticamente las tablas de la base de datos que necesita esta extensión.
- Hecho – Navega a Special:Version en el wiki para verificar que la extensión se haya instalado correctamente.
Instalaciones para versiones anteriores de MediaWiki
For MediaWiki 1.35-1.38, replace the above-mentioned "git clone" command with the following:
git clone -b REL1_35 https://github.com/edwardspec/mediawiki-moderation.git
Para MediaWiki 1.31-1.34, reemplaza el comando "git clone" mencionado arriba con lo siguiente:
git clone -b REL1_31 https://github.com/edwardspec/mediawiki-moderation.git
Para MediaWiki 1.27-1.30, reemplaza el comando "git clone" mencionado arriba con lo siguiente:
git clone -b REL1_27 https://github.com/edwardspec/mediawiki-moderation.git
Para MediaWiki 1.23-1.26, reemplaza el comando "git clone" mencionado arriba con lo siguiente:
git clone -b REL1_23 https://github.com/edwardspec/mediawiki-moderation.git
Estas versiones pueden todavía recibir actualizaciones de seguridad (si hay), pero no nuevas características.
Configuración
<span id="Parameters_for_LocalSettings.php ">
Parámetros para $LS
- $wgModerationEnable
- Si se establece como false, entonces las ediciones nuevas se aplican como es usual (no se envían a moderación). Predeterminado:
true
. - $wgModerationTimeToOverrideRejection
- El tiempo (en segundos) después del cual una edición rechazada no se puede aprobar más. Predeterminado: 2 semanas. Nota: ediciones rechazadas viejas NO son eliminadas (los moderadores siempre pueden verlas en la carpeta de rechazados incluso si el tiempo se ha agotado).
- $wgModerationOnlyInNamespaces
- If set to an array of namespace numbers (e.g.
$wgModerationOnlyInNamespaces = [ NS_MAIN, NS_FILE ];
), moderation is only enabled in these namespaces (edits in other namespaces will bypass moderation). Default (empty array): moderation is enabled everywhere. - $wgModerationIgnoredInNamespaces
- If set to an array of namespace numbers (e.g.
$wgModerationIgnoredInNamespaces = [ NS_MAIN, NS_FILE ];
), non-automoderated users can bypass moderation in these namespaces. Default (empty array): moderation can't be bypassed anywhere. - $wgModerationNotificationEnable
- If
true
, notification email will be sent to $wgModerationEmail (e.g.$wgModerationEmail = '[email protected]';
) each time an edit is queued for moderation. Default:false
. - $wgModerationNotificationNewOnly
- If
true
, only notify about new pages (but not about edits in existing pages). Default:false
.
See also: #Configuration options ONLY for pre-publish review (options not recommended for 95% of wikis).
Editing notices
When a user who is not in a trusted group edits a page, a message is added to the top of the page informing the user about moderation. You can edit this message by editing the MediaWiki:Moderation-edit-queued page.
Permisos de usuario
This extension adds two groups (automoderated
and moderator
), which have the following rights:
Permiso | ¿Qué puede hacer el usuario? | ¿Quién tiene este permiso? (por default) |
---|---|---|
skip-moderation
|
Las ediciones se aplican como es usual (no se envían a moderación). | automoderated, sysop, bot |
skip-move-moderation
|
Páginas trasladadas se aplican como es usual (no se envían a moderación). | automoderated, sysop, bot |
moderation
|
Puede acceder a Especial:Moderación | moderator, sysop |
moderation-checkuser
|
Puede ver las IP de usuarios registrados en Especial:Moderación. | checkuser |
Tips antivandalismo adicionales
Para prevenir el vandalismo, las siguientes medidas adicionales se deben aplicar:
- Please restrict the renaming of pages to a trusted group (not just
automoderated
), because it can be used for difficult-to-revert vandalism.
$wgGroupPermissions['automoderated']['skip-move-moderation'] = false;
$wgGroupPermissions['sysop']['skip-move-moderation'] = true;
- Registering new accounts with offensive names is still a way for a vandal to show itself in the RecentChanges. A simple solution is to remove newusers log from RecentChanges:
$wgLogRestrictions["newusers"] = 'moderation';
Prácticas recomendadas
Las siguientes prácticas son recomendadas:
- Sólo el vandalismo debería ser rechazado. Las ediciones no tan buenas con buenas intenciones (p. ej., agregar demasiados detalles de la trama en el artículo de Wikipedia sobre la película) es mejor aprobarlas y luego revertirlas como de costumbre. De esta manera, el autor no se ofende y el texto se guarda en el historial de la página, visible para cualquier persona.
- Cualquier usuario que se considere legítimo (hace nuevas buenas ediciones) debe agregarse al grupo
automoderated
. - Añadir usuarios al grupo
automoderated
vía$wgAutopromote
NO se recomienda, pues motiva a los vándalos a hacer muchas ediciones pequeñas (p. ej. agregar enlaces interwikis). Es mejor promocionarlos aautomoderated
manualmente por una buena edición y no promocionarlos por 30 ediciones. - Abstenerse de usar bloqueos . No protejas páginas "sólo por si acaso", excepto tal vez para plantillas importantes.
- Permite la rehabilitación completa de usuarios con un mal historial de edición. Sus ediciones útiles a artículos deben ser permitidas, no importa cuantas veces fueron bloqueados. Al mismo tiempo, hacer trolling en páginas de discusión debe ser rechazados, así sean ediciones de baja calidad con dolo.
- Please note that an editor who appears to be resubmitting a rejected edit does not necessarily imply an intent to edit-war, but the editor might have made changes to their pending edit without noticing that it was rejected in the meantime.
Non-recommended use: Moderation as pre-publish review extension
Moderation is an anti-vandalism tool first, but some wikis use it for quality control. For example, a wiki of scientific works might choose to:
- Not Approve any edits until they meet the strict quality standards of the industry.
- Not Reject any edits that are not yet good enough, so that the author could continue editing it as long as necessary.
Pros of this approach:
- New page appears as a fully reviewed, correctly formatted document with no typos, etc.
- No one except the author and moderators would see the imperfect revisions.
Cons:
- Other users can't improve the article until it is Approved. In fact, they won't even know that it exists.
- Pending changes don't have an "edit history". Moderation stores only 1 pending change for each Page/User pair. That's inconvenient if you are preparing your page for publication for weeks. User can even accidentally delete the necessary text in their pending revision, and it won't be recoverable.
Configuration options ONLY for pre-publish review
The following parameters are only needed when using Moderation for review. They are not recommended for 95% of wikis (when following the Best Practices, they are totally not needed).
- $wgModerationPreviewLink
- If
true
, Preview link is shown on Special:Moderation. Default:false
Why not recommended? Answer: when following Best Practices, you would never Reject a good change just because it is formatted poorly. Whether this edit is good or not, you know from "diff" link. "Preview" link tells you "how is this page formatted", which shouldn't affect your decision.
- $wgModerationEnableEditChange
- If
true
, moderators can modify the text of pending changes before Approving. Default:false
.
Why not recommended? Answer: easy to mess up. Moderator can accidentally delete the text of pending edit (and it won't be recoverable). Furthermore, these changes are not attributed to moderator (after approval, it looks as if the original author made the edit this way), which is creepy.
Allowing moderators to mark users as automoderated
By default, any sysop
can add users to automoderated
and moderator
groups.
If you want to allow moderators to mark users as automoderated
, you can use the following configuration:
$wgAddGroups['moderator'][] = 'automoderated';
$wgRemoveGroups['moderator'][] = 'automoderated';
Compatibilidad con otras extensiones
- Extension:Moderation should be enabled last in
LocalSettings.php
, because it aborts at least MultiContentSave hook.
- Extension:Moderation fully supports Extension:CheckUser , meaning that if CheckUser extension is enabled, then any approved edit will have correct IP, user-agent and XFF saved in the checkuser tables.
- Extension:Moderation is fully compatible with Extension:VisualEditor and Extensión:MobileFrontend .
Theoretically it should also work with other API-based editors.
- Extensión:StructuredDiscussions (also known as Flow) and Extension:CommentStreams will work, but edits in Flow/CommentStreams forums will bypass moderation.
- Moderation of Flow forums should be implemented in Extension:StructuredDiscussions itself. These forums use a non-text "content model", which is not supported by Moderation.
- CommentStreams extension misinterprets "edit was queued for moderation" as an error, which can only be fixed in Extension:CommentStreams itself.
- Extensions that modify several slots of Multi-Content Revisions (not just the main slot, as MediaWiki itself does) are not yet supported.
(currently very few extensions do)
Véase también
- Extension:ConfirmEdit - extensión CAPTCHA común.
- Extensión:AbuseFilter - common extension against spam bots and typical vandalism like blanking.
- Content approval extensions
Esta extensión está incluida en los siguientes anfitriones/granjas wiki y/o paquetes: No se trata de una lista oficial. Algunas granjas/hosts wiki y/o paquetes pueden tener disponible esta extensión aunque no estén listados aquí. Siempre compruébelo con su anfitrión o granja wiki para confirmarlo. |
- Stable extensions/es
- Special page extensions/es
- GPL licensed extensions/es
- Extensions in GitHub version control/es
- Extensions which add rights/es
- AlternateEdit extensions/es
- ApiBeforeMain extensions/es
- ApiCheckCanExecute extensions/es
- BeforePageDisplay extensions/es
- CheckUserInsertForRecentChange extensions/es
- EchoCanAbortNewMessagesAlert extensions/es
- EditFilter extensions/es
- EditFormInitialText extensions/es
- EditFormPreloadText extensions/es
- EditPage::showEditForm:fields extensions/es
- FileUpload extensions/es
- GetNewMessagesAlert extensions/es
- GetUserPermissionsErrors extensions/es
- ListDefinedTags extensions/es
- LoadExtensionSchemaUpdates extensions/es
- LocalUserCreated extensions/es
- MultiContentSave extensions/es
- PageForms::EditFormInitialText extensions/es
- PageForms::EditFormPreloadText extensions/es
- PageMoveCompleting extensions/es
- PageSaveComplete extensions/es
- RecentChange save extensions/es
- RevisionFromEditComplete extensions/es
- SpecialPageBeforeExecute extensions/es
- TitleMove extensions/es
- UploadVerifyUpload extensions/es
- WgQueryPages extensions/es
- All extensions/es
- Extensions included in Miraheze/es
- Extensions included in MyWikis/es
- Extensions included in ProWiki/es
- Extensions included in WikiForge/es
- Spam management extensions/es
- Revision management extensions/es