stringtranslate.com

Wikipedia:Solicitudes de comentarios/Propuesta de coordinador de eventos

ADOPTADO
Tras las solicitudes de cierre de SNOW y para cumplir con un plazo/evento de los desarrolladores de WMF (según TonyBallioni ): hay un consenso claro y sustancial para la adopción de la propuesta en su totalidad, con 80 votos a favor y 6 en contra después de 20 días de debate. Kevin ( alias L235  · t  · c ) 13:22, 8 de mayo de 2018 (UTC) [ responder ]

La siguiente discusión está cerrada. No la modifique. Los comentarios posteriores deben realizarse en la página de discusión correspondiente. No se deben realizar más modificaciones a esta discusión.

Seguimiento en
la tarea de Phabricator T193075

Uno de los puntos de retroalimentación sobre la reciente prueba de creación de cuentas con confirmación automática ha sido que algunos Wikimedistas que trabajan en GLAM y actividades de divulgación para realizar maratones de edición y capacitaciones sintieron que la prueba afectó negativamente su capacidad para atraer nuevos miembros a la comunidad Wikimedia. Para ayudar a resolver estas inquietudes, propongo que eventcoordinatorse cree un nuevo permiso de usuario con las siguientes capacidades y pautas para su uso y concesión:

  1. El eventcoordinatorgrupo de usuarios recibirá la capacidad de agregar temporalmente +confirmedcuentas recién creadas y también recibirá el (noratelimit)derecho de ayudar con la creación de cuentas. Esto permitirá que las nuevas cuentas confirmadas creen páginas en el espacio principal sin esperar 4 días y 10 ediciones y permitirá la creación de muchas cuentas nuevas desde la misma dirección IP.
  2. Los coordinadores de eventos deben establecer el tiempo de expiración del derecho de usuario confirmado en no más de diez días desde el momento en que se otorga.
  3. Los administradores solo deben conceder de forma permanente el eventcoordinatorderecho de usuario a editores con un historial establecido de edición en Wikipedia. Los administradores pueden, a su discreción, conceder temporalmente el permiso a editores que estén organizando eventos de divulgación pero que no tengan una experiencia significativa en Wikipedia. A los usuarios que no hayan editado en más de un año se les puede retirar el permiso por inactividad.
  4. Los coordinadores de eventos solo deben confirmar a los usuarios que realmente participan en un evento de divulgación.

TonyBallioni ( discusión ) 14:24 18 abr 2018 (UTC) [ responder ]


