Wikipedia:Café/Archivo/Políticas/Actual

Café: Políticas

En esta sección del Café de Wikipedia discutimos nuestras políticas, tanto para crear nuevas, modificar las actuales o eliminarlas. Para responder en un tema ya abierto, usa el enlace [editar] que se encuentra junto al título del apartado. Puedes iniciar un nuevo tema, o vigilar esta página para enterarte de sus cambios. Trata a los demás con respeto, especialmente a los recién llegados, y recuerda siempre presumir buena fe. Por favor, recuerda firmar usando cuatro virgulillas, así: ~~~~. Archivo del Café · Archivo temático del Café · Archivo de Políticas

Café
Noticias	[+]
Políticas	[+]
Técnica	[+]
Propuestas	[+]
Ayuda	[+]
Miscelánea	[+]
Ver todos
Temático

	Esta página es archivada automáticamente. (info)
	Parámetros del archivado: Lugar: Wikipedia:Café/Portal/Archivo/Políticas/AAAA/MM Días a mantener: 14 Avisar al archivar: Sí Estrategia: Firma más reciente en la sección Mantener caja de archivos: No

Páginas nuevas

Propongo restringir solo a los usuarios autoconfirmados hacer artículos ya que las direcciones ip y los usuarios nuevos violan mucho las políticas y también para que en caso de estar registrado puedas orientarte sobre como crer artículos. Ignacio2403 | ¿Hablamos? 23:12 18 jun 2018 (UTC)

Buena idea, es un poco confuso saber si leerán los mensajes en su discusión, aunque hay muchas IPs que se conocen muy bien las normas y el manual de estilo y ninguno va a apoyar una medida que restringa la libertad colectiva en Wikipedia. MONUMENTA Discusión 00:23 19 jun 2018 (UTC)

No creo que sea buena idea. Hay personas que no desean utilizar un usuario para crear artículos, y no podemos obligarlos a que lo hagan. La solución es patrullando más las páginas nuevas, no restringiendo su creación.--Santiago₁₄₂₈₅₇ 01:58 19 jun 2018 (UTC)

Esto se ha debatido muchas veces y siempre se ha rechazado. Lo cierto es que la mayoría de las IP ayudan y no se dedican al vandalismo. --Saludos. Ganímedes 16:37 19 jun 2018 (UTC)

Ya lo hemos debatido ad infitum. Una gran parte, una muy grande, crea contenido y ediciones válidas. Recordemos que esto es la Enciclopedia libre. Si restringimos el uso a un grupo de usuarios no vamos a crecer mucho. --Geom (discusión) 17:28 19 jun 2018 (UTC)

•  En contra, para eso están los patrulleros y los bots. Muchos usuarios anónimos crean o transfieren artículos de buena fe, y también construyen una buena parte de lo que es Wikipedia. -- Davod (desquítense n_n) 19:29 25 jun 2018 (UTC)

No me parece muy práctico, y ¿donde quedarían principios como el de la buena fé? --Леон Поланко говорит вам и слушает вас 11:50 5 jul 2018 (UTC)

Invitación a vigilar página de política oficial

Estimados compañeros wikipedistas, al parecer hay ciertas secciones de Wikipedia que no tienen suficiente vigilancia, como Wikipedia:Revalidación de bibliotecarios/Texto. La página contiene un texto que después se transcluye en la página de la política oficial, quizás por eso muchos no la tiene en seguimiento. Sucede que durante más de 20 horas un usuario, quizás un novato en estos asuntos, que no sabe que las políticas se modifican discutiéndolas y alcanzando consensos o mediante una votación, introdujo un texto: [1], y si yo no pasaba por allí ahora seguía el despropósito. Saludos. --IIM 78 (discusión) 13:51 22 jun 2018 (UTC)

Estimado @IIM 78:, la edición la hizo el bibliotecario Ezarate (disc. · contr. · bloq.), además ha puesto algo que es correcto, que se tiene que avisar al bibliotecario cuando se inicia el proceso de revalidación. Saludos, --Chico⁵¹² 14:30 22 jun 2018 (UTC)

@IIM 78: Yo vigilo bastantes plantillas y políticas que han sido atacadas bastantes veces y cuando he visto tu mensaje me he preocupado... Y cuando lo compruebo me encuentro con esto. Si con "durante más de 20 horas un usuario, quizás un novato en estos asuntos, que no sabe que las políticas se modifican discutiéndolas y alcanzando consensos o mediante una votación" pretendías hacer una gracia, no tiene la más mínima. Puedes venir a plantear el posible problema o sugerencias al café, pero sin sarcasmos, ironías.

Además no creo que añadir en el texto algo tan obvio como que hay que avisar al posible afectado en una intervención, y que es algo que prácticamente todas las políticas o plantillas de mantenimiento incluyen sea necesaria una votación. ¿Crees de verdad que se necesita consenso general para un añadido tan simple? Cómo avisar al propio "novato" que estan hablando de él en un hilo del café. Es mera y simple cortesía. --Geom (discusión) 14:36 22 jun 2018 (UTC)

Yo he visto muchas veces que "colar" este tipo de ediciones "insignificantes" ha traído importantes problemas en la aplicación de políticas. Esta inocente cláusula podría hacer que futuros procesos fueran nulos, tal como siempre soñó Ezarate. Pero aquí no procedemos a modificar políticas por los sueños de alguien, aunque sea bibliotecario. --IIM 78 (discusión) 14:44 22 jun 2018 (UTC)

Pero que problemas puede traer agregar una frase "avisar a bibliotecario", tampoco entiendo como esa frase podría hacer nulos los procesos. Explica bien tu postura que no la entiendo. --Chico⁵¹² 14:47 22 jun 2018 (UTC)

Curiosamente yo vi ese cambio de Ezarate antes de la intervención de IIM 78, y no le di importancia pues es de sentido común y era algo que se estaba tratando entre varios usuarios en la búsqueda de avales para la RECAB activa. Sin embargo sí le doy importancia a los sorprendentes requisitos de esta comunidad, donde todavía hay novatos de diez años de antigüedad... -- Leoncastro (discusión) 14:49 22 jun 2018 (UTC)

¿A ver? ¿Cuántos usuarios eran los que hablaban del asunto? ¿Y cuántos se mostraron a favor? Y si todavía se estaba discutiendo ¿no sería sabotaje cambiar la norma sin antes llegar a consenso? De cualquier manera he dejado una denuncia en el TAB [2] para ver qué nos dicen nuestros bendecidos que se puede hacer y qué no se puede hacer. --IIM 78 (discusión) 15:04 22 jun 2018 (UTC)

Una duda IIM 78, ¿te parece bien iniciar una búsqueda de avales sin notificar al usuario implicado? -- Leoncastro (discusión) 15:39 22 jun 2018 (UTC)

Pues bien ya que quiere un consenso real, abriré un sub-hilo. Saludos. --Chico⁵¹² 15:18 22 jun 2018 (UTC)

Consenso para agregar texto en la política de revalidación

Abro este sub-hilo para buscar consenso sobre los últimos cambios realizados por Esteban, ¿estan de acuerdo al cambio?, por mi parte estoy  A favor de los cambios realizados por Esteban, por que es importante avisar de los procesos a las personas que están implicadas. --Chico⁵¹² 15:18 22 jun 2018 (UTC)

