Usuario:Crath

Mi participación en Wikipedia es la de un colaborador activo. Con esto no quiero decir que patrulle páginas y contribuciones en busca de contenido que pueda marcar para borrar (o simplemente eliminar) debido a alguna supuesta contravención de las reglas y convenciones de Wikipedia (WP). Desde mi primera contribución en 2007, me ha quedado claro que muchos de los editores de WP más activos en realidad no contribuyen a WP; más bien, de alguna manera han llegado a creer que la eliminación de contenido de alguna manera suma valor a WP. Sí, hay muchos vándalos que trollean las páginas de WP y pintan grafitis que necesitan ser borrados -y la limpieza de esta destrucción gratuita es valiosa para WP- sin embargo, muy a menudo individuos bien intencionados están sumando al cuerpo de conocimiento contenido en WP, y es la eliminación mal intencionada de este contenido a lo que me refiero.

Por ejemplo, cuando un colaborador ha publicado material nuevo en el lugar equivocado, en lugar de eliminar la información y regañar al colaborador, el editor debería, en cambio, trabajar con el colaborador para mover la información al lugar correcto o simplemente mover la información él mismo.

Hace poco leí la página personal de un editor de WP que era miembro del equipo de New Page Police (NPP). Ese editor promovía descaradamente el comportamiento de eliminar páginas en lugar de intentar contribuir a ellas para que pudieran permanecer. Simpatizo con la idea de que muchas páginas nuevas son basura, pero empezar a evaluar cada página nueva sin motivación para contribuir a su relevancia es algo ajeno a la forma en que creo que deberían comportarse los editores de WP.

Un excelente ejemplo de esta eliminación de contenido es la confusión que han generado los editores de WP sobre (a) el contenido y (b) la organización del contenido. Las reglas sobre qué información se puede capturar en WP se centran en las "páginas", lo que significa que la denominada información no destacable se puede añadir a una página existente, pero puede que no tenga una página propia. Si bien esta idea es válida a veces, con la misma frecuencia no lo es. Por ejemplo, cuando un músico ha publicado varios álbumes a lo largo de una larga carrera, pero solo un subconjunto de ellos ha vendido millones, las reglas de notabilidad de WP establecen que solo los lanzamientos que han vendido millones pueden tener una "página" propia; sin embargo, estas mismas reglas recomiendan que el contenido no destacable se añada a la "página" principal del artista. Esto hace que la página principal se vuelva excesivamente larga.

Esta forma de pensar confunde organización con contenido. Si el contenido no es adecuado para su inclusión en una página propia, entonces no debería simplemente trasladarse a otro lugar: o bien califica para su inclusión en WP o no. Nota: en aras de un contenido bien organizado, la creación de páginas mayoritariamente vacías es contraproducente, y por eso, como parte de mantener WP bien organizado, tiene sentido trabajar para que cada "página" contenga una cantidad razonable de información. Pero esta motivación de organización es muy diferente a una evaluación de notabilidad (que es una evaluación de si cierta información califica para su inclusión en WP).

Recientemente, he notado que los Wikidelecionistas han comenzado a implementar una nueva táctica en su afán por imponer su visión del mundo en WP: la redirección . Un Wikidelecionista reemplazará el contenido de una página entera con un comando de redirección. Esto hace que la página sea inaccesible para el usuario promedio para su posterior edición. Esta utilización de las páginas de WP como arma se hace para imponer arbitrariamente un resultado sin permitir que el contenido en disputa exista durante un período de tiempo que permita una discusión más amplia.

Esta semana, utilicé texto de dominio público en una nueva página de WP que creé. En un día, los Wikideletionistas marcaron mi texto como una violación de derechos de autor. El problema de fondo era que los sitios web con derechos de autor también habían publicado ese texto de dominio público, por lo que ellos (los Wikideletionistas) clasificaron mi texto como infractor de los sitios que también habían copiado el texto de dominio público. Para empeorar las cosas, había citado mi texto con una referencia a la fuente de dominio público original del texto, pero los Wikideletionistas no se molestaron en leer mis citas... tal es su pereza. Si bien finalmente prevalecí y el texto que publiqué fue restaurado, fue una pérdida innecesaria de mi tiempo porque los Wikideletionistas no se molestaron en contribuir realmente a Wikipedia.