Apoyo

  1. Apoyo como proponente. En general, creo en dar a la gente las herramientas para hacer su "trabajo" en Wikipedia, especialmente cuando para algunos de ellos, es en realidad su trabajo en la vida real. Hay una facción significativa de personas que dicen que lo necesitan, así que creo que deberíamos dárselo. TonyBallioni ( discusión ) 14:24 18 abr 2018 (UTC) [ responder ]
  2. Apoyo con la salvedad de que el punto n.° 2 debería decir
    Los coordinadores de eventos deben establecer el tiempo de vencimiento del derecho de usuario confirmado en no más de diez días a partir del momento en que se otorga. fin del evento. "
    Después de todo, los eventos pueden durar más de 10 días y el objetivo del vencimiento es eliminar el derecho cuando ya no es necesario para el evento. Saludos So Why 14:31, 18 de abril de 2018 (UTC) [ responder ]
    Sí , pero después de 10 días se confirmarán automáticamente. Primefac ( discusión ) 14:33 18 abr 2018 (UTC) [ responder ]
    Casi lo cambié y luego recordé por qué estaba redactado de esa manera. 4 días es el umbral de confirmación automática, por lo que darle a un usuario 10 días le permite tiempo adicional para realizar las modificaciones, pero la parte de "duración" mínima ya no es un problema. TonyBallioni ( discusión ) 14:36, 18 de abril de 2018 (UTC) [ responder ]
    El requisito de edición para llegar a la confirmación automática también es una cosa. -- Izno ( discusión ) 14:38 18 abr 2018 (UTC) [ responder ]
    @ Izno , TonyBallioni , Primefac y Kelapstick : Si bien es probable que la mayoría de los editores hayan alcanzado las 10 ediciones para ese momento, no es seguro. Hay escenarios plausibles en los que las ediciones solo ocurren después de 10 días (por ejemplo, si los derechos se asignan el primer día, pero la edición comienza solo dos semanas después), por lo que no veo ninguna razón para agregar un lenguaje que podría ser problemático si también podemos usar un lenguaje que ciertamente no lo será. Saludos So Why 14:41, 18 de abril de 2018 (UTC) [ responder ]
    Ese es un buen punto, y una descripción genérica útil en lugar de un cronograma prescriptivo y único para todos. Creo que tu línea aún necesita algo de trabajo. ¿Por qué?, como estás diciendo diez días después del final del evento, cuando tal vez debería decir que los coordinadores del evento deben establecer el tiempo de vencimiento del derecho de usuario confirmado para que finalice a más tardar el último día del evento. Lo que daría margen para permitir que el otorgante conceda hasta el final del evento (independientemente de la duración), pero no más. También noto que no puedo imaginar que alguien que participe en un evento de edición de diez días y no alcance las diez ediciones realmente requiera una cuenta confirmada, pero tampoco veo ningún daño en eso. -- kelapstick ( bainuu ) 14:46, 18 de abril de 2018 (UTC) [ responder ]
    ¿A un usuario confirmado también se le otorga el permiso de confirmación automática, o eso lo bloqueará? ¿O se le otorgará al usuario el permiso de confirmación automática después de la primera edición después de que expire su confirmación? — Compassionate727  ( T · C ) 14:54, 18 de abril de 2018 (UTC) [ responder ]
    Esta es una pregunta importante. Si existen restricciones adicionales (como tener que realizar una edición adicional después de que el estado "confirmado" expire para convertirse en "autoconfirmado"), creo que sería preferible eliminar por completo el requisito de vencimiento de esta propuesta si queremos conservar a los editores después de tales eventos de divulgación. Respondido por TonyBallioni a continuación. -- Ahecht (
    PAGINA DE DISCUSION    ) 15:27 18 abril 2018 (UTC) [ responder ]
    Creo que se propusieron 10 días en la RfC de ACPERM o en la página de discusión (no puedo seguir toda la discusión sobre ACTRIAL). Normalmente, solo asigno el permiso por 7 días cuando se solicita para un ALT, asumiendo que si lo obtienen de antemano, no es un gran problema ya que expirará en poco tiempo. No tengo ninguna objeción real a cualquier lenguaje que la gente quiera proponer sobre ese punto, ya sea en la RfC o como parte de la "fase de ajustes" si esto se aprueba. Además, esto fue un conflicto de edición y principalmente respondiendo a kelapstick, pero confirmado no bloquea lo autoconfirmado. TonyBallioni ( discusión ) 14:57, 18 de abril de 2018 (UTC) [ responder ]
    @ Kelapstick : No me importa que lo exprese así. Saludos. So Why 15:21, 18 de abril de 2018 (UTC) [ responder ]
  3. Soporte Me parece sensato que no debería ser necesario ser administrador para proporcionar acceso confirmado a los usuarios en un evento que estás organizando. SoWhy No creo que se necesite confirmar durante más de diez días, ya que después de diez días deberían tener suficientes ediciones para ser confirmados automáticamente de todos modos. En realidad, deberíamos tener un valor predeterminado (o máximo) de diez días (o menos) en la concesión de confirmados de todos modos, ya que es solo un derecho temporal. -- kelapstick ( bainuu ) 14:35, 18 de abril de 2018 (UTC) [ responder ]
  4. El soporte como complemento útil de ACPERM. · · · Peter (Southwood) (discusión) : 14:44 18 abr 2018 (UTC) [ responder ]
  5. Apoya a Logical, en vista de que ACTRIAL busca convertirse en permanente el próximo mes. Courcelles ( discusión ) 14:55 18 abr 2018 (UTC) [ responder ]
  6. Apoyo para abordar las inquietudes de los coordinadores de eventos en la convocatoria de eventos de ACTRIAL . Los eventos de edición en persona son una parte importante de nuestro programa de divulgación. Si las personas que actualmente coordinan estos eventos piensan que esto les sería útil, entonces estoy totalmente a favor. Ajpolino ( discusión ) 14:58 18 abr 2018 (UTC) [ responder ]
  7. El apoyo como medida paliativa del principal inconveniente del ACPERM. MER-C 14:59, 18 de abril de 2018 (UTC) [ responder ]
  8. Apoyo como mitigación para ACPERM. La supervisión por parte de un coordinador de eventos debería dar tanto control sobre estos nuevos editores como sea necesario. Certes ( discusión ) 15:05 18 abr 2018 (UTC) [ responder ]
  9. Los participantes de los editatones reciben una formación y una orientación que superan con creces la experiencia necesaria para obtener la confirmación. Vexations ( discusión ) 15:16 18 abr 2018 (UTC) [ responder ]
  10. Apoyo Esto es simplemente sentido común. "Confirmado" es un estándar muy bajo que superar, y habrá trazabilidad/rendición de cuentas. No tendría ningún problema con esta propuesta incluso sin una fecha de vencimiento. -- Ahecht (
    PAGINA DE DISCUSION    ) 15:27 18 abril 2018 (UTC) [ responder ]
  11. El soporte es un enfoque razonable para la cuestión planteada. Puede ser una buena idea especificar que quien otorgue el estado de confirmado debe estar presente con ese usuario en el evento de divulgación. De lo contrario, no podemos dar por sentado que el usuario tiene acceso al soporte que suponemos que ofrecen los eventos de divulgación (es decir, la persona podría ser cualquier usuario que quiera ser confirmado).Las rododendritas hablan\\ 15:33, 18 de abril de 2018 (UTC) [ responder ]
  12. Apoyo No debería ser necesario, pero lamentablemente parece serlo a la luz de ACTRIAL. Mike Peel ( discusión ) 15:37 18 abr 2018 (UTC) [ responder ]
  13. Apoyo . Si bien la oposición a ACPERM fue muy baja, los organizadores del evento expusieron argumentos muy claros y comprensibles a favor de este requisito. Kudpung กุดผึ้ง ( discusión ) 15:39, 18 de abril de 2018 (UTC) [ responder ]
  14. Soporte . No soy un asiduo a los eventos, pero ayudé en un maratón de edición de estudiantes recientemente. Se les dijo a los estudiantes que crearan cuentas con anticipación, pero pocos lo hicieron. Es doloroso ver a la gente ingresar CAPTCHAs una y otra vez durante horas, que es lo que sucede cuando un usuario no confirmado agrega una referencia web a una página. Hacer que los usuarios experimentados muevan páginas del espacio de usuario al espacio principal al final no es lo ideal, ya que crea un atasco de tareas al final del maratón de edición y diluye nuestro mensaje de que los contribuyentes son responsables de sus propias ediciones. A largo plazo, me gustaría ver una solución más amplia para el problema de CAPTCHA, tal vez usando algo como ORES para distinguir entre humanos y robots de spam en menos de cuatro días. Mientras tanto, este es un paso en la dirección correcta. Clayoquot ( discusión | contribuciones ) 16:03, 18 de abril de 2018 (UTC) [ responder ]
    Pregunta, porque supongo que sabrás más sobre esto que yo: ¿podrías aclarar qué es lo que hace que las contribuciones parezcan menos importantes si empiezas en el espacio de usuario o de borrador y haces que los coordinadores muevan las páginas al espacio principal? Todo lo que he leído en otros lugares indica que los nuevos usuarios que editan de buena fe están perfectamente contentos de empezar fuera del espacio principal. — Compassionate727  ( T · C ) 16:12, 18 de abril de 2018 (UTC) [ responder ]
    Claro, gracias por tu pregunta. Sí, es bueno que los nuevos usuarios comiencen a escribir artículos fuera del espacio principal. Lo que estaba tratando de decir es que me gustaría que ellos mismos pudieran mover los artículos al espacio principal cuando sientan que el artículo está listo. Eso ayudaría a transmitir el mensaje de que Wikipedia es un sistema en el que pedimos perdón en lugar de permiso (es decir, los colaboradores publican y LUEGO otros revisan), y creo que ese es un concepto central de lo que es Wikipedia. Clayoquot ( discusión | contribuciones ) 16:25, 18 de abril de 2018 (UTC) [ responder ]
  15. Apoyo por ACPERM, pero supongo que, en pequeña medida, esto también es una especie de desagregación. —SerialNumber54129 paranoia / cheap sh*t room 16:10, 18 de abril de 2018 (UTC) [ responder ]
  16. Apoyo - Nunca he sido partidario de limitar la creación de artículos a los usuarios autoconfirmados, por lo que no tengo problema en brindar mi apoyo para relajar un poco la restricción cuando parezca razonable. — Godsy ( CONVERSACIÓN )  16:19  , 18 de abril de 2018 (UTC) [ responder ]
  17. Richard Nevell ( discusión ) 16:20 18 abr 2018 (UTC) [ responder ]
  18. Soporte Esto les da a las personas que organizan eventos las herramientas que pidieron. Mantiene más o menos el status quo que teníamos para la creación de artículos en eventos como lo teníamos antes de ACPERM, por lo que no puede empeorar las cosas. También creo que es importante que quienes trabajan en eventos vean que la comunidad en general responde a sus necesidades expresadas. Jbh Talk 16:31, 18 de abril de 2018 (UTC) [ responder ]
  19. Soporte Los editores de Editathon son editores de buena fe y reciben un poco de ayuda para familiarizarse con la notabilidad, etc. Como resultado, no son realmente el mismo tipo de editor nuevo que ACtRIAL/ACPERM fue diseñado para controlar. Tiene sentido hacer una excepción y ayudar a los coordinadores de eventos de esta manera. — Insertcleverphrasehere ( o aquí ) 17:03, 18 de abril de 2018 (UTC) [ responder ]
  20. Apoyo , parece razonable la adaptación a los eventos de divulgación. Renata ( discusión ) 17:21 18 abr 2018 (UTC) [ responder ]
  21. Apoyo . En la discusión de ACPERM, se presentó un caso claro y defendible a favor de este nuevo derecho de usuario, y no creo que los temores expresados ​​en la sección Oposición (en el momento de mi voto) presenten ningún riesgo serio. Boing! dijo Zebedee ( discusión ) 18:02 18 abr 2018 (UTC) [ responder ]
    En cuanto a las preocupaciones de que esto hará que sea más fácil para la gente que se presenta a los eventos producir malos artículos, creo que lo primero que hay que decir es que sin ACPERM (es decir, como siempre ha sido) ya pueden producir todos los malos artículos que quieran, por lo que la implementación de ACPERM más eventcoordinator no cambia eso. Además, la gran mayoría de los malos artículos (por un margen abrumador) simplemente no se crean en los eventos, como cualquiera que haya pasado algún tiempo trabajando en NPP y CSD sabe. ACPERM reducirá el torrente de malos artículos en general (como ACTRIAL ha demostrado claramente), y eventcoordinator simplemente restablecerá el status quo para los eventos. Boing! dijo Zebedee ( discusión ) 09:16, 19 de abril de 2018 (UTC) [ responder ]
  22. Apoyo He sido organizador de cientos de eventos presenciales de Wikipedia. Las personas que asisten a los eventos están ansiosas por hacer lo correcto y producir contenido de mayor calidad que otros usuarios nuevos que solo están en línea. Cuando las personas asisten a un evento de Wikipedia, a menudo tienen la esperanza de crear un nuevo artículo y tener una experiencia memorable y positiva. La Fundación Wikimedia financia activamente la difusión en persona en todo el mundo y parte de la experiencia es publicar un artículo. Quitar la capacidad de publicar hace que la difusión sea mucho más complicada. Sigamos esperando que los coordinadores de eventos hagan lo correcto y ofrezcan la capacitación adecuada para que los nuevos usuarios publiquen de acuerdo con las reglas y tengan una experiencia compartida de edición de Wikipedia con un grupo de colegas wiki. Blue Rasberry (discusión) 18:48 18 abr 2018 (UTC) [ responder ]
  23. Apoyo todos mis comentarios en discusiones anteriores sobre este tema. Andy Mabbett ( Pigsonthewing ); Habla con Andy ; Ediciones de Andy 18:56, 18 de abril de 2018 (UTC) [ responder ]
  24. Soporte . Hay muchos lugares en Wikipedia donde hemos optado por aplicar un nivel bajo para evitar la mayoría de las situaciones indeseables, sin imponer demasiados inconvenientes a los usuarios de buena fe. Por ejemplo, los expertos en calcetines pueden evadir la semiprotección, pero casi siempre es suficiente para detener a los vándalos. Del mismo modo, ACPERM no debería considerarse una medida de primera línea para garantizar que todos los artículos cumplan con los estándares, sino una barrera lo suficientemente mínima como para mantener fuera la mayor parte de la avalancha de basura. La asistencia a un evento de divulgación real es para la mayoría de las personas una barrera más alta, y las personas también tendrán orientación en persona. Esto es suficiente para "mantener fuera la mayor parte de la avalancha de basura" de esas personas, pero es lógico, y creo en las personas de divulgación cuando dicen, que los asistentes al evento en su mayoría tienen buenas intenciones. Al otorgar el derecho de coordinador del evento de forma permanente solo a editores experimentados, los asistentes que reciban +confirmación también tendrán ayuda experimentada y, por lo tanto, estarán en una posición mucho mejor para crear buen contenido que un editor nuevo normal.
    En resumen, deberíamos confiar en coordinadores de eventos con experiencia para que gestionen bien los eventos y los hagan excelentes tanto para la enciclopedia como para los nuevos editores; los que se oponen, por otro lado, no se sostienen. BethNaught ( discusión ) 19:14 18 abr 2018 (UTC) [ responder ]
  25. Apoyo lo anterior. Una elección sensata. - F ASTILY 19:41, 18 de abril de 2018 (UTC) [ responder ]
  26. Apoyo para mantener el status quo dentro de Outreach después de que entre en vigencia la regla 4/10. De lo contrario, los nuevos editores entusiastas que asistan a los eventos pueden sentirse desanimados. Cesdeva ( discusión ) 20:00, 18 abril 2018 (UTC) [ responder ]
  27. El apoyo no va a hacer daño a nadie. Tenemos NPR para detectar páginas problemáticas de baja calidad. Legacypac ( discusión ) 20:05 18 abr 2018 (UTC) [ responder ]
  28. Apoya algo realmente valioso en una edición bien organizada. Jheald ( discusión ) 23:40 18 abr 2018 (UTC) [ responder ]
  29. Apoyo . Creo que este es un ajuste necesario para evitar paralizar los eventos de divulgación y edición de buena fe. ¿Se crearán malos artículos en los editatones? Seguro, pero es una cantidad manejable y no tenemos que preocuparnos por la mala fe y los editores pagos en estos casos. Es mucho más probable que los artículos creados en los editatones sean de alta calidad, notables y que valga la pena incluirlos en la enciclopedia. No veo una razón convincente para obligar a dichos usuarios a pasar por muchos obstáculos para crear en el espacio de nombres principal. Kaldari ( discusión ) 23:50, 18 de abril de 2018 (UTC) [ responder ]
  30. Soporte -Nunca he asistido a un evento y nunca lo haré, pero me parece una buena idea. Beyond My Ken ( discusión ) 00:27 19 abr 2018 (UTC) [ responder ]
  31. Apoyo Buena idea. La experiencia mostrará si es necesario hacer ajustes. Johnuniq ( discusión ) 00:55 19 abr 2018 (UTC) [ responder ]
  32. Apoyo incondicionalmente según mis comentarios en la convocatoria de propuestas de ACPERM ; esto es absolutamente necesario después de ACPERM. Notaré que esta es en realidad mi segunda opción, ya que sigo creyendo que integrar esto accountcreatorsería más limpio. Temo que uno se vuelva vestigial. ~ Amory ( u • t • c ) 02:00, 19 de abril de 2018 (UTC) [ responder ]
  33. Apoya lo que se ha dicho. Esto nos ayudará a crecer y aportará flexibilidad a quienes organizan estos eventos. -- œ ™ 05:35, 19 de abril de 2018 (UTC) [ responder ]
  34. Apoyo . Un buen nuevo permiso con una necesidad demostrada. Tazerdadog ( discusión ) 07:49 19 abr 2018 (UTC) [ responder ]
  35. Apoyo Durante la discusión de ACPERM que acaba de concluir, más o menos les prometimos a los organizadores del evento que se haría algo para atender sus inquietudes. Será mejor que lo hagamos ahora y no creo que eso resulte en un daño grave : Noyster (discusión), 08:56 19 abr 2018 (UTC) [ responder ]
  36. Apoyo , estoy contento con la respuesta a mis preguntas y contento de apoyar esta iniciativa. Necesitamos buenos creadores de contenido y cualquier cosa que pueda ayudar a reclutar nuevos editores, particularmente en áreas menos cubiertas, es algo bueno, siempre que no genere otros problemas hasta el punto de que la propuesta sea negativa, lo cual estoy seguro de que no ocurriría y no lo es. Fish + Karate 09:14, 19 de abril de 2018 (UTC) [ responder ]
  37. Soporte Sería más feliz con una solución que evite una afluencia de artículos que podrían merecer ser eliminados durante los eventos, ya que esto no sucede (por ejemplo, la creación como borradores seguidos de su traslado al espacio principal una vez que un organizador los haya examinado), pero las desventajas de eso se han señalado correctamente y es probable que no haya suficiente apoyo para el enfoque. En su defecto, esta parece una solución viable. -- Elmidae ( discusión · contribuciones ) 13:00, 19 de abril de 2018 (UTC) [ responder ]
  38. Soporte Tengo dos pequeñas preocupaciones con la redacción. Primero, ¿"usuarios que realmente participan en un evento de divulgación" significa que tienen que estar físicamente presentes? Para eventos "virtuales", prefiero confiar en que los administradores agreguen el permiso. Segundo, creo que debe haber algún umbral de actividad para otorgar este derecho. Si dos editores con un total de 50 ediciones están organizando un maratón de edición, existe el riesgo de que los artículos creados estén muy fuera de las expectativas de la comunidad de Wikipedia, y creo que es una característica que los nuevos editores no serían confirmados automáticamente. En la práctica, no veo que ninguno de estos cause problemas incluso con la redacción actual, y se pueden solucionar más adelante si causan problemas. power~enwiki ( π , ν ) 19:35, 19 de abril de 2018 (UTC) [ responder ]
  39. Apoyo a todos los anteriores después de sopesar detenidamente ambas partes. Ss gem 00:20, 20 de abril de 2018 (UTC) [ responder ]
  40. Apoyo de otros. Necesario después de la implementación de ACPERM. Las nociones, presentadas por algunos en el otro RFC, de confiar en el cuerpo administrativo para agregar permisos confirmados o requerir que los participantes potenciales registren una cuenta con anticipación, mostraron una falta de comprensión de cómo funcionan los eventos de divulgación en persona. Esta propuesta es sensata y bien pensada. — Esto, aquello y lo otro (discusión) 12:21, 20 de abril de 2018 (UTC) [ responder ]
  41. Como ya han indicado Kudpung y Certes , esto es necesario para mitigar los inconvenientes que pueda tener el trabajo de divulgación que surja de ACPERM y lograr un beneficio mutuo para NPR/NPP y Outreach. La supervisión por parte de un coordinador de eventos debería dar tanto control sobre estos nuevos editores como sea necesario. Stinglehammer ( discusión ) 15:49 20 abr 2018 (UTC) [ responder ]
  42. Apoyo Las ventajas evidentes superan a las desventajas hipotéticas. Comparto la preocupación expresada anteriormente de que exigir a los posibles participantes de un evento que registren sus cuentas con bastante antelación no funcionará, ya que no comprende la dinámica de lograr que las personas se sumen a un software nuevo de manera seria. XOR'easter ( discusión ) 16:32 20 abr 2018 (UTC) [ responder ]
  43. Apoyo : puede que haya otras formas de lograr el mismo objetivo, pero confío en que los GLAMers y otros no abusen de esto. Smallbones ( smalltalk ) 17:24, 20 de abril de 2018 (UTC) [ responder ]
  44. Apoyo para que los eventos se desarrollen sin problemas a pesar de ACPERM. Calliopejen1 ( discusión ) 19:38 20 abr 2018 (UTC) [ responder ]
  45. El soporte autoconfirmado no es realmente un gran problema y cualquiera que tenga un fuerte deseo de abusar de Wikipedia puede evitarlo con bastante facilidad. El buen funcionamiento de los eventos de divulgación compensa cualquier inconveniente. Hut 8.5 19:43, 20 de abril de 2018 (UTC) [ responder ]
  46. Apoyo Propuesta sensata que resuelve un problema que preocupaba a muchos. Johnbod ( discusión ) 12:38 21 abr 2018 (UTC) [ responder ]
  47. Soporte débil : por lo general, no soy partidario de crear más grupos de usuarios, pero creo que hay un caso de uso claro aquí y, en general, estoy a favor de brindarles a las personas las herramientas que necesitan para realizar sus trabajos wiki. -- Ajraddatz ( discusión ) 02:37, 23 de abril de 2018 (UTC) [ responder ]
  48. Soporte : como alguien que organiza eventos de divulgación con regularidad, esta sería una herramienta valiosa para optimizar la experiencia del editor. Jason.nlw ( discusión ) 09:42, 23 de abril de 2018 (UTC) [ responder ]
  49. Soporte L293D  ( ☎  •  ✎ ) 13:22 23 abr 2018 (UTC) [ responder ]
  50. Apoyo He participado en muchos eventos de capacitación presencial para nuevos usuarios. La primera experiencia de un editor con Wikipedia puede ser muy formativa para ayudarlos a decidir si vale la pena dedicarle tiempo y esfuerzo. Como capacitadores, hacemos todo lo posible para prepararlos, pero los problemas técnicos y las restricciones pueden ser frustrantes y desalentadores, aunque acepto totalmente que deben existir restricciones para los nuevos usuarios de manera predeterminada. Un usuario nuevo en un evento que está siendo capacitado por un wikipedista experimentado está en una posición mucho mejor que alguien que presiona el botón de edición por curiosidad. Por lo general, habrán tenido una larga discusión sobre Wikipedia como comunidad, sus objetivos y normas, incluso antes de tocar la computadora. El paso propuesto ayudará a que estos eventos sean una experiencia positiva y productiva y nos ayudará a hacer crecer la comunidad de voluntarios. MartinPoulter ( discusión ) 08:45, 24 de abril de 2018 (UTC) [ responder ]
  51. Apoyo Esto sería de gran ayuda para aquellas personas que, como yo, organizan una serie de eventos para nuevos editores. Lirazelf ( discusión ) 12:58, 25 de abril de 2018 (UTC) [ responder ]
  52. Apoyo - sí, esto dará lugar a algunos baches en los artículos más pobres con los que New Page Patrol tendrá que lidiar, pero el porcentaje de artículos insatisfactorios no se parecerá en nada a los días anteriores a ACTRIAL. A cambio, podemos conseguir al menos algunos artículos nuevos más que la configuración actual no permitiría, algunos editores nuevos más interesados. Por supuesto, es fácil para quien no tiene que lidiar con las desventajas argumentar esto, pero Wikipedia debería estar a favor de permitir la edición a menos que haya aspectos negativos primordiales que indiquen lo contrario. No creo que los aspectos negativos primordiales sean lo suficientemente válidos en el caso de las ediciones. Nosebagbear ( discusión ) 10:38, 24 de abril de 2018 (UTC) [ responder ]
  53. Apoyo una idea muy útil que resuelve una de las preocupaciones clave de la convocatoria de propuestas de ACTRIAL/ACPERM. Callanecc ( discusión • contribuciones • registros ) 03:29, 26 de abril de 2018 (UTC) [ responder ]
  54. Apoyo Es perfectamente razonable. Abordaré las inquietudes planteadas por quienes están involucrados con GLAM. Doc James ( discusión · contribuciones · correo electrónico ) 12:26, ​​26 de abril de 2018 (UTC) [ responder ]
  55. Soporte . Según Amory, esto sería más claro si se incluyera en accountcreator, pero la expansión de los grupos de usuarios aún no es una preocupación importante. 14:04, 26 de abril de 2018 (UTC)
    Solo respondiéndoles a ti y a Amorymeltzer , ya que se ha hecho varias veces ahora: hay preocupaciones de seguridad con el accountcreatorque dividirlo de esta manera realmente aborda: tenerlo como un grupo separado y reservarlo accountcreatorpara personas que son parte de ACC es en realidad un mejor resultado ya que corrige una falla en el sistema actual (dándole a las personas que son esencialmente aleatorias en muchos casos acceso para anular la lista negra y los filtros anti-spoof) mientras que también corrige una preocupación que se planteó en gran medida con respecto a la creación directamente en el espacio principal. Una vez que esto pase, no habrá necesidad de que los coordinadores de eventos tengan acceso de creador de cuentas en la mayoría de los casos, lo que es un paso en la dirección correcta en ese sentido. TonyBallioni ( discusión ) 21:28, 26 de abril de 2018 (UTC) [ responder ]
  56. Apoyo , aunque también estoy de acuerdo en que incorporarlo accountcreatorpuede ser mejor a largo plazo. Richard 0612 21:13, 26 de abril de 2018 (UTC) [ responder ]
  57. Apoyo Será más lento y complicado, pero parece necesario para mitigar el molesto retraso de cuatro días. Andrew D. ( discusión ) 23:28 26 abr 2018 (UTC) [ responder ]
  58. Soporte : Como voluntario y anfitrión de eventos, me ha quedado claro muchas veces que esto es más que esencial. ɱ (discusión) · vbm · coi) 02:46, 27 de abril de 2018 (UTC) [ responder ]
  59. Apoyo según lo mencionado anteriormente. Como alguien que ha colaborado en editathons, creo que sería realmente útil poder proporcionar a los nuevos usuarios un acceso confirmado. Todavía no he visto a un vándalo presentarse en persona en un evento de Wikipedia. Tony Tan  ·  discusión 04:34, 27 de abril de 2018 (UTC) [ responder ]
  60. Apoyo como parte del paquete ACPERM. Cabayi ( discusión ) 13:22 27 abr 2018 (UTC) [ responder ]
  61. Apoyo He participado en muchos eventos de divulgación y, si bien comparto algunas de las preocupaciones de los opositores de que gran parte de la divulgación se centra en agregar nuevos artículos, he visto lo que hace el acelerador de edición cuando un instructor dice "todos presionen guardar ahora" y el problema que tiene que resolver un académico porque su cuenta no está confirmada y, por lo tanto, si cita una fuente en línea, debe completar un captcha. Ϣere Spiel Chequers 12:35, 29 de abril de 2018 (UTC) [ responder ]
  62. Soporte según los comentarios de Theredproject. - codificador   de Python ( discusión  |  contribuciones ) 22:35, 29 de abril de 2018 (UTC) [ respuesta ]
  63. Soporte Este es un requisito básico para la realización exitosa de eventos. No todos los eventos deberían involucrar o involucran la creación de nuevos artículos, pero algunos sí: no deberíamos restringir artificialmente el tipo de eventos que la gente organiza, sino permitir una variedad y promover la experimentación. La forma de prevenir el abuso es monitorear lo que sucede en los eventos; esto idealmente debería hacerlo alguien relacionado con la organización del evento, pero si se anuncian eventos, cualquiera puede hacerlo. DGG ( discusión ) 22:25 30 abr 2018 (UTC) [ responder ]
  64. Un paso natural tras la implementación de ACTRIAL. Esquivalience ( discusión ) 02:55 1 may 2018 (UTC) [ responder ]
  65. Apoyo Hace poco organicé un evento durante ACTRIAL y no tener esta capacidad hizo que las cosas llevaran mucho más tiempo y eliminó parte de la sensación de logro de las personas que estaban siendo capacitadas en el evento. John Cummings ( discusión ) 11:51 1 may 2018 (UTC) [ responder ]
  66. Soporte No es perfecto, pero proporcionará una opción para que la divulgación se lleve a cabo de una manera más sencilla que el lío que puede requerir actualmente. En mi humilde opinión, un derecho de creación masiva de este tipo debería ser un derecho limitado en el tiempo para el individuo que crea las cuentas también, en lugar de un derecho permanente que reciben para evitar el abuso por parte de alguien que "adquiera" su información de inicio de sesión. -- AlisonW ( discusión ) 13:01, 2 de mayo de 2018 (UTC) [ responder ]
  67. Gamaliel ( discusión ) 13:49 2 may 2018 (UTC) [ responder ]
  68. No es una obviedad . Debería haberse propuesto junto con ACTRIAL. Página de discusión de OhanaUnited 14:14, 2 de mayo de 2018 (UTC) [ responder ]
  69. Apoyo según las discusiones anteriores sobre este tema. Creo que es necesario. jcc ( té y galletas ) 19:11, 2 de mayo de 2018 (UTC) [ responder ]
  70. Apoyo en nombre de Art+Feminism. Gracias por apoyar las necesidades de los organizadores de eventos. -- Theredproject ( discusión ) 20:01 2 may 2018 (UTC) [ responder ]
  71. Apoyo - Esta es una idea maravillosa. S warm ♠ 03:07, 3 de mayo de 2018 (UTC) [ responder ]
  72. Soporte — Me quita la preocupación sobre ACPERM. Los maratones de edición son buenos para la enciclopedia y obtener nuevos artículos de ellos en el espacio principal es bueno para AfC.-- Carwil ( discusión ) 20:34 4 may 2018 (UTC) [ responder ]
  73. Soporte - Como editor y organizador de eventos offline, esto suena bien. Una forma básica y útil de facilitar a los organizadores de eventos la tarea de poner en marcha a sus participantes. Creo que la mayoría de los eventos offline se llevan a cabo lo suficientemente bien como para garantizar una orientación adecuada, y la limitación de tiempo es un buen detalle para ayudar a prevenir la inexperiencia y el abuso después de que finaliza un evento. ~ Super Hamster Talk Contribs 06:21, 5 de mayo de 2018 (UTC) [ responder ]
  74. Apoyo . El objetivo principal del requisito de confirmación automática para la creación de una página nueva es evitar el vandalismo impulsivo. Cualquiera que se tome la molestia de asistir en persona a un maratón de edición, asista a la capacitación que siempre (según mi experiencia) se brinda como parte del evento y luego quiera crear un artículo tiene menos probabilidades de ser un vándalo que alguien que hace 10 ediciones menores en 4 días y nada más. No creo que ninguno de los problemas planteados en la sección de oposición sean preocupaciones realistas, o al menos no lo suficientemente fuertes como para superar los beneficios de esta propuesta. Según mi experiencia, los editores experimentados de un evento revisan con frecuencia las contribuciones de los nuevos asistentes y ofrecen consejos sobre cómo crear artículos válidos y realizar ediciones válidas. Cuando asisto a un evento de este tipo, concedo rutinariamente el estado de confirmación permanente a cualquiera que lo solicite o para una de las tareas para las que es un requisito, y nunca he visto que se aprovechen de esto para hacer daño. No veo la necesidad de hacer que el estado de confirmación sea temporal. DES (discusión) DESiegel Contribuciones 17:01, 5 de mayo de 2018 (UTC) [ respuesta ]
    DESiegel : Solo estoy notando que ahora el estándar es otorgar solo usuarios confirmados temporalmente. Los usuarios autoconfirmados se adjuntan automáticamente después de 4 días, por lo que el permiso se vuelve redundante. Normalmente otorgo permisos por una semana o un mes cuando se solicita en PERM (según las circunstancias). Xaosflux probablemente pueda decir más que yo sobre el motivo por el cual preferimos no tener usuarios autoconfirmados también confirmados. TonyBallioni ( discusión ) 17:05 5 may 2018 (UTC) [ responder ]
    Ahora estoy al tanto de eso, TonyBallioni (aunque no lo estaba antes de leer esta propuesta). Sin embargo, no veo ninguna buena razón para que así sea. "Desordenar el grupo de usuarios" me parece un tema sin importancia. Quizás estoy pasando algo por alto. En cualquier caso, apoyo la propuesta tal como se hizo, y también la apoyaría si no sugiriera límites a la duración del derecho confirmado. DES (discusión) DESiegel Contribs 17:25, 5 de mayo de 2018 (UTC) [ responder ]
    Un período más largo (como un mes) también debería estar bien, aunque realmente creo que los maratones de edición deberían incluir algo de edición (incluso a través de WP:TWA , que realiza entre 8 y 9 ediciones). Ocasionalmente, limpiamos cuentas abandonadas que quedan en este grupo, pero rara vez. — xaosflux Talk 17:19, 5 de mayo de 2018 (UTC) [ responder ]
    Siempre supuse que el confirmedgrupo solo contendría editores temporalmente, ya que el permiso se volvería redundante después de 4 días y 10 ediciones. Eso significaría que al examinar Special:ListUsers/confirmed sería fácil detectar cualquier "rareza", es decir, editores a los que se les ha otorgado el permiso hace más de unas pocas semanas: o ya no necesitan el permiso o no han realizado 10 ediciones, por lo que levantaría una (pequeña) bandera. Sin embargo, cuando realmente miré la lista, que tiene 528 miembros inesperados, parece que estaba equivocado: hay un miembro que ha sido confirmado desde 2005 (que solo ha realizado 7 ediciones) y muchos otros que han estado en el grupo durante años. No me preocuparé por eso, pero tal vez el grupo debería limpiarse si va a tener algún sentido otorgarlo confirmedtemporalmente. -- RexxS ( discusión ) 19:18, 5 de mayo de 2018 (UTC) [ responder ]
    @ RexxS : la mayoría de estos son de antes de la época en que la expiración era posible, y de cuando el único punto real de confirmación era evitar el vandalismo mediante scripts1, básicamente "sí, esta cuenta está asociada con una persona real". A veces era por alguna otra razón como "permitir una carga", que ya no es necesaria, pero a menos que hagamos una regla de limpieza masiva que pase por todas esas cuentas, lleva mucho tiempo. En relación con la gestión de eventos, estas personas podrían haber estado en el evento y haber obtenido una cuenta, pero luego nunca la usaron (la mayoría de las muy antiguas, sin edición, ya se han purgado) o no hicieron al menos 10 ediciones. Hacer que los asistentes completen TWA o algún otro conjunto de actividades generalmente debería ser suficiente para que lleguen a 10 si el evento realmente se trata de "edición", si solo se trata de reclutar futuros editores potenciales, tal vez no (y tal vez tampoco necesiten omitir el proceso de confirmación automática ...). — xaosflux Discusión 23:55 5 may 2018 (UTC) [ responder ]
    @ Xaosflux : Siempre recomiendo que el formador de un evento guíe a los participantes a través de un mínimo de tres cosas: (1) crear su página de usuario; (2) escribir y reeditar una oración o dos en su sandbox; (3) agregar una referencia a su sandbox. Incluso con esa experiencia mínima, no pueden dejar de haber logrado 10 ediciones. Pueden hacer la Aventura de Wikipedia por su cuenta más tarde, por supuesto, pero en un evento quiero maximizar la interacción entre el formador y el participante porque así es como aprenden mejor. De todos modos, eché un vistazo a varios de los editores en el grupo confirmado. Hay varios administradores-alts allí, con el permiso presumiblemente autoconcedido. También vi una serie de "rarezas", como un editor que también está confirmado de forma extendida pero no tiene ediciones. Así como un editor que solicitó (y se le concedió) la confirmación el año pasado simplemente para cargar una sola imagen; no ha editado desde entonces. Si el grupo se vaciara de todos los miembros de (digamos) 2017 y anteriores, me pregunto cuántas personas se verían afectadas. Los administradores-alts siempre podrían volver a recibir su cuenta de administrador principal, y aquellos que han realizado 7 ediciones en 7 años probablemente no se den cuenta. ¿Cuáles son las desventajas de ese tipo de limpieza? -- RexxS ( discusión ) 00:28, 6 de mayo de 2018 (UTC) [ responder ]
    Probablemente también haya una buena cantidad de cuentas alternativas que no son administradores. Si alguien reclama una cuenta alternativa y pregunta en WP:PERM, obtiene la bandera; aunque no estoy seguro de por qué la gente se molesta y nunca la usa. — xaosflux Talk 00:40, 6 de mayo de 2018 (UTC) [ responder ]
  75. Fuerte apoyo por las razones expuestas en la publicación original. -- SkyGazer 512 ¿Qué dirás? / ¿Qué hice? 22:58, 6 de mayo de 2018 (UTC) [ responder ]
  76. Apoyo Mi inclinación inicial fue apoyarlo, ya que pensé que esta propuesta sonaba como una obviedad. Antes de opinar, me aseguré de leer las declaraciones en contra y confieso que se plantearon algunos puntos interesantes. Sin embargo, si bien eso me disuadió de considerarla una obviedad, sigo pensando que los argumentos a favor de la propuesta superan con creces las preocupaciones, por lo que estoy aquí expresando mi apoyo. -- S Philbrick (Discusión) 00:54, 7 de mayo de 2018 (UTC) [ responder ]
  77. Apoyar una parte de la situación ACTRIAL que ha sido descuidada durante mucho tiempo... Sadads ( discusión ) 12:38 7 may 2018 (UTC) [ responder ]
  78. Apoyo , aunque desconfío de la parte (3) que permite que se conceda el derecho a usuarios con poca experiencia en edición. ¿Por qué hay gente que coordina eventos de edición si no tiene al menos algo de experiencia? Ivanvector ( Discusión / Ediciones ) 13:36 7 may 2018 (UTC) [ responder ]
  79. Apoyo ya que esto solucionará una de las desventajas de ACTRIAL ya que es importante brindar soporte a los eventos de edición. -- Frmorrison ( discusión ) 15:44 7 may 2018 (UTC) [ responder ]
  80. Soporte Esta es una limpieza de sentido común del riesgo de seguridad creado al otorgarle derechos de creación de cuentas a los coordinadores de divulgación. El requisito de elegibilidad es un poco vago, pero como sucede con la mayoría de las introducciones de derechos de usuario, podemos resolver esto cuando aparece o no un patrón de abuso. TheDragonFire ( discusión ) 11:37 8 may 2018 (UTC) [ responder ]