Recién preguntaste por qué es grave esto que parece ser de sentido común. El asunto es sencillo: alguien abre una RECAB, se olvida de avisar en la PU del bibliotecario, y después alguien (quizás el mismo autor de la modificación de la política [3] grita "¡Nulo!, ¡Nulo!" [4] [5], y así seguimos teniendo a bibliotecarios de los que no tenemos la seguridad de que sigan siendo apoyados por la comunidad, después de presuntos malos desempeños.

Es una modificación importante y no se desprende del sentido común, esto no es un tribunal y no se puede aplicar el principio de derecho de defensa. Además no es que ahora la politica diga que esto se haga a espaldas del bibliotecario, dado que se publica el inicio del proceso en el café. --IIM 78 (discusión) 15:21 22 jun 2018 (UTC)

Esto es solo simple, por cortesía se debe avisar del proceso al bibliotecario en su discusión.Y el avisarle no convierte a Wikipedia en un tribunal, simplemente como reitero, es pro cortesía y sentido común. --Chico⁵¹² 15:29 22 jun 2018 (UTC)

Raro pensamiento el de que la cortesía debe surgir de una norma de cumplimiento obligatorio. El que sea cortés que le avise al bibliotecario, y punto. No creo que existan riesgos de que no se enteren de procesos que son anunciados en el Café. En cambio sí existe riesgo de que en un futuro se alegue nulidad por este "detalle de sentido común y cordialidad" que quieren meter, ya que también ha pasado antes. --IIM 78 (discusión) 15:34 22 jun 2018 (UTC)

Entonces que cambios propones en el texto de Esteban, para algunos esta bien pero como tu no estas de acuerdo cual es tu propuesta. --Chico⁵¹² 15:37 22 jun 2018 (UTC)

•  A favor de que incorporar en la política las notificaciones a los implicados, más que nada por respeto, aunque no sea vinculante para su anulación —como supongo que tampoco se anulará si no se cumple la obligación de que «deben existir motivos sólidos que sustenten la petición, y un sector importante de la comunidad debe estar de acuerdo con ellos», pues no se sabe a priori si “un sector importante de la comunidad” está de acuerdo con los motivos. -- Leoncastro (discusión) 15:39 22 jun 2018 (UTC)
•  A favor, lógicamente, usando, con permiso, el mismo argumento de Leoncastro --Geom (discusión) 15:42 22 jun 2018 (UTC)

Tu extraña inocencia me cae simpática, Chico512 (disc. · contr. · bloq.) Nadie está obligado aquí a adoptar soluciones de compromiso. Mi propuesta es que no se cambie nada de nada, porque las razones para introducir ese cambio no lo justifican (el bibliotecario se enterará igual por el anuncio en el Café), y la cláusula podrá desvirtuar futuros procesos. Compañeros, nosotros sabemos perfectamente qué tipos de personas son las que ante los procesos alegan nulidades: las que no se quieren someter a los mismos, las que sienten que están más allá de las normas.

Pero veo que quieren convertir esto en una votación, y en vez de sumar argumentos suman voluntades. Patético. --IIM 78 (discusión) 15:48 22 jun 2018 (UTC)

@IIM 78, yo he argumentado. Te rogaría que dirijas tus calificativos directamente a las personas a quienes los dirijas, en caso contrario se considera que lo diriges a la comunidad. Y por tanto ruego también que borres o taches la última palabra de tu comentario, y que evites resúmenes de edición con la misma. -- Leoncastro (discusión) 16:01 22 jun 2018 (UTC)

•  A favor como autor de la norma y por el hecho de que las notificaciones pueden ser desactivadas y el implicado no enterarse del proceso Esteban (discusión) 16:30 22 jun 2018 (UTC)

 En contra de hacerlo ahora, cuando hay abierta una recogida de avales: no se cambian las reglas de juego con el partido empezado. Más adelante, se puede hablar.--Enrique Cordero (discusión) 16:57 22 jun 2018 (UTC)

@Enrique Cordero, se sobreentiende que este cambio no es de carácter retroactivo y que la revalidación en curso ya fue abierta antes del mismo, y como tal no afecta una cosa a la otra. Precisamente es por causa de la búsqueda de avales en curso que se ha detectado este vacío en la norma. No he visto proposición ni razonamiento alguno para invalidar la consulta actual de avales, salvo los supuestos en la argumentación o queja de IIM 78. -- Leoncastro (discusión) 17:12 22 jun 2018 (UTC)

(conflicto de edición)

¿Un bibliotecario que no se entera de un proceso que se anuncia en el Café? Suena a excusa todo esto. En este proceso no es esencial que el bibliotecario se entere, solo que la comunidad se exprese. No es un juicio. No somos un tribunal. El bibliotecario no tiene "derecho de defensa", solo tiene derecho a intervenir como cualquier otro. --IIM 78 (discusión) 17:11 22 jun 2018 (UTC)

Por otro lado Enrique Cordero, ¿estarías de acuerdo en realizar la modificación al término del proceso en curso, sin necesidad de rearmar una nueva consulta de consenso? Lo pregunto básicamente para ahorrar un segundo proceso si se puede resolver ahora, aunque sea de un modo aplazado. -- Leoncastro (discusión) 17:17 22 jun 2018 (UTC)

(CdE)  A favor, es correcto y razonable avisar estas cosas, pero estoy totalmente  En contra de que se aplique retroactivamente y en ningún caso me parecería un motivo de anulación de un proceso. Al respecto, totalmente de acuerdo con Enrique Cordero y Leoncastro Mar del Sur (discusión) 17:19 22 jun 2018 (UTC)

 A favor notificar a alguien de que ha sido denunciado es fundamental. Plazamar (discusión) 17:38 22 jun 2018 (UTC)

Comentario, pues considero también que si se llegase a colocar ese texto, la omisión del aviso al bibliotecario no debería ser causal de anulación total del proceso como es el temor de IIM 78, en todo caso a final se podría agregar "...sin embargo la omisión del aviso al bibliotecario no deberá ser causal para anular el proceso..." o algo por el estilo. Saludos. --Chico⁵¹² 17:39 22 jun 2018 (UTC)

Si el proponente de la revalidación se olvida de hacer algún otro usuario lo va a hacer sin tener que anular nada Esteban (discusión) 17:43 22 jun 2018 (UTC)

•  A favor, pero sin carácter retroactivo. MONUMENTA Discusión 17:55 22 jun 2018 (UTC)

 A favor de notificar a la(s) persona(s) implicada(s) sobre el proceso en su discusión. Añado que en ocasiones el sistema no notifica con éxito una mención pese a tener activada las notificaciones, por lo que encuentro muy positiva esta propuesta. --Miaow 18:02 22 jun 2018 (UTC)

•  A favor, es de puro sentido común, me sorprende que tenga que llegar a discutirse esto. --Pólux (disceptatio) 18:12 22 jun 2018 (UTC)
•  A favor, por sentido común. Siempre que un usuario esté implicado en algo se le debe avisar. --Lautaro 97 (discusión) 18:18 22 jun 2018 (UTC)

Contesto a Leoncastro –y a Mar del Sur–: en primer lugar yo no veo muy necesario hacer eso del "ping" para que le salga la lucecita roja a un usuario con el que se participa en un debate -por eso no os enlazo- doy por hecho que si está en el debate y se quiere enterar se va a enterar, con lucecita roja o sin ella, pero la lucecita hace como que te fuerza a intervenir. Del mismo modo, el bibliotecario al que se le abra una recogida de avales se va a enterar cuando se comunique a la comunidad el inicio de la recogida de avales, si es que se quiere enterar...; un bibliotecario un poco descuidado sería si no estuviera a esas cosas. Tampoco creo que deba ser avisado, como alguien ha dicho arriba, por haber sido denunciado, pues una recogida de avales no es una denuncia. Ni siquiera debería dar lugar a una discusión: quien abre la recogida de avales expone sus motivos, quien está de acuerdo los avala y quien no, no es preciso que polemice, con que espere a que finalice el proceso de recogida de avales y vote a favor del bibliotecario cuestionado es suficiente. Dicho eso, me parece una cuestión de cortesía el aviso igual que me hubiese parecido más elegante plantear estos cambios en otro momento y no con el partido en juego. Saludos, --Enrique Cordero (discusión) 19:20 22 jun 2018 (UTC)

Antes de nada señalar que no se habla de notificaciones metiante ping, sino de un mensaje en la discusión del usuario, como se dice en la modificación.

Y en segundo lugar, yo veo que alguno no estaba precisamente muy atento, pero creo que así se enteró. -- Leoncastro (discusión) 21:28 22 jun 2018 (UTC)

Comentario Por otra parte, como se trata de un cuestión de cortesía, más vale parar con las reglas allí donde se prohíbe ser descortés... Porque basta con no ser descortés. En cambio, esto de obligar a la más exquisita cortesía ya es un poco contraproducente. Por eso, entiendo y comparto el punto de IIM 78. Podría aparecer allí como una sugerencia, simplemente. Mar del Sur (discusión) 21:47 22 jun 2018 (UTC)

 A favor, por cortesía, que no debería sobrar nunca, aunque concuerdo con Enrique Cordero, es una recogida de avales, los biblios podrían usar la defensa solo dependiendo del resultado y en la posible RECAB, nada para hacerlo tan complicado, pero tampoco sobra un simple aviso. -- JOAN   → (Pregúntame aquí) ← 22:05 22 jun 2018 (UTC)

Es curioso que se exija a los usuarios la cortesía (más bien la obligación suprema) de avisar al bibliotecario afectado, pero a estos se les permita hacer y deshacer a su antojo, no ya sin ninguna cortesía hacia las personas afectadas, sino incluso pasando olímpicamente de contestar a los mensajes de los usuarios afectados. Más que cortesía, esto parece servilismo. Por ello estoy  En contra de poner como obligación el arrastrarse a la página de discusión del bibliotecario que pueda ser candidato a revalidación por no respetar a la comunidad. Con el ping que recibe al utilizar su nombre en la RECAB ya se recibe el aviso correspondiente, y si el o la bibliotecario de turno tiene desactivado los avisos, allá él o ella. Lo que no es de recibo es pasar la responsabilidad de avisar a los usuarios cuando hay notificaciones automáticas. Lo que haga cada usuario con la activación o desactivación de esas notificaciones, es responsabilidad de cada usuario individualmente, y no del resto de usuarios ni de la comunidad. --Tximitx (discusión) 10:31 23 jun 2018 (UTC)

Si ves que un bibliotecario no procede con la cortesía o amabilidad que es exigible, le puedes reclamar, denunciarlo pero no proceder tu de la misma forma Esteban (discusión) 11:06 23 jun 2018 (UTC)

 En contra Suscribo 100% los argumentos de Tximitx. --Maragm (discusión) 11:00 23 jun 2018 (UTC)

• Comentario cuando la cortesía es 'obligada' es menos «cortesía» y más «formalidad» o «protocolo». Creo que no es necesario añadir más puntos en los procesos de RECAB, suficientemente tediosos (abrir página de avales, abrir página de discusión de avales, escribir motivos, detallar características del recabeado, discutir si los motivos son suficientemente fuertes, comunicar en Café:Noticias, reunir avales, tiene que ser al menos 12, no proselitismo, no cuentas con menos de X ediciones apoyando, no cuenta con menos de X ediciones liderando, no más de 15 palabras en los comentarios, cerrar página de avales, esperar X días, protegerla rápidamente una vez se cierre, abrir página de revalidación, abrir página de discusión de revalidación, incluir tal plantilla, esperar a que el BOT haga nosequé, anunciar en nosecual lista, votar otra vez, no votos con menos de X ediciones, no más de 15 palabras, cierre de la página, protección, pedida en meta de retirada de botones, asentimiento del Checkuser, pérdida de botones tras X días). Incluir más historias en este complejo ritual ("es necesario notificar al afectado en su discusión"): no, gracias, además ser bibliotecario (o dejar de serlo) no debería ser tan importante. No sé cómo pensáis que se pueden ver estos kafkianos 'procesos' desde fuera, pero para su mejora creo que es mejor pensar en un desbroce que en añadirles más matorral. strakhov (discusión) 14:07 23 jun 2018 (UTC)

Amén. De hecho propongo aquí mismo una reforma de RECAB de modo que sean solo 7 los avales necesarios para abrir la votación de revalidación. Si hay suficiente apoyo yo me encargo de la redacción, de la votación y de la modificación. --IIM 78 (discusión) 14:14 23 jun 2018 (UTC)

@IIM 78: deberías crear otro hilo para proponer eso, no hay que mezclar una cosa con la otra, este sub-hilo es para buscar consenso sobre las modificaciones de Esteban en el texto de la política. --Chico⁵¹² 14:47 23 jun 2018 (UTC)

 A favor de agregar el texto en la política de revalidación, y si como dice Miaow (disc. · contr. · bloq.) en ocasiones el sistema no notifica con éxito una mención pese a tener activada las notificaciones, entiendo que ha de ser notificado en su página de discusión. IIM_78 (disc. · contr. · bloq.) afirma que En este proceso no es esencial que el bibliotecario se entere, pues no sé, esencial no es, pero que alguien esté involucrado en una medida o política o cualquier tipo de proceso y «pueda o no enterarse», o que se entere «si es que se quiere enterar» me parece como ir por la puerta de atrás. Más que una simple cortesía, me parece necesario. --Tiberius1701 (discusión) 16:48 23 jun 2018 (UTC)

 A favor Es de elemental cortesía, se avisa de una platilla y de una CDB, ¿por qué no de una revalidación?--Rosymonterrey (discusión) 18:33 23 jun 2018 (UTC)

 En contra solo como una sugerencia, de ninguna manera obligatoria. Juan25 (discusión) 20:51 24 jun 2018 (UTC)

 En contra Una de las tareas principales del bibliotecario es estar pendiente del portal de la comunidad.--Maximo88 (discusión) 02:42 25 jun 2018 (UTC)

 A favor No solo es lógico, sino además necesario. No caigamos en el desacierto de mencionar principios como el de retroactividad y olvidarnos del principio de defensa. No es que alguien deba estar pendiente; no es que se haya portado tan mal que no lo merezca; es que no hay órgano en el mundo libre que imponga una sanción o inicie un procedimiento sin avisar al interesado. Seamos razonables. Hans Topo 1993 (Discusión) 10:35 25 jun 2018 (UTC)

 A favor Tiene sentido y veo verdaderos inconvenientes a hacerlo. --Crystallizedcarbon (discusión) 06:19 26 jun 2018 (UTC)

 En contra a menos que de implantarse este "aviso al afectado" se retire o simplifique algún punto ya existente de la interminable receta, por lo arriba dicho. Rotundo «no» a la burocracia, además de que no hace falta "arreglar lo que no está roto": si después de varios años no ha supuesto en la práctica un 'problema' la inexistencia de este "aviso personal al damnificado", no se ve claro por qué en 2018 haría falta incluirlo como requisito adicional. Seamos razonables. Saludos. strakhov (discusión) 13:23 26 jun 2018 (UTC)

 A favor Es algo elemental. --Amanuense (discusión) 16:03 30 jun 2018 (UTC)

 A favor de notificar en página de discusión de usuario por cortesía. Si alguien se olvidase, no creo que fuese motivo de invalidación, ya que el bibliotecario recibiría multitud de notificaciones por mención igualmente. --MarioGom (discusión) 13:24 7 jul 2018 (UTC)

 A favor el bibliotecario implicado debe ser avisado, también propondría crear una plantilla de aviso. Ignacio2403 ¿Hablamos? 19:03 8 jul 2018 (UTC)

Pregunta: ¿Es válida una votación en el café para modificar una política? --Saludos. Ganímedes 13:12 7 jul 2018 (UTC)

Consenso para bajar a 7 los avales necesarios para iniciar RECAB

Para no entrampar el hilo anterior que busca consenso sobre otra cosa, y, de acuerdo a lo expuesto por IIM 78, pues estoy  En contra porque el proceso es demasiado delicado como para tomarlo a la ligera, los 12 avales me siguen pareciendo la mejor opción para iniciar una RECAB. --Chico⁵¹² 14:51 23 jun 2018 (UTC)

 En contra Seria demasiado fácil abrir RECAB's --Shiho 123 (discusión) 14:56 23 jun 2018 (UTC)

 A favor Más que suficientes. De eso se trata, que sea más fácil. Si goza de la confianza de la comunidad, no tendría nada que temer. --Maragm (discusión) 15:02 23 jun 2018 (UTC)

 En contra, ya es ridículo ver la falta de argumentación y exposición de argumentos de peso para una RECAB y más encima lo quieren trivializar más... Hprmedina (¿cri cri?) 15:05 23 jun 2018 (UTC)

 En contra --Grabado (discusión) 15:11 23 jun 2018 (UTC)

 En contra --Kirito ^キリト 15:15 23 jun 2018 (UTC)

 A favor Menos drama. --Saludos. Ganímedes 16:08 23 jun 2018 (UTC)

 En contra. Coincido con Chico. Saludos. --Miaow 16:20 23 jun 2018 (UTC)

 En contra --Tiberius1701 (discusión) 16:51 23 jun 2018 (UTC)

 En contra Lautaro 97 (discusión) 16:54 23 jun 2018 (UTC)

 En contra En todo caso, debería considerarse elevar el número de avales si se supone que a medida que crece el proyecto, también crece su número de usuarios. Pero 12 avales me parece un número adecuado y si se toma una vista históricamente de las búsquedas de avales, de las 21 que se listan Wikipedia:Tablón de anuncios de los bibliotecarios/Portal/Archivo/Avales para revalidación de bibliotecarios, solo 1 (la primera de Taichi) no alcanzó los 12 avales en sus dos semanas de duración, la gran mayoría alcanzó los avales sin problema y el resto menor fueron cerradas de manera prematura (en general por el biblio renunciando voluntariamente). --Pólux (disceptatio) 17:06 23 jun 2018 (UTC)

 A favor. Generalmente ocurre que los que avalan votarán en contra en la futura revalidación (corríjanme si me equivoco en esto). Entonces, puede ser que en la revalidación haya 13 votos en contra (el proponente mas 12 que avalan). Para que el bibliotecario se mantenga, tendría que haber 39 votos a favor, es decir, un total de 52 votos. He visto muchas candidaturas que tienen menos de 52 votos en total, y candidaturas que resultan en la no elección del bibliotecario, con menos de 13 votos en contra. Ener6 (mensajes) 18:04 23 jun 2018 (UTC)

@Ener6: viendo WP:RECAB y contando la participación en esas votaciones (excluyo las dos cerradas de manera prematura): la de Hprmedina/2 tuvo un total de 84 votos; Cookie, 122; Hprmedina/1, 112; Cheveri, 85; Resped, 75; Laura Fiorucci, 144; Ganímedes, 154; Andreasmperu, 99; Magister Mathematicae, 112; Ecemaml, 135; y Sanbec, 109. Todas superan con creces los 52 votos totales, y algunas de ellas son de hace varios años atrás. Si te referís, a WP:CAB en la comparación, yo no creo que sean comparables, es distinto cómo se percibe a un bibliotecario que ya ha participado y aplicado sus permisos a darle el permiso a un usuario que nunca lo ha tenido. Es normal que haya más abstención cuando se desconoce al candidato. --Pólux (disceptatio) 19:03 23 jun 2018 (UTC)

Gracias por el análisis Pólux. Efectivamente yo me refería a las candidaturas en genral, y no sólo a las revalidaciones. No obstante, te doy la razón en que siempre serán diferentes a causa de conocerse o todavía no conocerse la actuación como bibliotecario. Ener6 (mensajes) 19:21 23 jun 2018 (UTC)

 En contra De por si se aceptan solicitudes de avales chapuceras e improcedentes, se realiza proselitismo haciendo ping a usuarios que se sabe que han tenido diferencias con el biblio. No, de ninguna manera.--Rosymonterrey (discusión) 18:30 23 jun 2018 (UTC)

Comentario no es el mecanismo de consulta, para eso hay encuestas, y las modificaciones a las políticas van por mediante votaciones Superzerocool (el buzón de msg) 20:28 23 jun 2018 (UTC)

Yo creo que todos los que escriben aquí saben eso (como también saben que se puede cambiar algunos aspectos de las políticas simplemente consensuando en el café). Por otro lado, es bueno charlar en el café, y no aumentar la burocracia cuando no es necesario. Ener6 (mensajes) 20:35 23 jun 2018 (UTC)

Claro está, si hay consenso, ¡bien!, el problema es que hay mecanismos para modificar las cosas, y creo que por muy sé valiente, el civismo -de avisar a las personas en los medios y mecanismos correctos- debe mantenerse y seguir los protocolos adecuados. Superzerocool (el buzón de msg) 20:48 23 jun 2018 (UTC)

 En contra, no se debería abrir una RECAB por pocos usuarios disgustados o con diferencias, como dicen por ahí «no se es perita en dulce como para caerle bien a todo el mundo», 12 están muy bien e incluso pensaría que un poco más tampoco estarían tan mal. -- JOAN   → (Pregúntame aquí) ← 01:59 24 jun 2018 (UTC)

 En contra. No podemos dejar que cualquier cosa amerite una revalidación. Debe haber consenso de la comunidad, no de unos pocos. Penquista (¡Que no te vaya bien!...¡Que te vaya excelente!...©) 02:17 24 jun 2018 (UTC)

 En contra --Леон Поланко говорит вам и слушает вас 02:18 24 jun 2018 (UTC)

 A favor Siete usuarios son más que suficientes para mostrar que hay un sector de la comunidad que lo ve necesario y para descartar lo único que se desea descartar: la apertura de RECAB de manera irresponsable o malintencionada de alguien que ofuscado quiera abrir un proceso de manera vengativa. En realidad, el propio hecho de que el cargo no tenga caducidad ya es raro, debería ser algo más natural el recambio. Mar del Sur (discusión) 03:21 24 jun 2018 (UTC)

•  En contra. Si la causa por la que se abre la revalidación está bien justificada, la experiencia demuestra que los avales no tardan en aparecer. Y más de doce, a veces. Gauri (ex Miss Manzana) (discusión) 04:16 24 jun 2018 (UTC)

•  En contra. Se necesitan Biblotecarios si se quiere tener una wikipedia de calidad, incluso se debería de aumentar el número de avales, hay que recordar que es una tarea copiosa y voluntaria y entiendo que eliminar biblotecarios, por motivos vanales o poco consensuados, mermaria la calidad de nuestra wikipedia que debe aspirar a mejorar día a día. --JaviMad (discusión) 09:56 24 jun 2018 (UTC)

• Comentario Un tanto indiferente porque siete, más allá de sus resonancias bíblicas, no me dice nada, y casi lo mismo me da eso que 8 que 10 que 12. En cualquier caso, no puedo estar más en contra del comentario que me precede. Lo que merma la calidad de nuestra wikipedia, resta frescura, oxida a la comunidad y genera tantas tensiones, y lo que (de hecho) reduce el número de administradores, es el insufrible "proteccionismo" del cargo, la tremenda importancia que se le da, este endiosamiento, este una vez que lo consigues es "para siempre". ¿De veras hay alguien tan ingenuo que cree que exigir más avalistas (por ejemplo, veinte) como requisito para revalidar ...va a resultar en más administradores? (???)

EMHO, en una enciclopedia en la que fuera más normal dejar de ser administrador (de hecho, en la que el cargo caducara por defecto después de 2 años, por ejemplo), ...habría más administradores, no menos. En las CABs se darían muchas más "segundas oportunidades" a personas con las que has tenido rencillas porque supondría eso, dar una oportunidad al candidato, en lugar de un free pass vitalicio. strakhov (discusión) 12:17 24 jun 2018 (UTC)

@Strakhov: Se puede decir más alto, pero no más claro. Conuve (discusión) 15:12 24 jun 2018 (UTC)

Amén. -- Leoncastro (discusión) 21:51 24 jun 2018 (UTC)

Mi aplauso a tu exposición. Suscribo tu escrito.--Maximo88 (discusión) 02:38 25 jun 2018 (UTC)

•  A favor El actual número es muy alto ya que muchos usuarios prefieren abstenerse. Es bueno que se hagan revalidaciones, así los bibliotecarios reafirman la confianza de la comunidad. Juan25 (discusión) 16:39 24 jun 2018 (UTC)
•  A favor Y sigo recomendando revalidaciones bianuales para todos los bibliotecarios.--Maximo88 (discusión) 02:34 25 jun 2018 (UTC)

 En contra Siete usuarios son demasiado fáciles de reunir, más cuando el ambiente que suele rodear una RECAB es siempre el de apoyar a nuestros amigos e ir en contra de nuestros enemigos. Doce personas es un número que ayuda a aliviar un poco ese ambiente, al ser más difícil tener once que seis amigos. Hans Topo 1993 (Discusión) 10:34 25 jun 2018 (UTC)

 En contra Ya hace años, cuando el proyecto era un número reducido de usuarios, se acordó la necesidad de doce apoyos. Ahora, que somos una comunidad mucho más grande, debería ser muy sencillo reunir estos doces avales. Mucho más sencillo que antaño. Rauletemunoz 11:28 25 jun 2018 (UTC)

 En contra No veo cuál es la necesidad. Banfield - ¿Reclamos? 18:22 25 jun 2018 (UTC)

•  En contra Son solo cinco más. Si el usuario necesita una RECAB seguro que no faltarán avalistas. --Geom (discusión) 00:53 26 jun 2018 (UTC)
•  En contra Jcfidy (discusión)
•  En contra No veo la necesidad del cambio. --Crystallizedcarbon (discusión) 06:21 26 jun 2018 (UTC)

 En contra --Amanuense (discusión) 15:52 30 jun 2018 (UTC)

 Muy a favor. Mas que suficientes, la comunidad se manifestará cuando esté abierta la RECAB, 7 avales son mas que suficientes; aunque quizá con mayores requisitos de antigüedad... Miguu ¡Parlamenta! 07:15 1 jul 2018 (UTC)

 En contra. Innecesario. Por otra parte, respecto al cargo vitalicio del bibliotecario, concuerdo totalmente con el comentario arriba de @Strakhov:, por lo que abogo por establecer revalidaciones periódicas. Saludos, --Technopat (discusión) 08:32 1 jul 2018 (UTC)

Comentario @Technopat: aclaro que yo estoy en contra de las revalidaciones periódicas. Estoy a favor de flags con caducidad. A alguno le puede parecer lo mismo, pero no lo es.

Las primeras implican una dinámica confrontativa periódica, una necesidad de justificar las acciones de uno ante la comunidad ('rendir cuentas'), sigue dando importancia al "cargo", pues es necesario revalidarlo, e implican que a un bibliotecario haya que quitarle los botones. Implica "drama" y exigencias, en algo que no deja de ser una labor ad honorem. Además, ¿os imagináis que el alcalde de vuestro pueblo fuera alcalde sine die, necesitando eso sí revalidarse periódicamente? ¿A que suena "raro-mal"? Además la expresión revalidación periódica apesta a burocracia.

Las segundas, los flags con caducidad, implican que un usuario tiene dos años (o los que sea) para usar los botones como mejor pueda-sepa y a los dos años los deja de tener, sin más. No hace falta ni quitárselos, pues se retirarían solos (creo que los flags desde hace poco se pueden asignar de esta manera). Potencia la idea de transitoriedad y de los botones están para usarlos y de que el bibliotecario no es un "usuario diferente" (...los supermanes de wikipedia, los generales de wikipedia...) sino un usuario normal al que por X tiempo se le han otorgado tales tareas (no especialmente gratas, si bien en la práctica bastante poderosas). El hecho de que en la práctica el "usuario bibliotecario" deje de serlo rompe con la idea de "vitalicio", que no deja de revolotear todavía con la "revalidación periódica" [sic]. Naturalmente, el usuario podría volver a presentar una "candidatura", pero el hecho de que no se "abriera automática e inmediatamente la votación" ayuda a ver a los bibliotecarios como un usuario más y no como miembro de una casta (tenía que salir la palabreja xD) de gobernantes que necesite 'rendir cuentas' para continuar en ella.

Naturalmente nada de esto va a funcionar nunca. Todos (bueno, todos quizás no, pero sí la mayor parte) los administradores votarían en contra. Debe de haber cerca de 100 cuentas con el flag, ganado con mucho esfuerzo y sudor. Echen un ojo a una votación 'tipo' y hagan cuentas, sobre todo teniendo en cuenta que no solo votarían ellos en contra, sino 1) todos los cachorritos de biblio, 2) todos los usuarios que aspiran desde hace tiempo a tener su cortijito de 'poder' y andan trabajando en ello —por medio de poner plantillas, hacer mantenimiento, visibilizarse, hacer la pelota y mostrarse cordial y cívico, eficaz y útil para el proyecto durante suficiente tiempo (¿no cantan a la legua todos los usuarios que están allanando su camino hacia la bibliotecaría? ¿no podríais hacer una lista de futuros candidatos?)— además de 3) todos los usuarios que se sienten cómodos per se en la dinámica actual existente o que sencillamente tengan pánico a los cambios («nos quedaríamos sin biblios»), que serán mayoría, visto lo visto. Saludos. strakhov (discusión) 11:29 2 jul 2018 (UTC)