Otro mal hábito que tienen algunos usuarios de Wikipedia es quejarse o criticar en lugar de contribuir. Por ejemplo, recientemente, en la página HP-41C un usuario notó en la pestaña Discusión que un mensaje de error en particular era incorrecto: el usuario criticó el contenido en lugar de simplemente corregir el error. No tengo forma de saber la motivación del usuario para no hacer clic simplemente en el botón [Editar] y realizar la corrección; pero, este comportamiento (desafortunadamente) no es inusual. En el tiempo que el usuario tardó en quejarse en la pestaña Discusión, podría haber hecho la corrección y mejorado el contenido de Wikipedia; en cambio, perdió su tiempo y creó trabajo para otra persona.

Recientemente, Wikipedia (WP) decidió dejar de admitir el formato automático de fechas. En su lugar, ahora se les pide a los editores que codifiquen las fechas en un formato específico de los Estados Unidos o en un formato que no sea de ese país, en el que el mes se escribe completo como una palabra. Otro editor de WP tuvo la amabilidad de indicarme algunas de las discusiones históricas sobre este tema:

• Desuso de la vinculación de fechas
• Usuario:Dabomb87/Resumen de las RFC que vinculan fechas
• Wikipedia:Solicitudes de arbitraje/Desvinculación de fecha

Al revisar la discusión, llegué a la conclusión de que quienes la impulsan no tienen ningún interés en servir a los lectores; más bien, tienen sus perspectivas y preferencias personales en mayor estima que los lectores para los que existe WP. Un buen diseño de UX impulsaría la presentación del material en un formato fácil de leer y utilizaría el poder de las computadoras que realizan la presentación en apoyo de ese diseño de UX. La subcomunidad de WP que impulsó la decisión de la fecha ignoró conscientemente a los lectores y la capacidad de las computadoras para respaldar un buen diseño de UX.

Además, al examinar el desafortunado intento de la comunidad de apoyar el formato automático de las fechas, es evidente que la comunidad no buscó la opinión de un experto sobre cómo se debería construir el marcado de entrada (es decir, un diseñador de lenguaje de programación). El equipo decidió sobrecargar el operador de enlace de doble corchete para indicar dónde se debían formatear las fechas. Ese formato automático debería haberse realizado utilizando un nuevo operador de llaves. La ironía de la situación actual es que esta nueva regla que requiere que los editores escriban manualmente la fecha completa viene con un nuevo operador de llaves que el editor debe utilizar para especificar el formato en el que se deben introducir esas fechas escritas manualmente.

Me parece que el enfoque más racional y amigable para el lector es especificar siempre las fechas en formato YMD y luego hacer que el motor de cómputo de WP las reformatee (en tiempo real mientras se muestra la página) según la preferencia del lector. En mi humilde opinión: dado que Wikipedia es una enciclopedia internacional, las fechas dentro de ella deben codificarse de conformidad con ISO 8601 . La forma en que se presentan esas fechas a un lector debe estar bajo el control de ese lector. Después de todo, WP no es un documento impreso estático: cada página se formatea dinámicamente en tiempo real cuando el usuario accede a la página. Que WP imponga un formato de fecha a los lectores es descortés e irrespetuoso.

Un editor de WP me expresó la opinión de que "ISO 8601 es una elección horrible para Wikipedia porque requiere que todas las fechas estén en el calendario gregoriano y no permite fechas anteriores a 1583 sin pedir primero permiso a los lectores, lo cual es completamente impráctico en el caso de Wikipedia".