Oponerse a

  1. Oposición . Expresé mi reacción inicial a continuación, y lo que estoy leyendo en la página de discusión de esta propuesta aumenta aún más mis preocupaciones. El problema aquí es, simplemente, que los nuevos usuarios que llegan de los eventos de divulgación no son diferentes a los nuevos usuarios de cualquier otra fuente: no saben cómo crear artículos que sobrevivan en el espacio principal, debido a que no están familiarizados con nuestras políticas. Mi propia experiencia al aprender políticas sugiere que simplemente leerlas no es necesariamente suficiente para comprender los detalles de su aplicación. En última instancia, hay una razón por la que se eliminan el 80% de los artículos nuevos. Y aunque apoyo tanto el fomento de la actividad entre los recién llegados como la expansión de la enciclopedia, no veo cómo el hecho de ser mordido con una eliminación logra cualquiera de estas cosas. En este punto, simplemente no estoy satisfecho de que los eventos de divulgación actualmente tengan suficiente supervisión para garantizar que las nuevas creaciones (que idealmente deberían hacerse en el borrador o en el espacio de usuario de todos modos) estén a la altura de nuestros estándares. Además, sostengo que si los eventos de divulgación tuvieran este nivel de supervisión, este permiso no sería necesario en absoluto: las coordenadas del evento podrían simplemente mover los borradores aceptables al espacio principal. — Compassionate727  ( T · C ) 15:31, 18 de abril de 2018 (UTC) [ responder ]
    Compassionate727 , creo que los nuevos usuarios que llegan a través de eventos de divulgación son, de hecho, muy diferentes de los nuevos usuarios que llegan a través de cualquier otra fuente. Como dice Rhododendrites : "Eso no quiere decir que no haya todavía muchos problemas, por ejemplo, con la notoriedad y la promoción, sino que es poco probable que alguien que haya decidido asistir a un evento de edición esté editando de mala fe, y la ayuda que recibe disminuye la probabilidad de encontrarse con otros problemas". Como editor que ha facilitado un par de maratones de edición y que hace muchas revisiones de páginas nuevas y la eliminación física de miles de páginas, esa es sin duda la evidencia con la que me he encontrado. La dura realidad es que la razón por la que se eliminan el 80% de los artículos nuevos es que no sólo no cumplen nuestros criterios, sino que la gran mayoría de ellos no tienen absolutamente nada que ver con una enciclopedia, o son puro spam corporativo, troleo, engaños y otra basura. Como revisor de New Page desde noviembre de 2016, frente a la manguera de agua de sentina diaria, probablemente esté muy consciente de esto. Kudpung กุดผึ้ง ( discusión ) 16:21, 18 de abril de 2018 (UTC) [ responder ]
    @ Kudpung : En cierta medida, no entendiste bien mi afirmación: sólo quise decir que son iguales en el sentido de que no están muy familiarizados con las políticas. Y aunque yo diría que, actualmente, el spam corporativo o autobiográfico es la mayor amenaza a la integridad de la enciclopedia, considero que, per cápita, tengo muchas más probabilidades de encontrarme con artículos de buena fe que con temas marginales o poco destacables, que es precisamente el tipo de cosas que esperaría que produjeran los maratones de edición. No digo que no confíe en la buena fe de los usuarios que asisten a eventos de divulgación, pero citaré mi respuesta a estos argumentos a continuación: "No veo cómo el hecho de que los coordinadores muevan al espacio principal artículos que claramente han seleccionado y leído es una carga significativa para ellos. Lo único que veo que puede hacer este permiso es facilitar a los participantes mover artículos al espacio principal sin consultar a su coordinador, y no estoy convencido de que darles la capacidad de hacerlo sea algo bueno". — Compassionate727  ( T · C ) 16:42, 18 de abril de 2018 (UTC) [ responder ]
    @ Compassionate727 : No les vamos a dar un control automático, su trabajo va a ser revisado por un nuevo supervisor de la página en cualquier caso. No veo esto como un problema dado que prácticamente todos los editores de editatones editarán de buena fe. ACTRIAL estaba destinado a detener a los otros tipos de editores nuevos, por lo que tiene sentido una exención para editatones y eventos de divulgación. — Insertcleverphrasehere ( o aquí ) 17:00, 18 de abril de 2018 (UTC) [ responder ]
    @ Insertcleverphrasehere : Me inclino a estar en desacuerdo. Al menos en mi opinión, la prevención de editores de mala fe es sólo uno (aunque importante) de los aspectos que aborda ACREQ. En general, ACREQ tiene como objetivo mejorar la calidad de los artículos en el espacio principal. Lo hace eliminando el flujo de basura con el que hemos estado lidiando en NPP durante años, pero también lo hace impidiendo que los editores nuevos creen artículos completamente por su cuenta (ya que es probable que se eliminen) y, en su lugar, 1) busquen orientación de editores más experimentados o 2) esperen hasta que hayan desarrollado más experiencia. Lo que esta propuesta pretende hacer (en efecto, si no intencionalmente) es eliminar la necesidad de que los editores que participan en eventos de divulgación busquen comentarios específicos para sus artículos antes de colocarlos en el espacio principal, y no creo que ese sea el curso de acción correcto. Esto no ayudará a la enciclopedia, que verá un aumento en la cantidad de artículos que llegan al espacio principal antes de que estén listos (y, por lo tanto, más artículos terminarán en AfD), y tampoco es bueno para los eventos de divulgación, porque el objetivo de ir a uno de esos eventos es recibir esa retroalimentación específica de otros editores. — Compassionate727  ( T · C ) 18:49, 18 de abril de 2018 (UTC) [ responder ]
  2. Oponerse a Per Compassionate727. Si se me permite añadir, esta es una de esas ideas que son geniales en el papel, pero cuando se aplican en el mundo real, nos dejan expuestos al abuso. Piénsenlo, ya que ninguno de nosotros se conoce en persona, ¿qué impide que un usuario baneado permanentemente aparezca, obtenga una cuenta y edite como un calcetín por un tiempo, con el beneficio adicional de un límite ilimitado en sus contribuciones? Me opongo firmemente a esto. ►К Ф Ƽ Ħ◄ 16:08, 18 de abril de 2018 (UTC) [ responder ]
    ¿Qué impide que un usuario baneado permanentemente se registre para obtener una nueva cuenta, realice 10 modificaciones en su página de usuario y espere 10 días? Nada, y requeriría menos esfuerzo que encontrar un evento de divulgación y viajar físicamente hasta él. El derecho temporal de 10 días confirmedque se otorgaría mediante un grupo eventcoordinatores idéntico al que se obtendría de autoconfirmedla forma tradicional. El (noratelimit)derecho, que permite crear más de 6 cuentas desde una única dirección IP en 24 horas, ya se otorga a las personas que afirman ser coordinadores de eventos de divulgación a través del accountcreatorgrupo. Esta propuesta no cambia eso y, en todo caso, es más restrictiva, ya que no permite que los coordinadores de eventos anulen la lista negra de nombres de usuario. -- Ahecht (
    PAGINA DE DISCUSION    ) 16:27 18 abril 2018 (UTC) [ responder ]
    Olvidé hacer ping a KoshVorlon . -- Ahecht (
    PAGINA DE DISCUSION    ) 16:29, 18 de abril de 2018 (UTC)    [ responder ]
    ¿Qué impide que alguien se convierta en administrador de enwiki y commons, que lo bloqueen indefinidamente en ambos, que luego vuelva a obtener derechos de administrador en commons con un calcetín y que lo bloqueen globalmente? G M G talk 19:13, 18 de abril de 2018 (UTC) [ responder ]
    Sin embargo, esta propuesta acorta ese método y ofrece la confirmación automática de inmediato. Al menos con el límite de publicaciones, tenemos una oportunidad de detener a los vándalos y bloquear permanentemente las cuentas antes de que se produzcan demasiados daños, ya que se los puede ver desde el principio, tratando de aumentar su tasa de publicaciones al tomar ciertas acciones <no se muestra en WP:BEANS>.
    Con Wikipedia funcionando correctamente, con todas las partes en funcionamiento (CU, administradores, etc.) los usuarios permanentemente baneados y los usuarios con calcetines pueden ser detectados y desactivados rápidamente. Con este procedimiento, si bien atraeríamos a usuarios de buena fe, también estaríamos extendiendo la alfombra roja para los usuarios permanentemente baneados, etc. ►К Ф Ƽ Ħ◄ 14:05, 19 de abril de 2018 (UTC) [ responder ]
    Entonces, para aclarar: ¿qué en particular en este procedimiento hace que sea más fácil para dichos editores volver a colarse que simplemente registrar una nueva cuenta, hacer 10 ediciones y esperar 4 días? (Descontando por el momento lo que lo hace mucho más difícil : presentarse en realidad en un evento, en lugar de quedarse en casa con la televisión y la cerveza de raíz). -- Elmidae ( discusión · contribs ) 14:27, 19 de abril de 2018 (UTC) [ responder ]
    Prohibición de la cerveza de raíz en los editatones, problema resuelto. Cesdeva ( discusión ) 14:38 19 abr 2018 (UTC) [ responder ]
  3. Oposición No confío en estos "coordinadores de eventos" que tienen una participación limitada en Wikipedia, y conozco a algunos de ellos. El estúpido énfasis de Wikipedia en el número de artículos como unidad de análisis funciona en contra de WP:N . Necesitamos que los editores mejoren los artículos existentes, especialmente considerando que muchos maratones de edición están enfocados en RIGHTGREATWRONGS . No nos beneficiamos ni de los nuevos usuarios ni de los artículos que crearían. Los nuevos editores pueden pasar por AfC. Chris Troutman ( discusión ) 21:13, 21 de abril de 2018 (UTC) [ responder ]
    Un sentimiento curioso, tal vez alguien terminó de escribir Wikipedia mientras yo no estaba mirando. De lo contrario, es difícil comprender una hostilidad tan abierta hacia los nuevos usuarios. Richard Nevell ( discusión ) 21:55, 21 de abril de 2018 (UTC) [ responder ]
    Estoy de acuerdo en que es completamente ilógico medir el valor de Wikipedia por su cantidad de artículos en lugar de por su calidad, pero esa es la política de la WMF. Al igual que tú, Chris , soy muy escéptico con aquellos de WiR que casi no han editado la enciclopedia (uno se pregunta de dónde sacaron esa experiencia), pero como reciben pagos de la WMF o de sus instituciones, hay poco que podamos hacer al respecto. Sin embargo, muchos editatones de divulgación son organizados y entregados por usuarios como RexxS , Pigsonthewing y otros miembros de capítulos en quienes confío implícitamente que saben lo que están haciendo. Tal vez no deberíamos meterlos a todos en el mismo saco. Kudpung กุดผึ้ง ( discusión ) 05:25, 22 de abril de 2018 (UTC) [ responder ]
    Para ser justos con la WMF, están interesados ​​en medir la calidad, motivo por el cual ORES está en desarrollo. Richard Nevell ( discusión ) 10:34 22 abr 2018 (UTC) [ responder ]
    Medición, sí, Richard , pero si sigues de cerca todo lo que han hecho y dicho a lo largo de los años, se hará bastante evidente que su objetivo es la cantidad por encima de la calidad. Es por eso que financian fuertemente WiR, su proyecto de Educación y cualquier otra acción que aumente el número de nuevos artículos. ACTRIAL fue demandado originalmente en 2011 por la comunidad para abordar las preocupaciones de calidad. La WMF se negó a implementarlo por temor a una caída en las nuevas creaciones. Este año se ha demostrado que estaban completamente equivocados, pero en lugar de abordar las necesidades de invertir en mejoras de software para NPP, están considerando AfC, nuevamente con la intención de salvar tantos artículos como sea posible y al diablo con la calidad. Han desarrollado ORES para obtener algo de retroalimentación de la Inteligencia Artificial, pero no parecen tener ninguna intención de convertirlo en una herramienta útil para quienes trabajan en áreas de mantenimiento. Kudpung กุดผึ้ง ( charla ) 20:47, 22 de abril de 2018 (UTC) [ respuesta ]
    @ Kudpung : Como trabajé anteriormente para un capítulo, sé algo de lo que la WMF quiere de sus afiliados. Plantearlo simplemente como cantidad me recuerda la historia del ciego y el elefante. Richard Nevell ( discusión ) 23:23, 22 de abril de 2018 (UTC) [ responder ]
    Precisamente , Richard , lo que quiere la WMF es cantidad, cantidad, cantidad. Se niegan incluso a reconocer que la calidad es parte de la ecuación que hace de Wikipedia una obra de referencia fiable. He pasado horas en reuniones de la vida real discutiendo con ellos sobre ello. La cantidad es el elefante en la habitación (o más precisamente: en el feed de NPP), y es exactamente por eso que ahora tenemos ACREQ. Kudpung กุดผึ้ง ( discusión ) 23:35, 22 de abril de 2018 (UTC) [ responder ]
    Me temo que no lo has entendido bien. En este escenario, el WMF es el elefante. No se trata solo de la cantidad. Entiendo que tu experiencia es diferente, pero estoy seguro de que te das cuenta de que no es toda la historia. Richard Nevell ( discusión ) 23:41 22 abr 2018 (UTC) [ responder ]
    Richard , quizás no lo entendiste bien. WMUK es un capítulo, he pasado varias horas felices en su oficina, no tiene nada que ver con la forma en que la gente de SF piensa y trabaja. Mi experiencia es amplia y prolongada. Luché con ellos durante 6 largos años para conseguir ACTRAl en varias reuniones en todo el planeta, sin mencionar las horas de videoconferencias con ellos y los miles de bytes aquí en en.Wiki. Si te centras en la calidad, bueno, sí, tus artículos (y GA) son excelentes. Kudpung กุดผึ้ง ( discusión ) 23:55, 22 de abril de 2018 (UTC) [ responder ]
    Como dije, sé un poco sobre lo que la WMF quiere de sus afiliados, ya que los capítulos tienen que informar a la Fundación. Ese no es el panorama completo, por supuesto, pero en mi experiencia, la WMF no está interesada únicamente en la cantidad. Puede que no esté de moda defender a la WMF, pero prefiero un poco de equilibrio. No estoy seguro de que esta actitud de campo de batalla contraria que tienes hacia la WMF sea particularmente útil. Richard Nevell ( discusión ) 07:25, 23 de abril de 2018 (UTC) [ responder ]
    @ Kudpung : No estoy criticando a Rexxs ni a Pigsonthewing en absoluto. Mis comentarios son específicos para los organizadores sin experiencia. Si nuestros editores experimentados quieren usar este derecho y el ACC, me parece bien, aunque me pregunto por qué Wikipedia necesita comprar la participación de nuevos editores y el costo de un artículo en el espacio principal. Me opongo a dar este derecho temporalmente a editores que carecen de la experiencia para ser confiables. Puedo nominar todos esos artículos para que se eliminen, de todos modos. Chris Troutman ( discusión ) 19:36, 22 de abril de 2018 (UTC) [ responder ]
    @Chris Troutman : , @Kudpung : .​
    Puede que sea una sugerencia ingenua, pero ¿no podría solucionarse parcialmente con una RfC que defina claramente el umbral que alguien debe alcanzar antes de que se le conceda el puesto de coordinador de eventos? ¿Digamos 500 ediciones en el espacio principal y 25 artículos creados? El punto 3 de esta propuesta de RfC es bastante vago en cuanto a lo que constituye "establecido". Cesdeva ( discusión ) 08:52, 23 de abril de 2018 (UTC) [ responder ]
    No conozco los detalles sobre cómo WMF tiende a implementar este tipo de cosas, pero en otro orden de cosas, ¿quizás sería posible marcar las cuentas nuevas a las que los coordinadores les otorgan el estado de confirmadas? De esta manera, podríamos rastrear la calidad de la creación de contenido hasta los coordinadores asociados y sancionarlos si tienen un desempeño irrazonablemente deficiente en términos de calidad y retención de artículos. — Compassionate727  ( T · C ) 14:31, 23 de abril de 2018 (UTC) [ responder ]
    @ Cesdeva : Sin convertirlo en una burocracia, creo que como comunidad podríamos elaborar una guía que los administradores puedan utilizar al considerar otorgar el derecho. Cualquier usuario que tenga ACC tiene la experiencia suficiente para ser confiable. @ Compassionate727 : Agregar ese tipo de responsabilidad ayudaría mucho a ganar mi confianza. Si se marcaran sus ediciones, podríamos examinarlas y clasificar a los editores que lo obtienen de aquellos que no prestaron atención durante la capacitación y eliminar el derecho, así como despojar al "coordinador de eventos" de su responsabilidad también. Chris Troutman ( discusión ) 16:24, 23 de abril de 2018 (UTC) [ responder ]
  4. Oponerme No entiendo el propósito de este derecho porque no veo nada malo en exigir a los participantes de los eventos que creen artículos en el espacio de borradores. De hecho, creo que es la mejor manera de proceder, para que sean revisados. Natureium ( discusión ) 17:49 25 abr 2018 (UTC) [ responder ]
    @ Natureium , espero poder cambiar tu opinión y tranquilizarte. Estos artículos serán revisados ​​de todos modos, ya que irán al feed de NPP; la confirmación no se controla automáticamente. ACTRIAL/ACPERM se creó para poner un obstáculo a los editores que pasan de largo y que no están aquí para crear una enciclopedia , y no hay razón para que este obstáculo se ponga frente a los editores de buena fe en los eventos de edición. La otra buena razón para confirmar a los participantes de la editatón es eliminar el requisito de un CAPTCHA cada vez que agregan un enlace en una edición (siempre que agregan referencias). Esto es molesto y disruptivo para los nuevos editores que agregan muchas referencias o cuando están jugando con el formato de referencias (requiere un CAPTCHA cada vez). — Insertcleverphrasehere ( o aquí ) 21:57, 25 de abril de 2018 (UTC) [ responder ]
  5. Me opongo a que esto sea independiente y apoyo que sea estándar para AccountCreator. ― Justin ( ko a vf ) ❤ T ☮ C ☺ M ☯ 07:18, 2 de mayo de 2018 (UTC) [ responder ]
  6. Oposición : hay una razón por la que pedimos a la gente que adquiera experiencia antes de ser autoconfirmada y poder crear artículos directamente en el espacio principal. Esa razón no ha desaparecido, por lo que esta propuesta no va a ayudar a la enciclopedia Amisom ( discusión ) 07:31, 2 de mayo de 2018 (UTC) [ responder ]
    @Amisom: - pero seguramente la razón ha desaparecido - el aumento de autoconfirmación (ACTRIAL/ACPERM) fue para salvar a NPP de la avalancha de vandalismo, páginas en blanco y otros fallos rotundos que estaban obstruyendo su evaluación y generando los retrasos. Los participantes de Editathon casi siempre son de buena fe, además de recibir algo de formación y práctica de edición. Así que el vandalismo y los envíos en blanco serán pocos. Las entradas todavía tienen que pasar por NPP, y sin duda algunas no lo lograrán, pero los beneficios para los participantes y los anfitriones no se verían superados por la interrupción de los envíos fallidos (muchas páginas autoconfirmadas también fallan, pero obviamente no lo suficiente como para causar problemas). Nosebagbear ( discusión ) 15:00, 2 de mayo de 2018 (UTC) [ responder ]
    @ Nosebagbear : (a) No estoy seguro de que la prevención de artículos de mala fe sea la única razón para la introducción de la bandera de autoconfirmación. Creo que la prevención de artículos que no cumplen con las políticas (violaciones de BLP, violaciones de WP:N...) por parte de editores inexpertos fue otro propósito. (b) Los participantes de los editatones son, de hecho, "casi siempre" de buena fe, pero como se ha señalado, no hay garantía - y si los eximimos de las restricciones de las nuevas cuentas eso les proporciona un incentivo para no serlo/ para que aquellos que tienen mala fe abusen de los editatones. Pero principalmente (a). Amisom ( discusión ) 19:04, 2 de mayo de 2018 (UTC) [ responder ]
    @Amisom: Sin duda tienes razón en que la reducción de los artículos que infringen las políticas se habría visto como una razón secundaria para parte del consenso global y un efecto secundario agradable para muchos más. Sin embargo, hay un par de razones por las que eso no debería ser suficiente para evitar una excepción limitada. Existe el argumento de que "lo bueno supera a lo malo", que dar a los participantes de Editathon la oportunidad de llevar su trabajo hasta el final para enviarlo fomenta la retención y los ayuda a saber qué hacer cuando están solos (en lugar de, por ejemplo, copiar a través de un editor senior). Además, la autoconfirmación es un límite tan bajo, que el bajo número de ediciones (ya sea 10, o lo que sea el promedio en 4 días) aún dejaría un nivel significativo de incumplimiento de las políticas en comparación con los recién llegados. Yo habría pensado (y no tengo evidencia de esto, pero parece razonable) que supervisar a los editores experimentados conduciría a menos infracciones de políticas en un Editathon que a los recién nombrados AC. Nosebagbear ( discusión ) 19:19 2 may 2018 (UTC) [ responder ]
    Bueno, tendremos que aceptar que no estamos de acuerdo. Amisom ( discusión ) 19:43 2 may 2018 (UTC) [ responder ]
    Creo que no has entendido que no restringimos la creación de artículos a las cuentas confirmadas automáticamente, y no lo hemos hecho desde el principio. Lo restringimos temporalmente durante ACTRIAL y lo restringiremos una vez que se promulgue ACPERM, lo que eliminará la capacidad de larga data de los editores no confirmados de crear artículos. Este nuevo permiso solo restablece la capacidad de los nuevos usuarios en los eventos para crear artículos, por lo que en realidad solo se está volviendo al status quo a largo plazo para ese subconjunto muy pequeño de nuevos editores. Boing! dijo Zebedee ( discusión ) 15:05, 2 de mayo de 2018 (UTC) [ responder ]
    La comunidad ha determinado que la creación de artículos debe estar restringida para las cuentas nuevas. Ese era mi punto. Amisom ( discusión ) 19:06 2 may 2018 (UTC) [ responder ]
    Sí, y parte de ese consenso fue encontrar una manera de no afectar negativamente a los nuevos usuarios en los eventos. El objetivo de ACTRIAL/ACPERM es mantener alejados a los vándalos, idiotas y spammers, no a los editores que reciben orientación en eventos coordinados. Boing! dijo Zebedee ( discusión ) 11:58 3 may 2018 (UTC) [ responder ]
    @ Boing! dijo Zebedee : Decir que WP:ACPERM estableció un consenso para esto no está justificado. Si bien la mayoría de los votos en contra citaron esto como la razón de su oposición, la mayoría de los votos a favor no abordaron esta cuestión. El propósito de esta RfC es establecer el consenso para este cambio. — Compassionate727  ( T · C ) 12:14, 3 de mayo de 2018 (UTC) [ responder ]
    Lo siento, no, no quiero sugerir que ACPERM haya proporcionado consenso para esto específicamente. Todo lo que quiero decir es que parecía haber un claro deseo (de muchos partidarios y opositores) de que los nuevos editores en los eventos mantuvieran su status quo y pudieran crear nuevos artículos, y eso, de hecho, es para lo que sirve esta RFC. Por tus palabras iniciales aquí, pensé que tal vez habías pensado que esta propuesta estaba extendiendo derechos a los nuevos editores en los eventos que no habían tenido antes, pero puedo ver que ese no es el caso. Boing! dijo Zebedee ( discusión ) 12:54, 3 de mayo de 2018 (UTC) [ responder ]