Gracias por la aclaración @Strakhov:. Tienes toda la razón y acepto, gustosamente, la enmienda. Con una salvedad de tu «naturalmente nada de esto va a funcionar nunca». Es posible que yo sea un poco más optimista que tú, pero todo es susceptible al cambio. Ya sabes, A la corta o a la larga, el tiempo todo lo alcanza. Saludos, --Technopat (discusión) 12:18 2 jul 2018 (UTC)

Todo es susceptible al cambio pero antes desaparecerá wikipedia (que lo hará, como todo) que se logrará hacer 'finito' el flag de bibliotecario. Heed my words. strakhov (discusión) 12:55 2 jul 2018 (UTC)

Como idea, la próxima vez que te presentes, comprométete a abandonar el flag a los dos años y pide que si no lo terminas haciendo se te abra una RECAB y se te vote en contra por mentiroso. Lo mismo logras cambiar algo. Saludos. strakhov (discusión) 13:00 2 jul 2018 (UTC)

Eso funciona menos aún, ni en la RL ;-). (Voté por un diputado que ofreció rebajarse la dieta parlamentaria si salía elegido. Lo eligieron y a la primera vez que pude le pregunté en público qué había sido de su promesa y me salió con que es tan difícil financiar a los equipos asesores, que los viajes, que se ha puesto tan cara la vida...) Sin embargo, sí, yo creo que podrías y deberías abrir una votación. Hace ya un tiempo que te veo plantearlo, Strakhov y también veo que, cuando lo haces, muchos expresamos nuestro acuerdo con un sistema de caducidad del flag de bibliotecario. No sé si se lograría mayoría para una votación así, pero al menos no se desestimaría la propuesta con el argumento falaz del supuesto «exceso de burocracia» que implicarían las revalidaciones... Mar del Sur (discusión) 13:56 2 jul 2018 (UTC)

Me remito al cuarto párrafo de mi primera réplica (la larga) a Technopat. La tónica que percibo es una oposición a lo que conlleve a asignar un fin en el tiempo al flag. La propuesta... la regalo. Que se la quede y la desarrolle quien quiera... Un optimista, por ejemplo. Yo no soy de eso. strakhov (discusión) 14:08 2 jul 2018 (UTC)

Dada la reciente encuesta y el comentario precedente, podemos agregar otra causa de por qué las iniciativas para limitar el cargo no prosperan: porque el método propuesto no es el que preferimos. Yo, revalidación permanente o nada! --angus (msjs) 15:09 2 jul 2018 (UTC)

• Comentario @Strakhov: Acabo de ver tu propuesta arriba: de haberme hecho un ping (¿haberme pingado?), te habría contestado antes. Al tener claro que ningún cargo debe/puede ser vitalicio, no tengo inconveniente alguno a comprometerme en una CAB futura a abandonar el cargo de bibliotecario a los dos años/al año, siempre con la evidente posibilidad de abrirme una recab antes del vencimiento de dicho plazo si incumplo alguna política. De hecho, solo hay dos motivos que me han impedido volver a presentarme de nuevo: a) en su día, se mencionó cierta preocupación por mi aparente empeño en presentarme y b) relacionado con el anterior motivo, no sé qué espacio de tiempo la comunidad consideraría razonable entre una CAB u otra. En fin, aunque es posible (¿probable?) que ninguno de los presentes lleguemos a verlo, mark my words, y aunque Sam Cooke tampoco llegó a verlo, «[A Change Is Gonna Come (canción)|A Change Is Gonna Come]»... Un saludo, --Technopat (discusión) 15:05 7 jul 2018 (UTC)

Hace un tiempo (no recuerdo cuándo exactamente... ¿2014?) se había llegado a un consenso e incluso se llegó a votar por revalidaciones periodicas cada 6 meses, pero eligieron los peores plazos posibles (enero y julio), coincidiendo con los dos veranos (austral y boreal) en la que los bibliotecarios (por derecho, vamos) podrían irse de vacaciones y no estar para defender sus RECAB. Creo que podría retomarse el tema, pero en forma más planificada. Un proceso similar al que se hace con los Stewarts (reafirmar a los que ya están + presentar a los nuevos). Todos a la vez, en un periodo razonable (no sé... ¿marzo? ¿octubre?). Simplificaría ambos procesos y le quitaría "trauma" al asunto. --Saludos. Ganímedes 13:11 6 jul 2018 (UTC)

Andrea, creo que te refieres a esta votación de 2012. Pero el rechazo fue muy claro (no llegó al 40% de los votos a favor ninguna de las propuestas) y solo muy marginalmente por la razón que das. Yo ya aporté entonces mis argumentos, que mantengo a día de hoy, sobre por qué esta clase de revalidaciones serían una mala idea. Un saludo, Furti (discusión) 14:34 6 jul 2018 (UTC).