• Re: "...no permite fechas anteriores a 1583 sin pedir permiso primero a sus lectores..." Esta postura es un completo malentendido y una caracterización errónea del requisito de la norma. La norma exige que cuando dos partes (o programas) intercambian fechas anteriores a 1583, las partes deben acordar un entendimiento común de cómo se manejarán esas fechas; ya que la norma en sí no impone un entendimiento de esas fechas. Este tipo de malentendido es uno que una persona no técnica podría extraer de la lectura de una norma técnica. Para que WP utilice ISO-8601 como su norma de fechas, lo único necesario para las fechas anteriores a 1583 es ​​que WP documente cómo se manejan esas fechas para que los lectores sepan cómo interpretarlas. Esto no es diferente del uso actual de fechas de DMY/MDY: WP simplemente le dice al lector cómo interpretar las fechas que aparecen en una página en particular.
• Re: "fechas anteriores a 1583..." No hay diferencia semántica entre escribir "1 de enero de 1500" o "1 de enero de 1500" o "1 de enero de 1500", y la objeción del editor no tiene sentido. Todos entendemos que hay diferentes calendarios históricos, pero la solución es simplemente indicar que todas las fechas de WP están en formato gregoriano o permitir que se agregue una etiqueta de marcado que permita agregar fechas no gregorianas a las páginas (para que el motor de formato de WP pueda cambiar el formato para los lectores según sus preferencias).

Las computadoras existen para reducir la carga de trabajo de las personas. Lo último que supe es que las páginas de WordPress se formateaban con una computadora; por lo tanto, no hay razón para que la computadora delegue trabajo a los editores de WordPress.

Hace más de 10 años, algunos editores de WP discutieron sobre el tema del formato automático de fechas . Aquellos que estaban en contra de seguir permitiendo el formato automático de fechas argumentaron que no era posible formatear siempre correctamente una fecha para la siguiente frase (donde el componente de fecha está dentro de una etiqueta de formato): "Los ataques del 11 de septiembre de 2001...". Cuando se utilizan fechas de formato largo no estadounidenses, esta frase es "Los ataques del 11 de septiembre de 2001...". Esta afirmación es que una etiqueta por sí sola no puede formatearse correctamente.

La falla en la lógica de los detractores es pensar que debería haber una etiqueta de fecha para gobernarlos a todos . Cualquiera que esté familiarizado con TeX sabrá que Donald Knuth permitió algunos casos extremos que debían manejarse manualmente a medida que TeX convertía el marcado en páginas legibles para humanos (por ejemplo, no había espacio adicional después de algunos puntos). Este mismo requisito para el tratamiento manual de casos extremos también se aplicaría a las fechas formateadas automáticamente en WP: por ejemplo, para casos excepcionales donde se debe omitir la coma final de las fechas con formato estadounidense, esto se indicaría mediante la etiqueta de fecha.

En las discusiones históricas, otra objeción planteada al formato automático de fechas es que WP no sabe cómo formatear las fechas para los usuarios que no han iniciado sesión. Al igual que con las otras objeciones, esta también es engañosa: WP puede usar fácilmente el seguimiento geográfico para determinar la ubicación general de un usuario y luego formatear las fechas de acuerdo con la configuración regional del usuario (al igual que Netflix determina desde qué país está viendo un espectador). WP puede volver a AAAA-MM-DD si no se puede establecer una ubicación confiable.

Como mencioné algunos párrafos más arriba, el verdadero problema parece ser que quienes hacen recomendaciones y toman decisiones sobre el marcado del lenguaje informático no tienen experiencia para hablar sobre el tema.

Al igual que la presentación de fechas, los puntos suspensivos son otro ejemplo de un "estándar" de Wikipedia que no cumple con los requisitos. Según MOS:ELLIPSIS , los editores de Wikipedia deben utilizar tres puntos separados por un espacio indivisible, en lugar de un carácter de puntos suspensivos. La razón de este enfoque se explicó en el Manual de estilo de WP y se puede resumir como "algunas tipografías contienen un carácter de puntos suspensivos mal dibujado, por lo que utilizaremos tres puntos en su lugar". El autor de la publicación de Talk afirma que los puntos suspensivos no son un elemento tipográfico único; sin embargo, dado que todas las guías de estilo mencionadas en la propia página de puntos suspensivos de Wikipedia requieren el uso de un solo carácter o de tres puntos que se mantienen juntos como si fueran un solo carácter, cualquier sugerencia de que los puntos suspensivos no son un elemento tipográfico atómico es engañosa.