Neutral

Discusión

Actualmente me inclino por oponerme, pero ciertamente puedo convencerme de lo contrario. Mi principal preocupación es que los nuevos usuarios que se incorporen como parte de los eventos de divulgación que creen artículos en el espacio principal se encontrarán con el mismo problema que la mayoría de los demás usuarios: no están familiarizados con las pautas y políticas y, por lo tanto, no pueden crear artículos que sobrevivan a la eliminación. ¿Cómo funcionan los eventos de divulgación? ¿Hay personas dentro de esos eventos que se aseguren de que los usuarios sepan lo que están haciendo o que supervisen las contribuciones para asegurarse de que no sean un problema? (De hecho, ¿hay alguna página en algún lugar que contenga información sobre estos eventos en general? No pude encontrar ninguna). — Compassionate727  ( T · C ) 15:06, 18 de abril de 2018 (UTC) [ responder ]

Por cierto, estoy de acuerdo. He asistido a ediciones en Estados Unidos y los coordinadores siempre han sido muy amables al decirle a la gente que cree cosas en su sandbox o en borrador. Lo positivo aquí, incluso para ese método, es que darles la confirmación también les permite moverla ellos mismos, lo que parece ser parte de la objeción. TonyBallioni ( discusión ) 15:20 18 abr 2018 (UTC) [ responder ]
Todos los eventos de edición presenciales a los que he asistido (muchos) han comenzado con una sesión de información o capacitación grupal o han tenido dicha capacitación disponible (a veces en una sala lateral dedicada). También suelen asistir al menos un editor experimentado (ha habido excepciones, pero en este caso damos por sentado que la persona que obtiene y usa este derecho de usuario es un editor experimentado). Apoyaría aumentar los requisitos más allá de los que exigimos al creador de cuentas, y apoyaría que se exija que la persona que usa este derecho de usuario esté físicamente presente con los usuarios a los que se les otorga el estado confirmado. En última instancia, las personas que asisten a estos eventos no están allí para vandalizar, crear páginas de ataque y casi siempre han recibido algunas instrucciones básicas sobre las mejores prácticas. También cuentan con uno o más editores experimentados para ayudar a evitar otros errores comunes. Eso no quiere decir que no haya muchos problemas con, por ejemplo, la notoriedad y la promoción, solo que es poco probable que alguien que haya decidido asistir a un evento de edición edite de mala fe, y la ayuda que recibe disminuye la probabilidad de encontrarse con otros problemas.Las rododendritas hablan\\ 15:29, 18 de abril de 2018 (UTC) [ responder ]
El requisito de autoconfirmación, que es un estándar MUY bajo para pasar, está establecido para prevenir el vandalismo desde el coche. Aumenta el esfuerzo requerido para publicar el primer artículo, ya que el editor tiene que decidir si vale la pena esperar 4 días para publicarlo. Sin embargo, yo diría que tener que viajar físicamente a un evento de divulgación requiere tanto esfuerzo, si no más, que simplemente esperar 10 4 días. ¿Es posible que algunas de las pocas personas a las que un "coordinador de eventos" les otorga el estado de "confirmadas" envíen un artículo inapropiado o incluso vandálico? Seguro, pero también lo harán algunas de las personas que obtienen el estado de "autoconfirmadas" de la manera tradicional. El impacto adicional de esta propuesta en NPP será insignificante. -- Ahecht (
PAGINA DE DISCUSION) 15:40, 18 de abril de 2018 (UTC) [ responder ]
No me preocupa tanto el impacto de los eventos de divulgación en NPP en sí (no son lo suficientemente comunes como para marcar una diferencia significativa), ni espero que los usuarios que asisten a dichos eventos editen de mala fe. Mi preocupación es lo que todos aparentemente acordamos que es verdad: que los nuevos usuarios, independientemente de su motivo, no necesariamente tienen la experiencia suficiente para hacer contribuciones aceptables al espacio principal. Y si lo que estoy leyendo arriba sobre recibir ayuda de los coordinadores de eventos es cierto (y no tengo ninguna razón para creer que no lo sea), entonces no veo cómo el hecho de que los coordinadores muevan artículos que claramente han extraído y leído al espacio principal es una carga significativa para ellos. Lo único que puedo ver que hace este permiso es facilitar que los participantes muevan artículos al espacio principal sin consultar a su coordinador, y no estoy convencido de que darles la capacidad de hacerlo sea algo bueno. — Compassionate727  ( T · C ) 15:53, 18 de abril de 2018 (UTC) [ responder ]
Además, Ahecht , debido a que cometiste este error en un par de lugares, debo señalar que el período de tiempo requerido para la confirmación automática es de 4 días, no de 10. :) — Compassionate727  ( T · C ) 19:13, 18 de abril de 2018 (UTC) [ responder ]
  • No estoy seguro de para qué hay datos, pero el punto de comparación para los fines de esta propuesta debería ser los usuarios autoconfirmados, no todos los usuarios nuevos. En otras palabras, estaríamos otorgando el estado de confirmado a un usuario nuevo; ¿esos usuarios confirmados tendrán más, menos o la misma cantidad de problemas que un usuario autoconfirmado? Anecdóticamente, no puedo imaginar que sean más . Parece probable que sean menos, pero independientemente de si son los mismos o menos, no hay razón para no seguir adelante.Las rododendritas hablan\\ 16:06, 18 de abril de 2018 (UTC) [ responder ]