Comentario Que los permisos de bibliotecario tengan un periodo de validez a menos que se renueven explícitamente sí me parece bastante sano para la comunidad. Aunque implicaría tener más CAB, sería cualitativamente distinto. Igual que en política no se vive igual una reelección que un revocatorio. --MarioGom (discusión) 13:33 7 jul 2018 (UTC)

 En contra de la idea de bajar el número de avales. La experiencia que tenemos es que doce avales no son garantía de que un bibliotecario no vaya a ser revalidado, ¿para qué rebajarlo más? Solo tendríamos más movidas y más burocracia para nada. Cuando hay algo grave que justifica una remoción de los permisos, se alcanzan siempre los doce avales en muy poco tiempo. --Furti (discusión) 14:37 6 jul 2018 (UTC).

 En contra 12 avales no deben ser difíciles de conseguir si existen motivos de peso como los expuestos en la política de RECAB. Lo único que puede aportar rebajar los avales es tener muchas más RECAB que, sin posibilidades de prosperar en votación, nos mantengan a todos un poco más ocupados en discusiones innecesarias. --MarioGom (discusión) 13:28 7 jul 2018 (UTC)

Comentario: En verdad no veo mucha diferencia entre 7 y 12, en ambos casos se refleja un consenso de una parte de la comunidad. Me parece mejor trabajar sobre las propuestas de utilizar revalidaciones periódicas o las "flag con caducidad" que mencionaron más arriba. Combinado con permisos escalonados y con requisitos más relajados. En las encuestas se refleja que la comunidad no está dispuesta o otorgar una cosa sin la otra. Un saludo. Mártir Peperino (plegarias) 18:32 10 jul 2018 (UTC)

Marcado indiscriminado de artículos con plantillas de mantenimiento crítico

Este último tiempo he estado observando con mayor atención las categorías de borrado, y he notado que varios artículos han sido marcados indiscriminadamente para borrado rápido o SRA, cuando claramente no corresponde (ya sea porque no es descaradamente promocional o a escasos minutos tras la creación de dichos artículos). No diré nombres, pero en mi página de discusión, esos usuarios me han reclamado por el retiro de plantillas de mantenimiento crítico (lo que se que no está bien, pero lo hago solo en casos muy puntuales), y también les he contrareclamado; incluso bibliotecarios han desestimado sus marcados y más de alguna vez me han dado la razón.

Precisamente, la colocación indiscriminada y apresurada de plantilla de mantenimiento, se puede interpretar como una aplicación extrema de las políticas, algo que está establecido en No sabotees Wikipedia para respaldar tus argumentos.

Citando lo que dicen los Criterios para el borrado rápido de acuerdo a las faltas que planteo:

A1. Lo que Wikipedia no es.

A1.2 Definiciones, recetas o textos, previo traslado a Wikcionario, Wikilibros, Wikisource, Wikiversidad, o a otro proyecto de la fundación Wikimedia.

Ahí dice claramente previo traslado, siempre y cuando pertenezca a esos proyectos.

A2. Infraesbozo.

Artículos de apenas una o dos líneas que carezcan de contexto que permita calificarlos como esbozos, si bien, y siempre y cuando el contenido sea enciclopédico, no se recomienda el borrado rápido a los pocos minutos de su creación. Se debería dar un margen mínimo (ej. media hora) al autor para su ampliación. Si el artículo es más amplio, de acuerdo a Wikipedia:Contextualizar, se le dará un periodo de un mes antes de proceder al borrado, usando {{infraesbozo}}.

De eso hablo precisamente cuando planteaba sobre el filtro, dar tiempo a los usuarios de ampliar los artículos. Un artículo muy reducido pero con contenido claramente no cumple con CBR.

A3. Páginas sin traducir o traducciones automáticas. Textos en otros idiomas excepto si se están traduciendo (deberá indicarse con, por ejemplo, las plantillas {{traducción}} y {{en desarrollo}}). Se incluyen también en este criterio textos producto de una traducción automática o semiautomática que posea tantos errores gramaticales u ortográficos que no se entienda la idea que el texto quiere transmitir. Si la traducción es apenas comprensible, se le dará un periodo de un mes antes de proceder al borrado, usando {{autotrad}}.

Apliquemos el sentido común. Si una página fue recientemente creada y está en otro idioma, y parece provenir de otra Wikipedia (ver resumen de edición), es claramente enciclopédico. Démosle tiempo a los editores de traducirla. Ojo con las traducciones creadas con la Herramienta de traducción.

A4. No enciclopédico o sin relevancia. Artículos de personas, empresas, grupos musicales, sitios web, entre otros, que sean claramente no enciclopédicos. En caso de duda sobre su relevancia, se añadirá {{sin relevancia}} y se dará un mes de plazo para justificarla antes de decidir si procede el borrado.

Aquí es donde veo muchos abusos de este criterio, marcados para borrado rápido donde la relevancia es discutible o cuestionable, pero no es evidente la irrelevancia. Se prefiere {{SRA}}, pero varios pretenden deshacerse del artículo, que es lo que estoy cuestionando principalmente.

G3. Páginas promocionales.

Páginas que contengan spam o textos de promoción, autopromoción, propaganda, publicidad o con muchos elogios innecesarios que impiden tener una redacción neutral. En caso de dudas sobre si la página realmente es autopromoción, coloca {{promocional}} y se dará un mes de plazo para justificarla antes de decidir si procede el borrado.

Al igual que A4, aquí se recomienda el uso de {{ Promocional}} o {{SRA}} en caso que la autopromoción o sin relevancia no sea evidente.

G6. Violaciones de derechos de autor. Si existe la posibilidad de que el usuario que subió el texto sea el dueño de los derechos de autor, se colocará {{copyvio}} y se dará un mes para probar la autoría antes de borrar. Si procede de páginas en las que sea un evidente caso de plagio (de la enciclopedia Encarta, por ejemplo), se colocará {{plagio}} y se borrará inmediatamente.

En algunos casos puede ser al revés, que Wikipedia haya sido plagiada, o que el contenido provenga de un mirror que nos indique claramente el licenciamiento. Aunque suene obvio, hay que revisar el historial y la fecha de publicación del artículo donde se sospecha copyvio, y si no es un mirror de Wikipedia. Si no esa información no está disponible, WHOIS tiene la última palabra (y él no revisar la fecha de creación del dominio es fuente frecuente de falsos positivos; de hecho vi hace poco uno en Commons). Esto quisiera recalcar y agregarlo a las políticas y huilas sobre copyvio.

U3. Si viola la política sobre páginas de usuario.

Si hay un artículo claramente enciclopédico, díganle amablemente al editor que lo traslade a su taller. No deberían trasladarlo ni marcarlo para borrado sin previo aviso, ya que eso causaría un Conflicto de edición, lo que es molesto.

Razón por la cual, y en base a la Política de borrado y el sentido común, propongo lo siguiente:

• Editar el Filtro antiabusos para:

• Impedir a los usuarios no-autoverificados marcar artículos verificados creados hace menos de 10 minutos, dentro de los espacios de nombres destinados a contenido enciclopédico ((principal), Anexo:, etc).

• Advertir a losno-verificadores al marcar artículos no verificados creados hace menos de 10 minutos.

• Advertir a los no-administradores (Bibliotecarios, Stewards, etc) al marcar artículos verificados creados hace menos de media hora.