Por lo tanto, una vez más, el enfoque de Wikipedia consiste en evitar el uso de ciclos de cálculo y utilizar un método manual para implementar un requisito de composición tipográfica. Un enfoque mejor sería pedir a los editores de Wikipedia que codificaran puntos suspensivos como marcado y luego dejar que el motor de visualización decida cómo representar el carácter. El enfoque de Wikipedia olvida que los usuarios ya no utilizan máquinas de escribir; en otras palabras, la decisión de estilo MOS:ELLIPSIS está estancada en la era preinformática.

Una última observación: nadie debería sugerir que el uso de una etiqueta de marcado de puntos suspensivos crea una carga para los editores de Wikipedia: el editor de artículos de Wikipedia se puede codificar fácilmente para transformar tres puntos en la etiqueta, de la misma manera que MS Word transforma automáticamente tres puntos en un carácter de puntos suspensivos.

Otra decisión desafortunada tomada por editores ignorantes de Wikipedia está documentada en Manual_of_Style#Section_headings y se resume en la frase inicial de esa página: "Los encabezados de sección deben... presentarse en mayúsculas oracionales". La aparente justificación de esta decisión es que "Wikipedia evita el uso innecesario de mayúsculas". Al igual que con las otras decisiones mal informadas que he documentado en esta página, la decisión de no utilizar mayúsculas en los títulos solo sirve para hacer que Wikipedia sea "menos", y no "más". La mayúscula en los títulos no es, por definición, un ejemplo de uso innecesario de mayúsculas; más bien, sirve para proporcionar otra pista visual al lector de que el título es un título y no el texto de un artículo. Además, el hecho mismo de que Wikipedia utilice la frase "en mayúsculas oracionales" significa que los editores que tomaron la decisión entienden que existe una diferencia entre oraciones y títulos, y que estaban decidiendo conscientemente no formatear los títulos como títulos (¡¡qué extraño es eso!!).

Esta sentencia es otro ejemplo de la observación de Robert A. Heinlein de que "para evaluar la inteligencia de un comité, hay que dividir el coeficiente intelectual de su miembro más estúpido por el número de miembros".

Hoy tuve un intercambio desafortunado con otro editor de WP. Una gran cantidad de páginas de WP han usado una imagen que dice ser una foto de un Big Mac, pero se puede ver fácilmente que NO es un Big Mac (no pondré un enlace a ella porque eso le daría legitimidad en el sistema de WP). La imagen es ciertamente la de una hamburguesa, pero no es un Big Mac real de McDonald's. Había editado varias páginas que usaban esa imagen y o bien había eliminado la imagen o bien había eliminado las palabras "Big Mac" de la etiqueta de la imagen.

El otro editor de WP revirtió mis ediciones y su razonamiento fue que la imagen en realidad es una Big Mac, haciendo referencia a la declaración del cargador original de que la hamburguesa era una Big Mac. La declaración del cargador no cambia el hecho de que la imagen no muestra una Big Mac como la que vende McDonald's: el queso y los pepinillos de la hamburguesa están encima de una hamburguesa de carne en lugar de debajo de ella, lo que muestra claramente que la hamburguesa NO es una Big Mac.

Esta semana, me encontré con otro ejemplo de por qué WP es catalogado como poco fiable: corregí información errónea y cité fuentes fiables (es decir, los Archivos Nacionales de Estados Unidos), pero los editores siguieron diciéndome que estaba equivocado. Todos estos editores hicieron referencia a un único vídeo de YouTube como prueba de que estaba equivocado. Afortunadamente, todos los editores finalmente cedieron y permitieron que mi texto se mantuviera; pero el hecho de que todos creyeran que YouTube era una fuente creíble es un problema real.

Vea mi página de inicio para ver mi cara pública .