La Fundación Wikimedia financia presentaciones de eventos, pero no financia la administración. Esto significa que no alientan a la comunidad Wikimedia a recopilar el tipo de datos que responderían a esta pregunta. Me gustaría mucho tener estos datos, pero cuando el tiempo y los recursos son limitados y el flujo de fondos alienta otras prioridades, eso significa que estos datos o bien no existen o cuando existen, casi nadie es capaz de procesarlos. El mejor conjunto de datos es el de los informes de clase de la Fundación Wiki Education y su instancia relacionada del panel de control fuera de sus programas. Consulte meta:Panel de control de programas y eventos para obtener la herramienta de recopilación de datos. Personalmente, puedo dar fe de que he utilizado esta herramienta más de 100 veces y he visto constantemente buenos resultados en cada reunión con usuarios totalmente nuevos. Muchas otras personas informan lo mismo. Cuando alguien viene a una reunión durante 2 horas con la intención de editar wiki, tiene una experiencia que es diferente a la de sentarse solo en casa frente a una computadora sin tener una conversación en vivo. No tengo dudas de que los programas producen contribuciones de mayor calidad en tiempos más cortos que las primeras experiencias en línea típicas. Blue Rasberry (discusión) 19:03 18 abr 2018 (UTC) [ responder ]
@Pythoncoder : No creo que haya estadísticas globales sobre esto, pero puedes hacer algunas aproximaciones a partir de las métricas de Art+Feminism de marzo. Puedes ver en la página de métricas de nuestro Dashboard que creamos un poco más de 3000 artículos (esto no incluye los ~400 adicionales de WiR, que se rastrean en una reunión). Puedes ver en la página de alertas que alrededor de ~50 artículos fueron marcados para su eliminación a través de Speedy, Prod o AfD. De esos ~50, tal vez ~30 fueron realmente eliminados. Entonces 30/3000 = 1%. Se eliminaron el uno por ciento de todos los artículos nuevos. Eso es bastante diferente de la tasa de eliminación del 80% que se discutió en todo el artículo. Espero que ayude a poner en contexto la calidad de lo que sucede en eventos como el nuestro. -- Theredproject ( discusión ) 22:19, 29 de abril de 2018 (UTC) [ responder ]
  • Creo que esto nos lleva a un problema con esta propuesta: que los casos de uso no están definidos tan claramente. Si es de hecho para eventos de divulgación, entonces "programas" me parece demasiado amplio. "Evento" connota algún tipo de participación fuera de la wiki (y si no es así, parece que debería), mientras que parece más difícil definir "programa" con tanta facilidad. Si vamos a extender esto para que se aplique a cualquier "programa", entonces también podríamos replantear el derecho del usuario para que sea simplemente una forma para que los no administradores experimentados y comprometidos otorguen el estado confirmado a los nuevos editores, independientemente del contexto. En ese sentido, se trata más de desagregar herramientas que de algo específico de la divulgación. Probablemente apoyaría cualquiera de las dos, pero creo que es importante hablar de qué es exactamente esto, ya que no creo que todo el mundo apoye lo último.Las rododendritas hablan\\ 19:59, 18 de abril de 2018 (UTC) [ responder ]
  • Estaba usando el nombre que Kaldari usó en una propuesta anterior. Entiendo los puntos que todos ustedes están planteando, pero también apoyo un nombre más corto, y coordinador de programa suena como un puesto de personal de WMF. En términos de uso, traté de aplicar pautas generales (no teníamos ninguna la última vez que se propuso esto, y estas fueron las que obtuvieron consenso en la página de discusión). Mi opinión sobre cualquier RfC importante para un problema de política o de todo el sitio es que los ajustes apropiados se pueden hacer inmediatamente después de la RfC en función de la discusión y el sentido común para las cosas no polémicas. Así es como terminan la mayoría de estas discusiones, y no creo que debamos profundizar demasiado en los detalles aquí más allá de una estructura básica, limitaciones técnicas y pautas básicas para que los administradores otorguen y usen, que es lo que tenemos aquí. Las cosas se pueden ajustar y expandir más tarde. TonyBallioni ( discusión ) 20:04, 18 de abril de 2018 (UTC) [ responder ]
  • Además, en serio, el nombre no es el fin del mundo. patrollersignifica revisor, reviewersignifica revisor de PC y autopatrolledsignificaba revisor automático, pero ya lo hemos aclarado, excepto que no, no lo hemos hecho. Eso no entra en el tema de sysop vs. admin. Coordinador de eventos es lo suficientemente largo, podemos permitirnos ser un poco menos precisos aquí. ~ Amory ( u • t • c ) 01:54, 19 de abril de 2018 (UTC) [ responder ]