• Aclarar quienes pueden remover plantillas de mantenimiento crítico si claramente no procede (si solo usuarios confirmados o también veteranos) (especialmente por lo que está estipulado en {{No retires plantillas de mantenimiento crítico}}, cito:

El retiro sin contar con el consenso es aceptable únicamente si el aviso viola las políticas de Wikipedia, como «Wikipedia:No sabotees Wikipedia para respaldar tus argumentos».

Y una forma de "respaldar argumentos" es marcar para borrado rápido artículos que, según tu opinion, no son enciclopédicos (lo que es la aplicacion extrema de las políticas como mencioné arriba, contrario al sentido común). Reitero, se prefiere SRA o un aviso previo al usuario.

Esto, para dar tiempo a los usuarios de mejorar los artículos de reciente creación, principalmente los que fueron traducidos usando la Herramienta de traducción, ya que no siempre traduce correctamente, o incluso puede fallar al poner las referencias. Un conflicto de educion por algo que justamente estás arreglando es molesto.

Davod (desquítense n_n) 20:08 25 jun 2018 (UTC)

Que tontería, por dios. No se si llorar o reir, pero "Impedir que usuarios que no sean administradores (Bibliotecarios, Stewards, etc) coloquen plantillas de mantenimiento crítico a artículos verificados creados hace menos de 1 hora" es muy absurdo. Va en contra de todas las políticas de Wikipedia. ¿Que quieres, mandar al pozo a los que no tenemos privilegios (son eso) en Wikipedia? ¿Restringir el borrado rápido, sabiendo que hay horas en los que no hay ni un solo bibliotecario que borre una misera página vandálica o promocional, o en propuesta de borrado? Esa no es la Wikipedia que quiero. Es repugnante, y si llegarse a aprobarse (lo que creo que no pasará), me retiraría sin pensar.--Marcos Okseniuk (discusión) 20:25 25 jun 2018 (UTC)

• Puede que suene absurdo, pero más absurdo son los marcados a artículos creados hace pocos minutos (incluso una hora es poco tiempo, a lo más media hora, de hecho la Política de borrado rápido lo menciona). No entiendo cuál es la prisa de borrar y borrar artículos que perfectamente se pueden mejorar (de la misma forma que planteas el restringir el borrado, tampoco podemos restringir la adición de artículos, lo que es parte de presumir buena fe y el sentido común; con hacerlo, también estaríamos mordiendo a los novatos). Lo mismo planteé en Commons, principalmente al operador de un bot, quien tomó en cuenta el consejo. La idea es dar tiempo a los editores de mejorar los artículos recién creados.

• Tomando en cuenta lo que dices, veo que será mejor permitir a los Verificadores marcar esas páginas. -- Davod (desquítense n_n) 20:45 25 jun 2018 (UTC)

• @Amitie 10g: Sí claro, significa que a las 11 de la noche, cuando no haya bibliotecarios activos, no podré marcar para borrado rápido (ni propb ni nada de eso) una página vandálica que diga "asfasdhaJSDHZahjkahsjkhjk" o una promocional que diga "apta créditos es la mejor empresa del mundo". No jodas, la Wikipedia no se soluciona con más privilegios a los bibliotecarios. --Marcos Okseniuk (discusión) 20:51 25 jun 2018 (UTC)

• 12 horas me parece mucho. Me gusta más media hora después de la última edición, aunque a algunos le pueda parecer pronto. No creo que un artículo que fue verificado necesite que le sea colocado una plantilla de mantenimiento crítico, por lo que no le veo mucho sentido al primer punto. Lo único que creo que estoy de acuerdo es en el tercer punto, aunque creí que ya había un filtro para eso. Si no es el caso, no estaría mal crear uno a priori. (PD: Y espero que para «plantillas de mantenimiento crítico» no te estés refiriendo también a la plantilla de Destruir o la plantilla de Propuesta de borrado)--Santiago₁₄₂₈₅₇ 20:54 25 jun 2018 (UTC)

• @Santiago142857: De hecho, se refiere a esas plantillas...--Marcos Okseniuk (discusión) 20:59 25 jun 2018 (UTC)

• Pensé que estaba más orientado a plantillas como SRA o Infraesbozo, aunque ahora que lo mencionas sí que están esas plantillas incluidas en las de mantenimiento crítico. ¿Eso significa que te saldría un mensaje de aviso cada vez que quieras incluir una de estas plantillas, incluso en caso de vandalismos? No me convence.--Santiago₁₄₂₈₅₇ 21:02 25 jun 2018 (UTC)

• A mi en particular, el término "impedir" me suena muy fuerte, seguir quitando privilegios a los usuarios y dar mas trabajo a verificadores o bibliotecarios no me parece razonable en lo más mínimo, me parecería mejor que en vez de utilizar una plantilla de mantenimiento crítico se utilizase otra y se notifique al usuario creador del artículo de un posible borrado del mismo si este no es mejorado en "x" cantidad de días (horas me parece muy injusto ya que hay muchas personas a las cuáles no les sobra el tiempo) o invitarlo que lo traspase al taller con la misma finalidad de borrado si no lo hiciese. Es todo una cuestión de "educar" a los usuarios que hay mas de una alternativa que sólo la plantilla de borrado. --Claudieg (discusión) 21:03 25 jun 2018 (UTC)

• El problema es que a veces no pasa: algunos usuarios que hago alusión ni siquiera avisan al usuario en cuestión (no estamos educando a los novatos). El hecho de que haya poco tiempo para patrullar no es excusa para leer en diagonal y marcar para borrado rápido por considerarlo como no enciclopédico (e insisto, los Criterios para borrado rápido lo especifican). -- Davod (desquítense n_n) 21:24 25 jun 2018 (UTC)

• Los que vienen a promocionar empresas o a sí mismos no merecen ni un segundo de piedad en el asunto. ¿O que? ¿Vamos a seguir favoreciendolos dándoles tiempo?--Marcos Okseniuk (discusión) 21:08 25 jun 2018 (UTC)

• Lean bien lo que puse: hablo de artículos verificados por un verificador o los creados por autoverificados (es obvio que un patrullero no marcará como verificado un artículo vandálico o promicional). Los artículos no verificados quedan excluídos de este filtro, lo que sí permitirá marcar vandalismos o autopromocionales. -- Davod (desquítense n_n) 21:12 25 jun 2018 (UTC)

  @Amitie 10g: ¿Y como se puede confiar en el criterio de los verificadores? Si por descuido verifica una página de plagio, ¿tendré que esperar una hora o más para marcarlo? Tu petición ya pierde sentido práctico; una hora después todos se olvidan de la página, queda a lo último.--Marcos Okseniuk (discusión) 21:24 25 jun 2018 (UTC)

•  Muy en contra, los  usuarios no bibliotecarios pueden marcar algún artículo para destruir pero ello no significa que sea destruido (eso ya lo decidirá el bibliotecario que lo revise). Jcfidy (discusión) 21:26 25 jun 2018 (UTC)

• A lo que voy con esto también, es que los biblios también se equivocan, por el problema de las prisas. -- Davod (desquítense n_n) 21:38 25 jun 2018 (UTC)

Quizá se equivocaron también cuando te dieron la razón en quitar plantillas de borrado ¿O solo cuando te conviene?.--Marcos Okseniuk (discusión) 21:42 25 jun 2018 (UTC)

Para que ven que la prisa es un verdadero problema, comentaré a cerca de una situación que pasó en Commons hace un tiempo atrás (no tiene ningún desperdicio). En resumen:

• Un administrador, sin concenso, alteró una plantilla de licencia, dejando a archivos válidamente licenciados como sin licencia
• Otro administrador, descuidadamente, marcó todos esos archivos multimedia como elegibles para borrado
• La comunidad tuvo que arreglar el desmadre y arreglar el licenciamiento de esos archivos "sin importar cuánto tiempo tome"

Por eso también estoy en contra de llevar las políticas al extremo y demasiado rápido. -- Davod (desquítense n_n) 21:52 25 jun 2018 (UTC)

• @Amitie 10g (disc. · contr. · bloq.) Primero yo pondría el filtro con 15 minutos, pero debería haber un bot que analizara los artículos y colocar o no colocar el filtro según sea el caso, porque si es muy promocional Astanium es la mejor empresa del mundo con los mejores productos, un vandalismo literal como este gengavscwyjxedrA,, páginas de pruebas como que el contenido diga esta es una dirección ip, puede que muchas otras personas la controlen, para más seguridad crea una cuenta de usuario o SRA inarreglables como artículos sobre canales de Youtube pequeños. Ignacio2403 | ¿Hablamos? 00:53 27 jun 2018 (UTC).

• Respecto del filtro, lo suavicé para solo advertir, y reduje el tiempo a 5 minutos para no-sysop y 30 minutos para no-verificadores.

Lo del bot... mejor dejárselo a un humano, la tasa de falsos positivos sería demasiado alta (razón por la cual terminaron dando de baja a PatruBOT), y además también están los filtros y SeroBOT. -- Davod (desquítense n_n) 02:12 27 jun 2018 (UTC)

• Pero en estos casos estaría  En contra no se pueden seguir restringiendo las funciones a un grupo de usuarios porque ese grupo tendría mucho trabajo que hacer, además, Wikipedia dejaría de crecer, debido a las restricciones, los usuarios novatos querrían aprender a patrullar páginas nuevas. Ignacio2403 | ¿Hablamos? 01:04 27 jun 2018 (UTC)

• Aquí es donde se forma una paradoja: con tanto plantillismo, estamos restringiendo a los novatos a crear o traer nuevos artículos (que es el objetivo principal de la comunidad). Lo que se busca es beneficiar a todos, al tiempo de erradicar esa mala práctica del plantillismo. -- Davod (desquítense n_n) 02:12 27 jun 2018 (UTC)

• No sé si se ha discutido antes, ¿pero se ha propuesto que las IPs no puedan crear artículos nuevos? Reduciría potencialmente el número de casos de vandalismo y de autopromoción, aunque por experiencia he visto que hay IPs que han creado artículos que cumplen las políticas de la enciclopedia, incluso si necesitan arreglos en estilo. --Jamez42 (discusión) 15:36 27 jun 2018 (UTC)

Tengo entendido que sí se ha discutido en varias ocasiones. Lo que se suele hacer es bloquearlas si se observa un patrón de comportamiento vandálico. -- Davod (desquítense n_n) 16:12 27 jun 2018 (UTC)

@Jamez42 y Amitie 10g: sí, se ha hablado mucho de ello, y siempre se ha acordado que las cosas sigan igual (o sea, que las IPs puedan seguir creando artículos desde cero), cosa que me parece mal pues hacerte una cuenta no cuesta nada si quieres colaborar, pero seguramente dé mucha pereza si solo se desea vandalizar. Al fin y al cabo, esta es la enciclopedia libre que todos pueden editar. Un saludo. --Fdo.: Gonzalo P.M.G. • 16:17 27 jun 2018 (UTC)

La última vez hace una semana más arriba, en este mismo café. MONUMENTA Discusión 16:20 27 jun 2018 (UTC)

Además, para aprobar esto, tendría que aumentar considerablemente el número de verificadores, cosa que no pasará nunca, al menos que se retire la política que dice el verificador obtiene automaticamente el permiso de autoverificado y prohibirles a los verificadores verificar artículos suyos, al menos, que también soliciten el permiso de autoverificado. Ignacio2403 | ¿Hablamos? 21:52 27 jun 2018 (UTC)

Si no se hace eso seguiría estando muy  En contra. Ignacio2403 | ¿Hablamos? 21:52 27 jun 2018 (UTC)

Ya que lo mencionas, me parece mejor, ya que ese permiso no se otorga "automáticamente". 0--- Davod (desquítense n_n) 23:00 27 jun 2018 (UTC)

• Comentario @Amitie 10g: Volviendo al planteo inicial, el problema es que ninguna política establece un límite a la colocación de plantillas. SRA resulta particularmente complicada, dado que es una plantilla que cualquiera puede colocar, generando un condicionamiento hacia el o los autores, forzándolos a "demostrar la relevancia" en un plazo de 30 días, bajo principios subjetivos. Se han dado casos en que usuarios plantillean masivamente con SRA una categoría entera de artículos que, en su opinión, no deberían estar en Wikipedia. Lo que necesitamos es una modificación de la política, para establecer un límite a la cantidad de plantillas que un usuario puede colocar. Si esto no es posible técnicamente, entonces se deberá crear un permiso para poder colocarlas, similar a como se procede para solicitar otros permisos como el de verificador o el de reversor. Un saludo. Mártir Peperino (plegarias) 18:59 10 jul 2018 (UTC)

• Yo aplicaría ese límite por grupos; los verificadores rendirán un límite mayor. -- Davod (desquítense n_n) 21:47 10 jul 2018 (UTC)

Comentario El usuario Amitie o Davod o como quiera llamarse, constantemente esta revirtiendo plantillas, aún a artículos que merecen el borrado rápido sin lugar a dudas. Se ha empeñado a defender artículos solamente revirtiendo solicitudes de borrado y no con la mejora de los artículos que defiende. Da la impresión de que quiere que Wikipedia se vuelva una enciclopedia llena de información sin criterio, simplemente por el hecho de existir, técnicamente como una Wiki sin reglas.
Les voy a mostrar varios ejemplos en los que ha hecho esto:

• Calibre 89 fue aplantillado con SRA, se cumplió el mes y un usuario coloco la de borrado rápido. Se que en este caso, es cuestionable que un usuario anónimo coloque una plantilla de borrado rápido, pero lo cierto es que el articulo tuvo la oportunidad de ser mejorado y no ocurrió, el borrado rápido era valido y le correspondía a un bibliotecario aceptar el borrado o revertir a la plantilla SRA, que de todos modos el resultado hubiera sido el mismo.
• Banjo (personaje): El articulo es una obra de investigación original. Se colocó una plantilla SRA, la cual, Amitie revirtió inmediatamente argumentando que la relevancia es obvia porque el juego Banjo-Kazooie es relevante, es decir, argumenta relevancia heredada y sólo por ese hecho, para Amitie, el articulo es intocable. Después se intento fusionar en la página principal del juego, otros artículos similares de personajes del juego, a lo cual también se opuso, en primer lugar porque desconocía el procedimiento para fusión y consideró que era erróneo unificar los datos, y también porque seguía argumentando relevancia de los personajes principales, aún cuando los artículos son también investigación original, aún peores que Banjo (personaje).
• Ensenada, Baja California: Esta era una redirección innecesaria, ya no había artículos enlazados a esta, además de que no cumple con las convenciones de títulos, la desambiguación sería Ensenada (Baja California), además de que fue creada arbitrariamente para cubrir un error al enlazar en el articulo Televisa Regional. Aplantille para borrado R4 esta tarde, pero Amitie inmediatamente revirtió argumentando vagamente y de facto que "no había motivos para que se borrara la redirección. Actuó del mismo modo con Televisa Mexicali con el mismo "argumento", este caso es aún peor ya que no sólo es una redirección innecesaria, era recreación de material borrado.
• Anexo:Personajes de Banjo-Kazooie Tras la discusión de los artículos de personajes de Banjo-Kazooie, se dio a la tarea de crear un anexo para fusionar los artículos que deberían ser borrados. Sin embargo, crea un anexo aún peor que los otros artículos, no sólo es investigación original, también la redacción no es neutral, completamente escrito por un fan del juego, con lenguaje coloquial y como si fueran parte del mismo manual del juego. Pero eso no es todo; colocó una plantilla de en desarrollo mientras estaba creando el artículo, sin embargo, no removió la etiqueta cuando terminó y como cereza del pastel, colocó la plantilla de Wikiproyecto Videojuegos en la discusión, esto da la impresión de que trataba de blindar el artículo. Al parecer, no es la primera vez que utiliza la plantilla "en desarrollo" para "defender" un articulo, tal y como se comenta en su página de discusión para el artículo Shawn Mendes: The Tour.

Si bien, como dice Amitie o Davod, se puede abusar y se abusa de las plantillas para borrado, también se puede abusar de la creación de páginas irrelevantes y su defensa. Los bibliotecarios cumplen muchas funciones y no pueden estar "verificando" todos y cada uno de los artículos. Existen las plantillas de borrado rápido para ayudar a mejorar la Wikipedia, anunciando que hay artículos vandálicos o que simplemente no tienen razón de ser, y las SRA no sólo están para borrar, también están para mejorar, en lugar de simplemente solicitar el borrado, con estas plantillas se le hace un llamado a la comunidad para defender los artículos corrigiéndolos y demostrando de verdad la relevancia de estos y se da un plazo, si no se mejora, se procede a borrar, pero al menos se le dio la oportunidad de justificar la existencia del articulo.

Es muy curioso que en su propuesta mencione a los pilares de Wikipedia cuando el mismo usuario no los sigue y los viola constantemente, sobre todo la de sabotaje y "lo que Wikipedia no es". Creo que el usuario no debería de utilizar el café para la creación de políticas para proteger sus propios errores, debería mejor estudiar bien los pilares, admitir sus errores y ser más tolerante con la comunidad. Si no le gusta que Wikipedia tenga estas políticas, para eso están las Wikis, esto es una enciclopedia universal, no se pueden estar añadiendo artículos de cuanta cosa le interese a cada usuario sin poder justificar relevancia. Creo a todos nos han borrado artículos, pero no podemos ni deberíamos discutir la creación de políticas para que no nos vuelvan a borrar páginas de baja calidad, por el contrario, se debe discutir el mejoramiento de estas políticas para que desincentivar o vigilar mejor la creación de artículos "malos". Mejor debería escribir un blog de las cosas que le interesan, en lugar de hacernos perder muchísimo tiempo revirtiendo, discutiendo e incluso iniciando CDBs por su intransigencia. Me disculpo de antemano de lo último que acabo de decir si les pareció grosero, pero realmente nos ha hecho perder mucho tiempo a varios wikipedistas y bibliotecarios.--MexTDT (discusión) 03:08 11 jul 2018 (UTC)

@@MexTDT: Qué te parece la idea de crear un nuevo espacio de artículos "pendientes de mejora", solo visibles luego de una advertencia y no indexables por buscadores? Sería como una instancia previa al borrado, donde los artículos pueden mejorarse antes de ser trasladados al espacio principal. Allí podrían moverse todos los artículos problemáticos, sin referencias, con dudas sobre la relevancia, etc. Mártir Peperino (plegarias) 17:53 11 jul 2018 (UTC)

Un concepto interesante, una especie de purgatorio para estos artículos. Lo malo de esto sería que sólo algunos tendrían oportunidad de verlos, un usuario anónimo que tenga conocimientos en el tema de algún artículo, no podría hacer sus aportaciones, sin embargo es un concepto interesante que quizás con algunas mejoras podría ayudar, aunque en lo personal, creo que las plantillas ya "mandan a un purgatorio" a artículos malos y se da la oportunidad a toda la comunidad de arreglarlos y salvarlos. Lo cierto es que hay muchísimos que simplemente no se pueden defender y por eso están las plantillas criticas.--MexTDT (discusión) 20:47 11 jul 2018 (UTC)

Modificación de la política de votación (prórrogas)

A raíz del reciente apagón de Wikipedia se ha generado un debate sobre los plazos de votaciones (véase el café de Noticias). Las dos principales posiciones, a grandes rasgos, se pueden resumir de la siguiente forma:

1. El plazo se debe extender, dado que se han reducido las posibilidades de votar.
2. El plazo no se debe extender, dado que no está contemplado en la política.

Dado que esta circunstancia se puede repetir, no sólo por un apagón voluntario, también por un ataque de denegación de servicio o un desastre como un incendio en un centro de datos, propongo añadir a la política uno de las siguientes puntos:

Versión 1

Prórroga por días en todos los casos

• En caso de haber una interrupción de servicio generalizada interrupción del acceso que afecte a la mayoría de los usuarios de Wikipedia en español, se prorrogará el plazo de votación. La extensión de la votación se realizará en incrementos de un día cuando la interrupción de servicio supere las 12 horas.

Versión 2

Prórroga únicamente en interrupciones prolongadas (requiere aclaraciones)

• Antes del cierre de una votación, si se ha producido una interrupción de servicio generalizada interrupción del acceso que afecte a la mayoría de los usuarios deWikipedia en español, durante más de tercio del plazo, se extenderá el plazo de votación. La extensión de la votación se realizará por el tiempo que haya durado la interrupción redondeado a días enteros.

Podría existir la duda de qué constituye una interrupción de servicio generalizada: mi propuesta es que se trate de una interrupción general y del lado de Wikipedia. Lamentablemente sería inviable aplicar esta regla si se trata de un bloqueo parcial externo a Wikipedia, como el Gran Cortafuegos en China o el bloqueo de Wikipedia en Turquía. Puede que no haga falta especificarlo, ya que se puede aplicar el sentido común. Pero si pensáis que existirá confusión, se podría aclarar en un pie de página.

Planteo este tema de forma totalmente independiente a una posible política de apagones (ya sea en el sentido de prohibirlos o regularlos), ya que este problema se puede dar en otras circunstancias. Para poder mantener un debate constructivo, os pediría que para debatir una posible política de apagones se abriese un hilo separado de este. Gracias. --MarioGom (discusión) 21:05 6 jul 2018 (UTC)

Hola, MarioGom. No me queda claro en la versión 2 a qué te refieres con "más de un tercio del plazo". --Saludos. Ganímedes 21:14 6 jul 2018 (UTC)

Si el plazo son 14 días, se extendería el plazo únicamente ante una interrupción de más de 4 días. La limitación es bastante arbitraria, y además tiene el problema de que no es lo mismo que haya una interrupción durante el primer día de votación a que la votación acabe abruptamente por una interrupción que dure hasta el final del plazo marcado... En cualquier caso, intentaría adoptar una serie de reglas a las que le encontremos sentido y no sean difíciles de comprender, interpretar y aplicar. --MarioGom (discusión) 21:19 6 jul 2018 (UTC)

Es que justamente allí radica el problema. No es lo mismo los 4 días si afectan los días previos al cierre de la votación que en el inicio o la primera mitad de la misma. --Saludos. Ganímedes 21:28 6 jul 2018 (UTC)

Probablemente lo más fácil de aplicar con cierto sentido es la primera versión o algo en la misma línea. --MarioGom (discusión) 21:30 6 jul 2018 (UTC)

¿Por qué prorrogar solo si es más de doce horas? Para mí, es bien claro. Se interrumpe por 6 horas, se prorroga por 6 horas. Se interrumpe por 10 horas, se prorroga por 10 horas. ¿Y por qué cuando se interrumpe por un tercio del plazo? (4,6 días en una CAB) me parece algo antojadizo. Por el momento  No apoyo ni la versión 1 ni la 2. Penquista (¡Que no te vaya bien!...¡Que te vaya excelente!...©) 21:31 6 jul 2018 (UTC)

Sobre lo del tercio: estoy de acuerdo. De hecho, retiro la segunda versión, no está bien desarrollada.

Sobre por qué no hacerlo con precisión de horas: por aplicabilidad. Lo primero: si hay una interrupción de servicio de dos horas, como parece que hubo en 2012, ¿vale la pena prorrogar todas las votaciones? Y si queremos ir a una precisión exacta, tenemos el problema de cómo medir la interrupción. Ante una interrupción de «más o menos un día», prorrogamos un día, en lugar de entrar en una discusión eterna sobre si la interrupción duró 20 o 26 horas. --MarioGom (discusión) 21:38 6 jul 2018 (UTC)

Me oriento hacia la versión 2 pero tiene que ser más específico en algunos términos. Cuanto antes del cierre por dar un ejemplo. --Claudieg (discusión) 21:41 6 jul 2018 (UTC)

A ver, tomando la idea de Penquista:

Versión 3

Prórroga

• En caso de haber una interrupción de servicio generalizada en la Wikipedia en español, se prorrogará el plazo de votación por igual duración al de la interrupción.

--Saludos. Ganímedes 21:43 6 jul 2018 (UTC)

A tener en cuenta:

1. Depende del tipo de interrupción, la duración se podrá determinar con mayor o menor exactitud. Por ejemplo, en el caso del apagón, deberíamos ser capaces de saberlo con total precisión, ya que habrá algún registro de cuando se aplica y cuando se levanta (no sé quién tiene acceso, pero entiendo que existe). En una desastre, lo normal es que exista un comunicado oficial de Wikimedia (vía página de estado o blog). Normalmente este tipo de actualizaciones de estado se dan con una precisión de horas. En caso de una interrupción intermitente, como puede ser en un ataque de denegación de servicio, la precisión de la medida se complica más, y es posible que no tengamos acceso a un registro exacto.
2. Creo que tiene que haber un mínimo de interrupción antes de tomarnos la molestia de prorrogar: ¿si hay una interrupción de 10 minutos qué hacemos? Creo que tampoco se han planteado problemas con los plazos de votación en anteriores interrupciones de servicio cortas... --MarioGom (discusión) 21:50 6 jul 2018 (UTC)

Entiendo... Cuando hay apagones "programados" por motivos de mantenimiento o similar la Fundación siempre avisa con tiempo. Tampoco es lo mismo 10 minutos en cualquier momento que en el último suspiro de una votación. Si no ha pasado, tal vez es porque no se había presentado este problema. Habría que estudiarlo. --Saludos. Ganímedes 22:03 6 jul 2018 (UTC)

Pues yo no entiendo ni lo de «interrupción de servicio generalizada» ni tampoco lo de «interrupción general y del lado de Wikipedia». Por ejemplo la reciente interrupción por el apagón no fue ni del lado del servidor de Wikipedia ni tampoco fue generalizada pues algunos no estaban afectados. Es preciso definir mucho más ese concepto. -- Leoncastro (discusión) 22:27 6 jul 2018 (UTC)

El apagón afectó, técnicamente, a todos los usuarios por igual: no era posible acceder a Wikipedia mediante los medios habituales. Los usuarios que pudimos entrar lo hicimos mediante algún tipo de "truco" (en mi caso, usar un bloqueador de JavaScript para acceder y la edición móvil para editar). Era "del lado de Wikipedia" porque el bloqueo se implementó en los servidores de Wikipedia. Se aceptan propuestas de redacción para clarificar el concepto. --MarioGom (discusión) 22:42 6 jul 2018 (UTC)

Técnicamente estás equivocado MarioGom. El uso de la aplicación móvil no fue afectado por el bloqueo y es uno de los «medios habituales». Igualmente el bloqueo no fue del lado del servidor, sino del lado del usuario, pues el código javascript se ejecuta en ese lado. Si se considera del “lado de Wikipedia” porque fue una decisión de la plataforma, entonces es lo que se deberá aclarar, independientemente de si el bloqueo se realiza desde el lado del servidor o no, o incluso por arte de magia. -- Leoncastro (discusión) 23:08 6 jul 2018 (UTC)

Para que se entienda cómo se ha efectuado el bloqueo, cuando accedías a una página, el servidor de Wikipedia te entregaba esa página que pedías, junto con un código que al ejecutarse realizaba una redirección a otra página prefijada. Tu navegador realmente siempre descargaba la página que pedías, aunque en cuestión de menos de un segundo ya te redireccionaba a otra. Algo similar a una simple redirección. Wikipedia, tanto el servidor como el sistema funcionaban; era tu navegador el que te bloqueaba. -- Leoncastro (discusión) 23:12 6 jul 2018 (UTC)

El que te bloqueaba era tu navegador, pero la intención era esa, que el navegador te bloquease y te redirigiese y que no pudieras editar. Es algo parecido al bloqueo de un usuario aquí en wikipedia, que igualmente puede editar, saltándose el bloqueo, pero la intención es que esté bloqueado. Conuve (discusión) 23:17 6 jul 2018 (UTC)

Pues ténicamente también te equivocas Conuve, cuando te aplican un bloqueo queda registrado bien tu nombre de usuario bien tu dirección IP, y al cargar una página desde esa dirección o desde ese nombre de usuario el servidor sirve una página no editable. El navegador en este caso no realiza ninguna alteración. -- Leoncastro (discusión) 23:39 6 jul 2018 (UTC)

Sí, sé que el apagón se aplicó en el frontend, pero me refiero a que fue implementado en la plataforma de Wikipedia. Sí, en el servidor, que es el que sirve el JavaScript del cliente, no hablamos de un script de usuario que haya sido inyectado por terceros. Creo que la definición que escojamos debe contemplar este caso. En cuanto a la aplicación móvil, si bien es un medio habitual, creo que deberíamos considerar que hay interrupción si esta afecta a la página web principal (sin contar las APIs para desarrolladores), que creo que es a través de dónde editamos la mayoría, incluso desde dispositivos móviles, y por lo tanto lo que más afecta a las votaciones. ¿Cómo crees que podríamos definirlo? ¿O dónde crees que debería estar el límite? --MarioGom (discusión) 23:18 6 jul 2018 (UTC)

┌─────────────────────────────┘
¿«apagón, interrupción de servicio de los servidores o cualquier otra incidencia técnica de la Wikipedia en español que afecte seriamente a la capacidad de votar»? --MarioGom (discusión) 23:29 6 jul 2018 (UTC)

Yo considero que no necesitamos una norma para regular algo que habrá pasado 1 vez en 20 años. De hecho no recuerdo ningún precedente. Es evidente que cada uno maneja su tiempo como quiere pero al final la relación trabajo-beneficio es muy bajo, el trabajo que supondrá plasmar el cambio y el debate, no compensa el beneficio de tener un añadido a la norma por lo ya comentado. Wikipedia en sus política debe abordar casuisticas mucho más amplias y habituales como se desprende claramente de WP:NOES. Saludos. Bernard - Et voilà! 23:36 6 jul 2018 (UTC)

@MarioGom, ¿para qué complicarse? «una interrupción del acceso que afecte a la mayoría de los usuarios». -- Leoncastro (discusión) 23:39 6 jul 2018 (UTC)

Gracias. Esa redacción me parece bien. Pensaba que ibas por otro lado con tu comentario ;-) --MarioGom (discusión) 23:47 6 jul 2018 (UTC)

@Bernard: Tras leer las argumentaciones a favor y en contra, pensé que no sería tan costoso llegar a un consenso en este caso. Igual estoy pecando de ingenuo. --MarioGom (discusión) 23:57 6 jul 2018 (UTC)

Esa idea es buena Leoncastro. Hay que centrarse en problemas en el "acceso" y no en qué lo provoque. El acceso puede estar impedido de forma voluntaria o involuntaria. El acceso puede ser prohibido por un órgano interno, por decisión de la comunidad o por órganos externos. La declaración tiene que ser amplia. Esto de la propuesta dos debería ser algo así: La extensión de la votación se realizará por el tiempo que haya durado la interrupción redondeado a días enteros, sin que esto supere el plazo estipulado por la política en número de días/horas en condiciones de acceso normales para la edición. Es decir, si se cae el servidor un año, la votación no debe durar un año cuando se reanude. No estoy muy lúcido ya hoy, pero no se puede presuponer que la interrupción, siempre va a durar menos que el plazo de una votación. Muchas gracias MarioGom, por sacar esto adelante. Para mí, es necesario, sobre todo, para votaciones de políticas complejas futuras con numerosos apartados, dónde haya que hacer un buen estudio. No sabemos a lo que nos enfrentamos en el futuro, debemos garantizar la continuidad del proyecto y el procedimiento para la reanudación del servicio ante graves problemas.--Maximo88 (discusión) 00:04 7 jul 2018 (UTC)

Creo que el tiempo que se invertirá en esto no vale la pena, son cosas que pasan de manera esporádica. Saludos, Laura Fiorucci (discusión) 00:11 7 jul 2018 (UTC)

Cada cual que invierta su tiempo en lo que quiera. -- Leoncastro (discusión) 00:17 7 jul 2018 (UTC)

¡Por supuesto! ¡No faltaba más!... ni menos tampoco. Tampoco sobra, aunque algunas veces... bueno, el asunto es que, es mi opinión, y la tuya y la del otro y bué, así es esto (Cantinflas dixit). Laura Fiorucci (discusión) 00:20 7 jul 2018 (UTC)

No veo necesario una prorroga para las votaciones, son situaciones que no suceden seguido. Hay plazos fijos en las votaciones y se deben respetar. Además parece que solo se desea extender a CABs y RECABs pero hay muchas otras consultas, propuestas, CADs, etc. las cuales de alargar su tiempo crea bastante confusión. Kirito ^キリト 00:26 7 jul 2018 (UTC)

Kírito: en ninguna parte de este hilo se ha explicitado que sea solo para CAB y RECAB y mucho menos se ha dicho que no se desea hacer nada con las demás. Solamente se ha hablado de "votaciones" (y por cierto, como las CdB no son votaciones sino que es por argumentación, deberían ser consideradas aparte; es más, existen ya mecanismos específicos para alargarlas y nadie ha tenido problemas con ello). ¿Por qué afirmas eso? --Saludos. Ganímedes 13:49 7 jul 2018 (UTC)

Solo he dicho que me parece, hay todo tipo de votaciones hasta incluso plantillas de mantenimiento que uno podría decir que se debe prorrogar por lo que no veo motivos para extender más allá del tiempo expirado porque se pueden crear confusiones. Saludos. Kirito ^キリト 14:43 7 jul 2018 (UTC)

┌─────────────────────────────┘
Lo de ponerse a debatir que casos se deben considerar como interrupciones graves me parece un poco fuera de lugar. Creo que todos sabemos lo que es una interrupción grave del acceso a Wikipedia. En cuanto a lo de si ampliar el plazo o no, y cuanto tiempo, aquí ya puede haber más debate, puesto que no es lo mismo una interrupción al principio de la votación que al final. Tampoco veo muy claro eso de ampliar el mismo plazo que dure la interrupción. ¿Y si la interrupción dura 7 minutos, ampliamos 7 minutos? ¿Y como medimos el tiempo que dura una interrupción? De hecho, en este último apagón el tiempo no ha sido de 36 horas exactas, porque ha habido un periodo en el que el bloqueo fue desactivado. Además, en una interrupción fortuita no se sabe cuanto va a durar. ¿Que pasa si se produce una interrupción en la última hora y no se sabe cuando se restablecerá el servicio? ¿Habrá que estar pendientes las 3 horas siguientes para ver si se restablece el servicio y se puede votar en las 3 horas de prórroga? Creo que es más adecuado establecer un periodo más concreto de prórroga, con independencia de los condicionantes que se establezcan.