Relación con los derechos de los usuarios de la extensión educativa

La propuesta actual es un derecho de usuario que permitiría a los usuarios que coordinan programas y eventos ayudar a los nuevos usuarios a publicar sus artículos. Esta es una respuesta a la reciente adopción de WP:ACTRIAL .

Sin relación con la adopción de ACTRIAL en marzo de 2018, también está la descontinuación en marzo de 2018 de la extensión educativa de Wikimedia, que era una extensión de software de 2011 y un conjunto de derechos de usuario asociados con la divulgación en las aulas y también en eventos. Aquí se encuentra la documentación relevante.

Se ha debatido durante años sobre lo que los wikipedistas que se dedican a la divulgación educativa deberían y no deberían hacer. La discusión equivale a cientos de páginas de texto impreso en papel. Los usuarios que realizaron actividades de divulgación en este programa obtuvieron derechos de usuario denominados "embajador del campus", pensado para personas que irían en persona a las escuelas; "embajador en línea", pensado para personas que apoyarían programas y eventos en línea sin presentarse en persona; y "coordinador del curso", pensado para usuarios que podrían conceder los otros dos derechos de usuario a cualquier usuario de Wikipedia a su discreción de acuerdo con algunas reglas simples. Yo fui coordinador del curso hasta este mes y he realizado documentación para actividades de divulgación con el Programa Educativo de Wikipedia, Wiki NYC y muchos otros modelos de actividades de divulgación en persona.