Mi propuesta de redacción (sujeta a cambios) es la siguiente:

En caso de que en las últimas 24 horas de una votación se produzca una interrupción del acceso a la Wikipedia en español que afecte a la mayoría de los usuarios, se prorrogará el plazo de esa votación 24 horas más. Si se produce una nueva interrupción durante esa prórroga, se realizará una nueva prorroga, y así sucesivamente hasta que se restablezca el servicio de manera estable.

Esta propuesta asume la tesis (que algunos pueden no compartir) de que en términos generales una interrupción temporal en medio de una votación no tiene porque afectar a la misma si aún hay plazo para votar, es decir, se evita alargar el plazo de la votación innecesariamente, dado que todos conocen desde el inicio cuando finaliza y por tanto hasta que día tienen para votar. Sin embargo, si que contempla la tesis de que si la interrupción se produce en el último día de la misma, sí que parece más razonable que haya usuarios que se hayan quedado fuera por no tener ya tiempo para votar (normalmente nadie puede estar 24 horas conectado esperando a que se restablezca el servicio). Para este caso se establece una prórroga siempre fija de 24 horas, puesto que puede ser difícil de determinar la duración del corte y los usuarios tampoco tienen porque saber cuando se ha restablecido el servicio o cuando se va a restablecer. Con esta opción, aunque haya un corte y no se sepa cuando finalizará, siempre se sabe que al menos habrá un periodo adicional para votar de 24 horas, por lo que bastará con entrar una vez al día para comprobar si el servicio se ha restablecido y poder votar. --Tximitx (discusión) 01:37 7 jul 2018 (UTC)

La idea es no beneficiar ni perjudicar a nadie. Adicionalmente, diría yo, «incluiría que si alguien votase durante una suspensión programada o no, los votos serán nulos hasta que el servicio se restablezca de manera íntegra». Penquista (¡Que no te vaya bien!...¡Que te vaya excelente!...©) 01:50 7 jul 2018 (UTC)

No comparto lo de anular esos votos, porque quien tenga acceso y vote no tiene porque saber que el resto han estado sin acceso. Por ejemplo, en el apagón que ha habido, dicen que había usuarios que podían acceder desde el móvil libremente sin usar ningún truco. Si alguno de ellos vota sin ni siquiera haberse enterado del apagón, ¿habría que anularle su voto? Eso es suponer mala fe. --Tximitx (discusión) 07:10 7 jul 2018 (UTC)

Yo tampoco creo que se deban anular votos. No le encuentro justificación y me parece complicar las cosas demasiado. --MarioGom (discusión) 08:09 7 jul 2018 (UTC)

@Tximitx: Sobre la precisión de la interrupción, como comentaba más arriba, en los casos más probables (apagón, parada de mantenimiento, caída del servidor) tendríamos la posibilidad de saber la duración exacta o con una resolución no inferior a la hora. En otros casos como un ataque de denegación de servicio probablemente tendríamos la duración total al finalizar el ataque, pero de forma más inexacta, ya que el efecto puede ser intermitente. Sobre duraciones mínimas: creo que una interrupción de 7 minutos (incluso al final de la votación) no debería ser motivo de prórroga ni discusión alguna. Por lo demás, la posibilidad de dar más peso al último día me parece interesante si se optase por algo en la línea de la segunda versión propuesta. --MarioGom (discusión) 08:19 7 jul 2018 (UTC)

Bueno, no lo tengo tan claro lo de la duración. Un apagón o una parada de mantenimiento programada si que puede tener una duración clara, pero si se produce una caída de servidor(es), un caída de internet [6] [7], un ataque a Wikipedia, etc., no es tan fácil determinar cuantas horas ha durado la falta de acceso, puesto que el restablecimiento del servicio puede ser escalonado. De hecho, muchas veces las informaciones hablan de "varias horas" sin especificar duración exacta, y en otros casos puede haber alguna disparidad entre las fuentes sobre la duración exacta. En la mayoría de las votaciones será indiferente una hora más o una menos, puesto que los votos estarán claros hacia un lado, pero si se produce un voto decisivo justo en el plazo discutido, ya estará el lío montado. Puedo que eso sea mucha casualidad, pero es algo que ya ha ocurrido. --Tximitx (discusión) 07:28 8 jul 2018 (UTC)

Me queda la duda, con la última propuesta, respecto a la duración. Dices "si en las últimas 24 horas" ... se extenderá 24 horas. Sería lo mismo si en esas 24 horas Wikipedia no estuviera accesible 19 horas o 19 minutos? --Saludos. Ganímedes 13:52 7 jul 2018 (UTC)

Efectivamente sería lo mismo. La cuestión es que si hay una incidencia en el acceso por una caída del sitio, quien se vea afectado probablemente no sepa cuanto tiempo va a durar la incidencia, y no se le puede pedir que este pendiente varias horas para ver si se restablece el acceso. Tampoco sirve de nada que se prorrogue la encuesta unos minutos o unas horas porque puede ocurrir que esa prórroga le pille trabajando o durmiendo. A nadie le sirve de nada que si no puede acceder por la tarde a votar por una incidencia con el acceso, se le prorrogue luego a la noche unas horas cuando está durmiendo. ¿Pasaría algo si no se hiciera ninguna prorroga? Pues acabamos de tener un apagón de 36 horas sin que se haya prorrogado ninguna votación y ya hemos visto que eso no ha influido en el resultado. ¿Y pasaría algo si se prorrogase 24 horas aunque la incidencia haya durado solo un minuto? Pues yo diría que tampoco, salvo que el resultado oficial se conocería un día más tarde. Si la idea es que quien pueda verse afectado por la incidencia tenga la oportunidad de votar, lo suyo es que se le de una prórroga suficiente para que pueda hacerlo al día siguiente sin depender del horario y de si las horas de prórroga coinciden o no con que esté trabajando o durmiendo. No creo que andar mirando las horas que dure el corte para prorrogar más o menos tiempo solucionen nada. Tampoco creo que se buena opción andar mirando si el corte ha durado más o menos de X minutos para decidir si se prorroga o no. Para mi, la mejor opción es que si alguien el último día a la hora que se ha conectado no ha podido votar por una incidencia con el acceso, se amplía el plazo 24 horas y se le deja votar al día siguiente a la hora que le venga bien. Al final la idea es que pueda votar, y no que tenga que estar pendiente de si tiene 12 horas más o solo 1 hora. --Tximitx (discusión) 07:28 8 jul 2018 (UTC)

Por lo que vi en el café de Noticias había varias formas de saltar el bloqueo. En caso de futuros apagones se podría indicar, quizás en la página a la que se redirige cuando se entra durante el bloqueo, cómo evadirlo. --Fundn (discusión) 17:08 7 jul 2018 (UTC)

No estoy de acuerdo Fundn. Si se propone hacer un futuro apagón, espero que no pueda ser evadido de ninguna forma, pues existen los medios técnicos para que así sea. Otra cosa es que se proponga un mensaje en forma de diálogo que se pueda cerrar y continuar sin ningún otro tipo de restricción, para dar igualdad de oportunidades a los que sepan o no evadir bloqueos ridículos. -- Leoncastro (discusión) 17:27 7 jul 2018 (UTC)

Entiendo, no tiene sentido un apagón si se puede evadir. Sería más simple colocar un aviso. Pero eso se discutirá en aquel momento. --Fundn (discusión) 17:59 7 jul 2018 (UTC)

Criterio de voto y reflexión

Comentario Quiero añadir que no se debe reducir el discurso a que la emisión del voto se hace en minutos (esto sería solo cierto en CAB/RECAB, y no en largas votaciones de políticas amplias). Me refiero al tiempo, que los servidores necesitan, para almacenar la firma que ejerce el derecho al voto. Un acceso inhabilitado a Wikipedia, impide leer los apartados de discusión de la votación, acceder a historiales de contribuciones de los usuarios y analizarlos, contestar a usuarios que efectúan preguntas y puede influir en las votaciones, el derecho a la defensa de alguien propuesto a CAB ante una acusación. También la verificación de la validez del voto requiere el acceso a herramientas de contribuciones. Por ello, una caída del sistema, impide las garantías no solo para exponer el voto, sino para construir el criterio de voto. También quiero que decidamos que va a ocurrir con las encuestas, también tienen fecha de cierre, y algunas han exigido muchísimo trabajo para decidir las opciones y para firmar numerosas veces.

El hecho acontecido puede repetirse con seguridad a partir de septiembre (aunque espero que no ocurra) porque habrá que enmendar (¿terceras enmiendas?) los artículos en Europa, y no podemos estar meses sin celebrar votaciones, por si da la casualidad de que la fecha de cierre coincide con otra suspensión. Si necesitais un ejemplo de por qué necesito los plazos de acceso, os puedo dar uno muy reciente: he necesitado días y leerme toda la discusión para darme cuenta de que la CAB de Kírito [8], era la de un usuario que se ha cambiado el nombre, al cual yo conocía por IrwinSantos y no estaba ni avisado en la plantilla de esta CAB que había optado dos veces más a CAB. Solo se menciona levemente en la presentación (que me acabo de dar cuenta ahora) y en ella se aducía que no se sabía ponerlo en la plantilla (nadie ayudó a hacerlo).

Entiendo las posturas de “no es necesario”, pero quién sabe si el criterio de todos seguiría siendo el mismo de ahora, si el próximo bloqueo no es una chapuza como este, que pudisteis eludir los más expertos en el código de Wikipedia (cosa que yo solo pude hacer a las 12 horas, cuando lo avisaron en la PD inglesa el truco, y ni se me ocurrió, a partir de dicho momento, editar por respeto a las decisiones de la comunidad y a los demás usuarios que formáis parte, añadiendo que la funcionalidad de los menús de navegación quedaba lastrada). Si no se hubieran permitido las dos reversiones que levantaron durante unas dos horas el veto o la creencia de que se podía realizar otra en cualquier momento más si hacía falta, y si hubieran sido escrupulosamente las 36 horas que se decidieron (no es el propósito aquí valorar quienes ni de que forma), habría que ver las nuevas posturas. Me alegro mucho, de que no haya caído la suspensión con el cierre de las 2 CAB y la RECAB, pero ha sido por un suspiro y puro azar en la apertura del día elegido para las votaciones, y no me gusta dejar las cosas a la arbitrariedad. Una nota de humor: Está el cuento de los Tres Cerditos, que al final siempre queda un día para votar (la casa de ladrillo) y todos bailan celebrando el buen final, pero también está el cuento de Pedro y el Lobo, el cual se da un festín con las ovejas, y ya sabéis como acaban los pastores.--Maximo88 (discusión) 06:01 7 jul 2018 (UTC)

@Leoncastro:, mi proposición sigue siendo igual de válida, porque se puede usar una vpn o un pc ajeno para saltarse el bloqueo. En algunos casos también funciona borrando las cookies. Conuve (discusión) 10:58 7 jul 2018 (UTC)

@Maximo88: creo que te equivocaste de cuento :) . En Pedro y el lobo no hay ovejas, creo que muchos en internet confunden ese cuento con la fábula El pastor mentiroso. Y ahora, leyendo Wikipedia (cómo nooooo), lo aclaran en el artículo.

Con respecto al tema tratado en este apartado, dejé mi impresión en otra sección. Saludos, Laura Fiorucci (discusión) 14:01 7 jul 2018 (UTC)

@Conuve, usar un VPN o una computadora ajena sirven para acceder desde otra dirección IP diferente a la bloqueada, y borrar las cookies sirven para desconectar forzadamente la vinculación con la cuenta de usuario bloqueada; que son ambas cosas las que ya mencioné anteriormente que se registran en el servidor. Por cierto, es mejor no profundizar mucho más en este aspecto. -- Leoncastro (discusión) 15:23 7 jul 2018 (UTC)

Cualquiera de las dos primeras opciones que ha planteado MarioGom (disc. · contr. · bloq.) me parecen razonables. En caso de que el consenso se incline por la primera, a mi juicio ya estaría bien así. Si se inclina por la segunda, en cambio, introduciría una cláusula que establezca que si la interrupción es de más de doce horas y afecta al último día de votación, igualmente se prorrogará por un día natural (o dos si la interrupción es de más de treinta y seis, y así sucesivamente) aunque no llegue a afectar a un tercio del período de voto. Un saludo, Furti (discusión) 16:05 7 jul 2018 (UTC).

Plantilla plagio

Una cosa, ¿por qué es necesario firmar en la plantilla {{plagio}}? ¿Qué función cumple la introducción de una parámetro obligatorio que sea una firma? ¿No sale en el historial todo? ¿Es para ayudar a los biblios a qué decidan mejor si borrar o no? Que yo sepa se trata de la única plantilla que lo incluye. (sé que utilizando {{subst:plagio|1=origen del plagio}} no hace falta poner las virguillas). Ídem con {{Posible copyvio}}. Las plantillas {{destruir}} y {{bulo}} no la incluyen. Soy consciente de que Wikipedia:Acerca de firmar artículos no aplica al tratarse de una plantilla de mantenimiento. Gracias Triplecaña (discusión) 12:53 6 jul 2018 (UTC)

Siempre pensé en que ese parámetro no debía existir, y me reafirmo. --Saludos. Ganímedes 12:57 6 jul 2018 (UTC)

A mí me parece que puede ser muy útil saber quién puso la plantilla, para comunicarse con la persona. En ese sentido, pienso que habría que agregar ese parámetro en todas las otras plantillas que mencionas. Recuerdo las varias veces que tuve que hacer minuciosas búsquedas en el historial para saber quién agregó la plantilla y poder hacer alguna pregunta, y eso hace perder bastante tiempo. Cuando podría ser un dato simple de la plantilla. Ener6 (mensajes) 21:06 6 jul 2018 (UTC)