La desaprobación de la extensión de software del Programa Educativo se debió a un software muy desactualizado, la llegada de un software equivalente más nuevo y mejor en el panel meta:Programas y Eventos, y una tendencia social a fusionar las prácticas de extensión y la capacitación de nuevos usuarios independientemente de si se trata de clases, eventos únicos, campañas a más largo plazo u otras situaciones de capacitación.

Comparto todo esto como contexto a una propuesta adicional que tengo para la “propuesta de coordinador de eventos”.

Propuesta: la documentación para la divulgación que se aplicó a los derechos de usuario de educación 2011-2018, y que se aplica a los usuarios del panel de Programas y eventos, también debería aplicarse a cualquiera que obtenga este derecho de usuario. Este derecho de usuario no es una idea completamente nueva, sino que en realidad es la convergencia de muchas ideas previamente separadas. Tony Ballioni está en la cresta de la ola del espíritu de la época con esta propuesta. Con la necesidad de descontinuar el software, corríamos el riesgo de perder parte de la infraestructura social, pero si este derecho de usuario se convierte en el legado de los derechos de usuario de divulgación, entonces podemos tomar todas las lecciones aprendidas, los argumentos sobre los problemas y la documentación desarrollada sobre los derechos de usuario de divulgación anteriores y aplicarlos aquí para darle una gran ventaja a este derecho de usuario. No estoy pidiendo que nadie acepte cada bit de documentación y política del antiguo programa educativo, pero las similitudes son tan grandes que tampoco quisiera que nadie dejara de reconocer que había un programa de divulgación anterior con derechos de usuario y años de experiencia y discusión que podrían demostrar cómo y cómo no administrar con éxito este derecho de usuario y apoyar a cualquiera que lo reciba. Blue Rasberry (discusión) 02:15 19 abr 2018 (UTC) [ responder ]

Relación con los derechos del creador de la cuenta

Los coordinadores de eventos se beneficiarían al obtener este derecho de usuario para que los nuevos usuarios puedan publicar nuevos artículos.

Otra cosa que necesitan los coordinadores de eventos es la capacidad de ayudar a los nuevos usuarios a registrar cuentas de Wikipedia. Existe una restricción para crear más de 6 nuevas cuentas de Wikipedia en una dirección IP en 24 horas. Normalmente, en los eventos hay muchas personas en una sala con una dirección IP que intentan registrar cuentas. Para que todos se registren, una estrategia común es que el coordinador del evento tenga derechos de usuario de Wikipedia:Creador de cuentas , lo que permite a esa persona crear cuentas de Wikimedia para todos los asistentes al evento.

Menciono esto porque probablemente todos los que obtengan este derecho de usuario de "coordinador de eventos" también necesitarán el derecho de usuario de "creador de cuentas". En el caso de la antigua extensión educativa, había una regla que establecía que cualquiera que tuviera un derecho de usuario de extensión educativa también podía tener el derecho de usuario de "creador de cuentas". Esto puede ser apropiado o no ahora, pero sea cual sea el caso, necesitamos una regla al respecto para que no sea una molestia continua para los coordinadores de eventos obtener todo el apoyo que necesitan para organizar un evento. Estas son algunas formas en que esto podría suceder:

  1. El derecho de usuario "coordinador de eventos" viene incluido con el derecho de usuario "creador de cuenta".
  2. El derecho de usuario "coordinador de eventos" viene junto con una variante del derecho de "creador de cuentas" que permite crear cuentas adicionales, pero sin todos los poderes adicionales. El derecho de "creador de cuentas" tiene algunas capacidades extrañas que son vulnerabilidades de seguridad y que solo utilizan los usuarios avanzados. Creo que hay consenso en permitir libremente que usuarios totalmente nuevos obtengan un derecho de usuario para crear más cuentas. No hay ninguna razón para que los usuarios nuevos tengan todos los poderes del derecho de usuario actual de "creador de cuentas".
  3. Obtener el "coordinador de eventos" significa aprobación predeterminada en las solicitudes de "creador de cuenta", salvo una excepción inusual
  4. Alternativamente, tal vez obtener el título "creador de cuenta" otorgue derechos de usuario a "coordinador de eventos".

De alguna manera, estas dos ideas están relacionadas. Me cuesta articular lo que debería suceder, pero sé que muchas personas que solicitan un derecho de usuario querrán los privilegios del otro. Blue Rasberry (discusión) 02:26 19 abr 2018 (UTC) [ responder ]

Hola @TonyBallioni y @Bluerasberry : tras una rápida lectura de lo anterior, los objetivos de crear este nuevo grupo de acceso de usuarios son :

(1) Permitir que los miembros puedan crear cuentas que excedan el límite de velocidad

Esto se puede lograr a través del (noratelimit)permiso subyacente.
En realidad, sería preferible reemplazar esto en el futuro con un permiso aún no creado "noratelimit-account", pero es lo que tenemos que usar por ahora. Existe una consideración de seguridad con "noratelimit" que puede afectar otras cosas, no quiero detallarlas todas, pero el uso indebido sería motivo de revocación y bloqueo por interrupción.

(2) poder agregar (confirmed) acceso a otra cuenta.

Esto no es un "permiso", sino una "configuración" que se puede implementar fácilmente.
Nota: actualmente no hay un medio técnico disponible para que esto sea solo para "subvenciones temporales", pero ciertamente podemos tener una "regla" para esto.

Alguien PODRÍA tener acceso de "coordinador de eventos" y de "creador de cuentas", pero no lo necesitaría para muchos de los casos de uso. La diferencia notable: los creadores de cuentas pueden anular todo tipo de colisiones de nombres, durante un evento sería mejor evitar esto y hacer que los asistentes elijan un nuevo ID de usuario; los creadores de cuentas no pueden confirmar usuarios. En el caso de uso general "Estoy ejecutando un evento el día del mes", las nuevas configuraciones deberían ser todo lo que alguien necesita y deberían eliminarse cuando ya no las necesite. En mi opinión, si alguien está ejecutando eventos como todos los meses, debería conservar el acceso en lugar de volver a solicitarlo constantemente hasta el momento en que deje de usarlo continuamente. ¿Espero que esto ayude? — xaosflux Talk 02:53, 19 de abril de 2018 (UTC) [ responder ]

Parece que está resuelto . Vale, me equivoqué. La propuesta original previó y abordó esta inquietud. No veo la necesidad de solicitar que se considere más el tema. Me equivoqué y fui ignorante al plantear esta inquietud, que en realidad parece resuelta. 17:18, 20 de abril de 2018 (UTC)

"No nos beneficiamos ni de los nuevos usuarios ni de los artículos que ellos crearían". Es un fuerte candidato a la frase más idiota que alguien haya dicho en Wikipedia, jamás. Andy Mabbett ( Pigsonthewing ); Habla con Andy ; Ediciones de Andy 17:34, 1 de mayo de 2018 (UTC) [ responder ]

@ Pigsonthewing : Probablemente sea de buena educación hacer un ping a la persona a la que estás citando. Además, intenta sangrar tu comentario en el hilo correcto. Cesdeva ( discusión ) 18:41, 1 de mayo de 2018 (UTC) [ responder ]
@ Cesdeva : En las convocatorias de propuestas se considera de buena educación no saturar la votación con discusiones en cadena. Por eso tenemos una sección titulada " Discusión ". El comentario de Andy es un hilo nuevo en la sección de discusión y, independientemente de lo apropiado que sea que lo haya hecho, en realidad está sangrado con precisión y en el lugar correcto. -- RexxS ( discusión ) 21:21, 1 de mayo de 2018 (UTC) [ responder ]
No existe riesgo de "obstruir" la sección de votación en contra en esta convocatoria de propuestas; de la convocatoria de propuestas de ACTRIAL se desprende claramente que habría poca oposición a esta propuesta. Además, esta convocatoria de propuestas ha estado prácticamente estancada durante un tiempo.
Ya existe un contexto establecido en otro hilo, y ese es el lugar más probable para que el editor citado note la respuesta.
Todo el mundo puede discernir quién está siendo citado, entonces ¿por qué no es apropiado que el autor de la publicación informe al editor al respecto?
Tal vez lo hayan hecho por medios no públicos, pero desde aquí todo parece un poco encubierto, lo cual es decepcionante.
En realidad, estoy de acuerdo con el sentimiento de lo que dijo Andy Mabbett . Eso es todo lo que tengo que decir al respecto. Saludos cordiales, Cesdeva ( discusión ) 22:26 1 may 2018 (UTC) [ responder ]

Agrupamiento en accountcreator

Probablemente valga la pena aclarar si sería mejor agrupar la capacidad de otorgar confirmeden el grupo accountcreator , en lugar de tener un grupo separado para event Coordinator . Las ventajas de hacer eso incluirían no aumentar la cantidad de grupos de permisos desagrupados de sysop , y quizás otras que no se me han ocurrido hasta ahora. Sin embargo, las desventajas serían que a veces podríamos estar entregando el estado de accountcreator a organizadores de eventos que podemos sentir que tienen poca experiencia en el manejo de permisos. Desafortunadamente, accountcreator contiene otras habilidades que probablemente querría establecer un estándar más alto para otorgar. Tanto el indicador 'override-antispoof' como el indicador ' tboverride-account ' rara vez son necesarios para los organizadores de eventos, pero están agrupados con accountcreator . En otras palabras, hay un rango de experiencia wiki de editores en la que no me preocuparía otorgar event Coordinator donde tendría reservas sobre otorgar el mismo editor accountcreator , principalmente por la posibilidad de mal uso accidental.

Ahora bien, puede ser que no me preocupe por nada y que, de todos modos, se establezca un estándar razonablemente alto para otorgar el privilegio de coordinador de eventos . Si es así, mi preocupación desaparece. Pero sospecho que querremos ser más liberales al otorgar (y retirar) este nuevo derecho de lo que tradicionalmente hemos sido (o deberíamos haber sido) con el de creador de cuentas . ¿Qué piensan los demás? -- RexxS ( discusión ) 15:59, 2 de mayo de 2018 (UTC) [ responder ]

Estoy de acuerdo. No hay ninguna razón por la que los coordinadores de eventos deban haber obtenido el nivel de experiencia y confianza requeridos para "override-antispoof" y " tboverride-account ". Por el contrario, si bien el permiso del coordinador de eventos en la mayoría de los casos se otorgaría temporalmente durante la duración de un evento, no hay ninguna razón por la que los creadores de cuentas deban tener la capacidad permanente de otorgar el estado confirmado. -- Ahecht (
PAGINA DE DISCUSION) 17:30, 2 de mayo de 2018 (UTC) [ responder ]
Creo que el listón para el puesto de coordinador de eventos puede ser bastante bajo, por lo que probablemente sea mejor mantenerlos separados. Tengo la impresión de que hay dos tipos de coordinadores de eventos. Aquellos con bastante experiencia, que deberían estar bien, y aquellos que no la tienen, y cuya competencia puede estar abierta a dudas. Si la cagan, sería apropiado relevarlos del puesto hasta que hayan demostrado que pueden hacerlo de manera competente, pero según tengo entendido, es probable que el permiso se dé a algunas personas sin mucha idea, y cuanto menos puedan romper, mejor. Estoy a favor de darle a las personas las herramientas que necesitan . · · · Peter (Southwood) (discusión) : 18:38 2 may 2018 (UTC) [ responder ]
La discusión anterior está cerrada. No la modifique. Los comentarios posteriores deben realizarse en la página de discusión correspondiente. No se deben realizar más modificaciones a esta discusión.