Pero es distinto a estampar la firma. --Saludos. Ganímedes 21:51 6 jul 2018 (UTC)

En lugar de obligar a poner la firma, sería mejor agregar solo el enlace a la discusión del usuario (que marcó el artículo) automáticamente.— El comentario anterior sin firmar es obra de Amitie 10g (disc. • contribs • bloq). 15:29 7 jul 2018

Porque no se hace lo que se hace con las plantillas {{bulo}} y {{destruir}} así no se tendría que firmar en las plantillas {{copyvio}} y {{plagio}}. Ignacio2403 ¿Hablamos? 22:47 8 jul 2018 (UTC)

La plantilla {{Bulo}} contiene

La <span class=plainlinks>[{{fullurl:{{FULLPAGENAME}}|diff=cur}}</span> última edición] en esta página fue hecha por {{U|{{REVISIONUSER}}}} [{{fullurl:{{FULLPAGENAME}}|action=purge}} <span class=plainlinks>{{Edad en tiempo|{{REVISIONTIMESTAMP}}}}].

Lo que podría ser reemplazado por

<span class=plainlinks>Esta página fue marcada por {{U|{{subst:REVISIONUSER}}}} [{{fullurl:{{FULLPAGENAME}}|action=purge}} <span class=plainlinks>{{Edad en tiempo|{{subst:REVISIONTIMESTAMP}}}}]. Véase el [{{fullurl:{{FULLPAGENAME}}|action=history}} historial] para detalles.</span>

Lo que resulta en:

Esta página fue marcada por Amitie 10g (disc. · contr. · bloq.) hace 5 días. Véase el historial para detalles.

Bien se puede hacer con todas las plantillas de mantenimiento crítico. -- Davod (desquítense n_n) 23:25 8 jul 2018 (UTC)

A mí me parecería muy útil que todas las platillas (no solo las de «mantenimiento crítico») incluyesen un enlace claro a la discu del usuario que las puso. Muchas veces resuelvo los problemas que tiene el artículo, pero simplemente paso de tratar de quitarles el cartel, porque me parece sumamente tedioso este asunto de bucear en el historial, averiguar quién puso el cartelito, bajo qué condiciones, determinar si ese usuario está activo, ponerle un amable mensaje en su discu, esperar su respuesta ...¡ufff!!! Y cuando pienso que el que la puso gastó apenas medio minuto en hacerlo pues es que ya... Es raro: en esta versión de Wikipedia en español no hay propiedad de los artículos, pero sí hay una suerte de «propiedad de las plantillas»: todo el mundo se enfada si no se le va a preguntar explícitamente si ya podemos retirar «su» plantilla. Me parece pésimo. Pero dado que esa «costumbre wikipédica» es bastante difícil de cambiar, al menos sería bueno que quienes ponen los cartelitos nos alivianasen la pista a los que hacemos la otra parte del mantenimiento (tratar de resolver los problemas que ellos diagnostican). Determinar fácilmente quién puso la plantilla sería una ayuda perfecta. Mar del Sur (discusión) 21:30 11 jul 2018 (UTC)

Votaciones

Propongo bajar el periodo de votaciones a 2 meses y 300 contribuciones, quien apoya esto. Ignacio2403 ¿Hablamos? 23:01 8 jul 2018 (UTC)

•  En contra, especialmente cuando el proponente tiene justos los dos meses y no llega a las 500 contribuciones de requisito actual. ¿Tienes prisa por poder votar? Propondría incluso subir los requisitos en todo caso. -- Leoncastro (discusión) 01:22 9 jul 2018 (UTC)
•  En contra, antes los requisitos eran 1 mes y 100 ediciones en el espacio principal pero se llego a consenso para aumentarle los requisitos, así que bajarle de nuevo los requisitos sería un retroceso. Saludos. --Chico⁵¹² 05:23 9 jul 2018 (UTC)
•  En contra si no hay argumentos. --MarioGom (discusión) 06:57 9 jul 2018 (UTC)

Como bien ha advertido MarioGom, esto planteado así parece una ocurrencia sin ton ni son. Ignacio, sería mucho más productivo que explicases el problema que te lleva a proponer el cambio, y así podríamos contarte si estamos de acuerdo o no y por qué. Furti (discusión) 15:11 9 jul 2018 (UTC).

Propongo esto única y exclusivamente por la revalidación de Taichi, debido a que, muchos usuarios tenían de que hablar y no los dejaron votar, además, la cantidad de gente que vota, no crece debido a esto, por eso creo que se deberían bajar, porque si no, las votaciones serían injustas. Ignacio2403 ¿Hablamos? 19:35 9 jul 2018 (UTC)

 En contra La cantidad de gente que ha votado en la RECAB de Taichi es la que más participación ha tenido, o sea que decir que no crece es no haber indagado mucho que digamos. Rauletemunoz 19:41 9 jul 2018 (UTC)

•  En contra. No tiene sentido proponer endurecer la creación de artículos y las ediciones a IPs y no autoconfirmados en un hilo y en otro ablandar las condiciones a usuarios con poca o nula experiencia para temas importantes. Precisamente se necesita usuarios que sepan moverse en Wikipedia, que conozcan un poco las políticas, costumbres y usuarios de la comunidad para poder argumentar y votar con cabeza.--Geom (discusión) 19:49 9 jul 2018 (UTC)

Precisamente Ignacio2403, en las votaciones es preferible que no puedan votar aquellos que no conocen el fondo de las cosas, y que voten solamente por las primeras apariencias. Una persona con poco tiempo en la comunidad, será desconocedora de muchas cosas importantes, que solo se van adquiriendo con el tiempo y la experiencia. Seis meses de tiempo y 500 ediciones de experiencia es un bagaje pequeño en comparación con los más de diez años o las más de cien mil ediciones que ya llevan algunos. -- Leoncastro (discusión) 22:56 9 jul 2018 (UTC)

De acuerdo con todos los participantes anteriores. Sabéis, en mi ciudad la Cruz Roja realiza mucho trabajo social y se responsabiliza tanto del banco de alimentos como de ofrecer clases de repaso gratuitas para los colegiales de familias humildes. Si yo mañana decido hacerme voluntario será porque quiero ayudar en algunas de estas tareas y aportar mi grano de arena para una causa que creo justa. Solo con el paso del tiempo adquiriré conocimientos sobre la dinámica interna de la organización y la conveniencia o no de reformar ciertas normas, y solo después de que pase aún más tiempo seré capaz de conocer a las personas que hay detrás de los cargos y a formarme un criterio sobre su gestión. En Wikipedia ocurre lo mismo: lo fundamental son los artículos y todo lo que se pueda hacer para acercarlos a la gente y generar más participación será bien empleado. Pero los procedimientos internos son algo más complejo de copsar y no debemos temer la postergación del sufragio hasta que se haya ganado más experiencia y criterio. Furti (discusión) 15:47 10 jul 2018 (UTC).

 En contra: concuerdo con todos los comentarios anteriores. No veo que beneficio tenga. El periodo actual sugiere que en dicho lapso el usuario quizás ya tenga un poco de madurez y un poco de nociones sobre como funciona wikipedia. --Леон Поланко говорит вам и слушает вас 18:59 14 jul 2018 (UTC)

Página de desambiguación con dos elementos

¿Es correcto y necesario Winter Park, por poner un ejemplo? La política no dice nada (o no lo encuentro). ¿No bastaría poner un distinguir en cada artículo? Triplecaña (discusión) 22:09 9 jul 2018 (UTC)

Yo no sé de memoria la política y menos sus detalles (y tampoco entré a consultar), pero creo recordar que dice que cuando ninguno de los nombres de los artículos sobresale claramente por sobre los demás (en cuanto a apariciones en las fuentes), entonces el nombre sin paréntesis debe tenerlo la página de desambigüación, que creo que es justo el caso del ejemplo que das. Ener6 (mensajes) 23:07 9 jul 2018 (UTC)

Véase Wikipedia:Café/Portal/Archivo/Políticas/2014/03#Desambiguaciones. -- Leoncastro (discusión) 23:10 9 jul 2018 (UTC)

Gracias a ambos Triplecaña (discusión) 10:53 10 jul 2018 (UTC)

En el mencionado caso, alguna de las dos acepciones debería tener mayor acepción que la otra, pero si no es posible definir la principal, entonces yo pienso personalmente que sí puede ser útil. --Леон Поланко говорит вам и слушает вас 03:42 13 jul 2018 (UTC)

Me quitaste las palabras de la boca (o las letras de mis dedos), Leonpolanco . Penquista (¡Que no te vaya bien!...¡Que te vaya excelente!...©) 03:50 13 jul 2018 (UTC)

Si es permisible una página de desambiguación de 2 elementos si entre esos 2 no hay una acepción principal o más conocida, cuando si hay una principal entre las 2, se usa las plantillas {{redirige}} o {{otrosusos}} como ejemplo esto. Saludos. --Chico⁵¹² 13:51 13 jul 2018 (UTC)

Firmas

Solicito la modificación a la política de firmas para que una firma pueda tener 2 imágenes, esto lo propongo debido a que muchas de las firmas de wikipedia tienen 2 imágenes y puede ser muy difícil que todas estas personas sepan de esto y decirles que cambien sus firmas sería una tarea mucha más difícil, esta propuesta es para que no se vean afectados muchos usuarios por esta política. Ignacio2403 ¿Hablamos? 22:28 9 jul 2018 (UTC)

Cambiar una política porque muchas personas no la conozcan no creo que sea buena idea. En esta votación se aceptó reducir la cantidad de imágenes a una para no molestar a «aquellos usuarios que no cuentan con una conexión de banda ancha». Tampoco es que sea muy difícil cambiar una firma.--Santiago₁₄₂₈₅₇ 22:54 9 jul 2018 (UTC)

El uso de imágenes en firmas de usuario supone una carga innecesaria, como lo indica la política. Hay usuarios que no cuentan con conexión de banda ancha y sería más lento cargar las imágenes, por eso se estableció que solo fuera sola imagen. Además, a los usuarios que incumplan este punto se les puede notificar fácilmente para proceder con los cambios, o sino desean, con la intervención de un bibliotecario. Esteban16 - mensajes 22:59 9 jul 2018 (UTC)

@Ignacio2403, y aparte de tu firma ¿conoces muchos usuarios que usen actualmente una doble imagen? En un hilo precedente propones modificar WP:VOTO porque todavía no cumples los requisitos para votar, y en este propones modificar WP:FIRMA porque tampoco cumples con la norma en tu firma. Creo que lo primero que deberías hacer es mostrar respeto a la comunidad y respetar las normas vigentes y luego, desde el cumplimiento, proponer los cambios que consideras beneficiosos para todos —y no solo por tu propio beneficio—. Un saludo y por favor, ve modificando tu firma. -- Leoncastro (discusión) 23:02 9 jul 2018 (UTC)

Coincido plenamente con Leoncastro que esta propuesta no tiene apoyo y que sólo busca que el proponente tenga las dos imágenes en su firma. Así tampoco es la cosa... --Taichi 〒 23:06 9 jul 2018 (UTC)

@Ignacio2403:, cambiar las políticas para beneficio propio no es lo correcto. En lugar de pedir cambios en las políticas (que pueden tardar meses para cambiarlas), lo mejor es adecuarte a las mismas. Si te dicen que solo se usan una imagen en las firmas, pues solo usa una imagen; si te dicen que necesitas 500 ediciones y 6 meses para votar, debes cumplir eso. Saludos. --Chico⁵¹² 19:05 10 jul 2018 (UTC)

 En contra: no beneficia que la firma de usuario tenga o no imágenes. Por esto que dicen de la carga innecesaria, en mi opinión sería mejor ni poner imagenes en la firma, sobretodo por no saber si la pueden borrar en commons. --Леон Поланко говорит вам и слушает вас 03:40 13 jul 2018 (UTC)

Wikipedia:Fusionar para categorías

No tenemos una política clara para estos casos. Son una minoría pero existir, existen. Lo planteo con un ejemplo, Categoría:Rumania en los Años 1930 vs Categoría:Años 1930 en Rumania. La primera tiene 22 páginas y la segunda 11, pero esta última es la que está enlazada con Wikidata y sigue un formato homogéneo como Categoría:Años 1930 por país. Entonces tengo claro que la segunda es la que debe quedar y la primera no. Pero mi problema es el cómo. Lo primero que toca hacer es trasladar 22 páginas manualmente o con bot (vale, no hay problema). Una vez hecho esto, ¿pido que se borre?, ¿dejo redirección?, ¿realmente es necesario la fusión de historiales? Para categorías da un poco igual quién haya creado la primera o segunda (para artículos sí es muy importante). Alguien me puede ilustrar en esto. En en.wiki tienen en:Wikipedia:Categories for discussion y una plantilla ad hoc solo para categorías en:Template:Cfm (y también para plantillas). Ya de paso aprovecho para recordar que se necesitan manos en para fusionar artículos. Recientemente Leoncastro implementó un sistema para saber desde cuánto hace que un artículo tiene colocada la plantilla y tenemos un backlog o atraso de 3843, con 10 artículos de 2007; 27 de 2008 y 80 de 2009 por poner un ejemplo. Y, no sé, cualquier idea para implementar una política o traducir una guía de procedimiento nos vendría muy bien. Saludos a todos. Triplecaña (discusión) 09:54 11 jul 2018 (UTC)

Hay otra discusión sobre fusión de categorías aquí. --Saludos. Ganímedes 11:51 11 jul 2018 (UTC)

¿Como se haría la fusión de categorías? Esto podría implicar tener que mover con un bot las páginas hacia la categoría principal. --Леон Поланко говорит вам и слушает вас 18:57 14 jul 2018 (UTC)