Wikimedia Meta-Wiki

Hub de Alianzas de Contenido/Metabase/Metabase para datos de capítulos

< Content Partnerships Hub | Metabase
This page is a translated version of the page Content Partnerships Hub/Metabase/Metabase for chapter data and the translation is 100% complete.
Other languages:


Content Partnerships Hub

Improving the Wikimedia movement’s work with content partners

Metabase para datos de capítulos

Libro blanco sobre Metabase

Después de realizar la configuración inicial, y con Metabase en funcionamiento, estábamos listos para comenzar a llenarla con contenido. Elegimos comenzar con algo con lo que estamos familiarizados: la base de conocimiento interna de Wikimedia Sverige. En este estudio, describiremos cómo lo hicimos, centrándonos en el proceso para que otros afiliados que estén considerando utilizar Metabase para este propósito sepan qué esperar.

Contexto

Comenzar con nuestros propios datos era algo que dimos por hecho, ya que entendíamos bien su estructura. Nuestra wiki de capítulo, donde reside todo, es nuestro depósito central de información. La usamos para documentar todo lo relacionado con nuestras operaciones: nuestros proyectos y sus partes constituyentes, como cargas por lotes y actividades, junto con las métricas que enviamos a la WMF y socios; solicitudes de subvenciones e informes de proyectos; planes e informes anuales; actas de las reuniones de la junta directiva; políticas y directrices para los empleados. La información recopilada a lo largo de los años hace posible que otros conozcan nuestro trabajo (después de todo, en el mundo Wikimedia apostamos por la transparencia, especialmente considerando que somos una asociación sin fines de lucro y dependemos en gran medida del apoyo de nuestros miembros y público en general), pero al mismo tiempo también es una referencia para nosotros mismos. Usamos categorías y plantillas para estructurar la información, sin embargo no es exactamente un secreto, que no siempre es fácil (incluso para nosotros) encontrar rápidamente lo que buscamos, especialmente si queremos agregar datos o buscar en diferentes proyectos. Por eso, convertir parte de la información en datos vinculados era un experimento que nos interesaba mucho.

Los miembros de nuestro personal leen y contribuyen a la wiki todos los días, usándola de diferentes maneras según sus funciones. Con eso en mente, comenzamos compilando un conjunto de identidades (persona) basados en miembros reales del personal, para guiarnos en nuestro trabajo de desarrollo de la base de conocimientos. Rápidamente nos dimos cuenta de que nosotros, las pocas personas que trabajamos en el proyecto de Metabase, no tenemos las mismas habilidades y necesidades que nuestros compañeros de trabajo, y que deberíamos facilitarles al máximo la comprensión de qué es y qué no es Metabase, y cómo podrían utilizarla en su trabajo. A lo largo del proyecto, los hemos mantenido actualizados sobre nuestro trabajo, su propósito y sus principales hitos. También tuvimos un par de sesiones en las que cada uno podía contribuir con datos relevantes para su especialidad: crear un elemento para dos para un informe de su autoría o un maratón de edición organizado por ellos. De este modo, nos aseguramos de que se entendiera bien por qué nosotros, como organización, estamos invirtiendo recursos en la creación de Metabase; al mismo tiempo, al observar a nuestros colegas y escuchar sus comentarios, nos hicimos una mejor idea de las necesidades de los distintos tipos de usuarios.

Método

Como se indica en Configurar una Wikibase desde cero, el trabajo inicial de configuración de Metabase concluyó con la construcción de una ontología básica. Se crearon varias propiedades de uso general, como SameAs en Wikidata. También discutimos y acordamos las pautas básicas sobre cómo se deben abordar cuestiones como la duplicación de datos y la compatibilidad con Wikidata y la información personal. Estos se aplican a todos los datos de Metabase, independientemente de su fuente o tema. Cuando entramos en la siguiente etapa y comenzamos realmente a pensar en el contenido, decidimos que la mejor manera de lidiar con el terror de tener una base de datos vacía era dejar que el modelado creciera junto con el contenido. Es decir, comenzamos a pensar en "qué" queríamos ingresar y luego creamos las propiedades y pautas de modelado que tenían más sentido.

En términos prácticos, teníamos un miembro del personal dedicado a la entrada de datos y otros dos (que habían creado la estructura básica de Metabase) brindando apoyo y sirviendo como órgano consultivo. Todos se reunieron regularmente para analizar los acontecimientos recientes y discutir cualquier desafío. En concreto, en las primeras etapas de nuestro trabajo, decidimos que no se crearían nuevas propiedades hasta que los tres estuviéramos de acuerdo de que fueran necesarias y de cómo deberían usarse. Queríamos mantener el modelado lo más simple posible y evitar crear propiedades innecesarias con fines demasiado específicos. Al mismo tiempo que crecía el contenido, documentamos nuestras decisiones en un documento interno compartido, después de lo cual fueron depuradas y crearon la base para las pautas de modelado de wiki en Metabase.

El proceso iterativo demostró que hay mucha diferencia entre planificar y hacer el trabajo en cuestión. No sabíamos de antemano ―de hecho, apenas podíamos imaginarnos― cuánto tiempo nos llevaría y con qué problemas nos encontraríamos. Muchas preguntas que tuvieron que ser discutidas, aparecieron durante el trabajo, especialmente en áreas donde no había ejemplos de Wikidata de estructuras para copiar.

Los datos de WMSE

Cada afiliado tiene su propia forma de gestionar y administrar su trabajo. En Wikimedia Sverige, usamos la siguiente estructura:

  • Áreas temáticas. Desde hace unos años han sido las cuatro siguientes: Habilitación, Acceso, Comunidad, Uso.
  • Proyectos. Cada proyecto pertenece a una de las cuatro áreas temáticas. Además tienen un plazo, un gestor y una fuente de financiación.
    • Proyectos financiados por una subvención operativa (WCF) de la Fundación Wikimedia. La financiación completa para el proyecto se recibe a principios de año. Los proyectos se ejecutan por año calendario y, por lo tanto, el año se incluye en el nombre del proyecto.
    • Proyectos financiados externamente. Una categoría amplia de proyectos, vinculada a una solicitud específica presentada a un financiador en términos de forma, presupuesto y tiempo. Los proyectos suelen abarcar años calendarios y, por lo tanto, el año no está incluido en el nombre del proyecto.
    • Proyectos basados ​​en tiempo. Estos son encargados por otra entidad, comprometiéndose generalmente a entregar un determinado número de horas de trabajo. El trabajo puede estar destinado directamente a la parte encargada o como subcontratista en una solicitud de proyecto.
  • Actividades. Cada actividad, como en el caso de una carga por lotes, un editatón o una presentación realizada en una conferencia, pertenece a un proyecto específico que la financia, y la actividad contribuye al cumplimiento de los objetivos del proyecto.

Resultados

Proyectos

Los proyectos son una parte central de nuestro trabajo, todo lo que hacemos es parte de un proyecto. Es por eso que tenía sentido comenzar con este concepto; nuestro primer trimestre (Q1) fue el proyecto de Soporte para las alianzas de contenido. Después de crearlo, empezamos a pensar en lo que queríamos poder decir sobre este proyecto, y creamos las propiedades necesarias.

Algunos de ellos eran obvios y tenían equivalentes en Wikidata: instancia de, hora de inicio, hora de finalización, etc. Pero también queríamos reflejar cómo está realmente estructurado nuestro trabajo. Para lograr esto se necesitaban las siguientes propiedades y estructuras:

Propiedades de WMSE
Estructura de trabajo de WMSE

Algunos de nuestros proyectos tienen como objetivo editar o añadir contenido a las plataformas de Wikimedia, como por ejemplo organizando editatones o subiendo archivos a Wikimedia Commons. Esto puede indicarse utilizando la propiedad plataforma(s) de Wikimedia afectada(s) en el elemento del proyecto.

Cada proyecto tiene una página dedicada en el espacio de nombres Projekt en la wiki de WMSE, por ejemplo Projekt:Stöd för innehållspartnerskap. Utilizamos la propiedad descrita en página de Wikimedia para vincularla .

Dado que todas las actividades que realizamos forman parte de un proyecto, utilizamos las propiedades tiene parte(s) / parte de para vincularlas entre sí.

Financiamiento - un problema abierto

Un aspecto de nuestro capítulo que nos gustaría poder modelar es nuestro presupuesto y cómo esta financiado nuestro trabajo. Esto incluye información como:

  • Solicitudes de subvención: financiador, subvención, cantidades solicitadas, cofinanciación, solicitantes; incluidas tanto las solicitudes exitosas como las no exitosas.
  • Proyectos y eventos financiados - los aspectos financieros de este proyecto, incluidos: costes finales y fuentes de financiación.
  • Nuestras finanzas anuales generales: tamaño del presupuesto, costes finales/ingresos/resultados, donaciones.

Hemos tenido una serie de discusiones internas sobre cómo abordar este tema de la mejor manera. Lo ideal sería reutilizar las estructuras y las mejores prácticas existentes. Wikidata tiene algunos modelos en torno a las subvenciones de investigación, pero el enfoque se centra principalmente en las subvenciones y los proyectos financiados en lugar de las propias aplicaciones (que son fundamentales para la forma de trabajar de WMSE). Hemos identificado un par de propiedades de Wikidata que podrían ser de interés:

Después de hacer toda esta investigación, terminamos por no modelar nada relacionado con economía o financiamiento en Metabase. La razón de esto es que no queremos construir accidentalmente estructuras que sean perfectas para nuestras propias necesidades pero que no sean útiles para otros afiliados. Como ocurre con todo lo demás, queremos que la ontología sea flexible y fácil de usar para ellos. Para lograr esto, es crucial que recibamos sus comentarios y opiniones: cómo trabajan actualmente y cuáles son sus necesidades. Planteamos este tema en los Wikidata Modeling Days en el otoño de 2023 (grabación de YouTube, diapositivas) y pensamos hacerlo nuevamente en Wikimania en 2024, brindando una oportunidad para que otros afiliados contribuyan y discutan juntos las estructuras necesarias.

Cargas de contenido

Las cargas de contenido ―de archivos multimedia a Wikimedia Commons o de datos a Wikidata― son una de las partes más importantes de nuestro trabajo de alianza de contenido (así como el de muchos otros afiliados). Al mismo tiempo, no ha sido necesario modelarlas en Wikidata y, por lo tanto, no hay mejores prácticas de las que aprender; tuvimos que modelarlas desde cero. Por esta razón, merecen una atención especial aquí. Usaremos como ejemplo el elemento 2021 imágenes de 2021: subido a través del Museo Röhsska.

Decidimos que queríamos expresar las siguientes cosas sobre una carga de contenido:

  • Cuándo se realizó.
  • A cuál de los proyectos de WMSE pertenecía: para hacer posible la búsqueda de información específica del proyecto, o compilar métricas para cada uno de nuestros proyectos.
  • En qué plataforma Wikimedia se realizó.
  • Qué tipo de recursos se subieron. Esto es especialmente conveniente para las cargas de contenidos multimedia, ya que Wikimedia Commons puede albergar imágenes, archivos de audio, vídeos, archivos pdf, etc. En Wikidata, podemos trabajar con elementos o lexemas, por lo que también deberíamos ser capaces de mantenerlos separados.
  • Cuántas entidades se han subido. Eso son elementos o lexemas en Wikidata, o archivos en Wikimedia Commons.
  • De dónde proceden los recursos subidos, para saber con cuántos archivos contribuyó un determinado museo.
  • Categoría de Commons. Para que podamos localizar fácilmente los archivos subidos.
  • Enlace a la página correspondiente en la wiki de WMSE. Nuestra wiki es donde informamos de las métricas de todas nuestras cargas.

Tras un periodo de pruebas, nos decidimos por las siguientes propiedades y estructuras:

La razón por la que utilizamos tanto espacio de nombres como tipo de recurso es que el espacio de nombres de Archivos en Wikimedia Commons puede albergar diferentes tipos de archivos: grabaciones de audio, fotografías, vídeos, etc. En Wikidata, los elementos y lexemas pertenecen a espacios de nombres diferentes, aunque ambos sean datos enlazados. A veces puede ser útil conocer el desglose: no sólo cuántas entidades se subieron, sino también de qué tipos.

Ten en cuenta que este modelado puede adaptarse a cargas que afectan a múltiples plataformas de Wikimedia. Un ejemplo es la realización de proyectos en los que subimos varios cuadros digitalizadas a Wikimedia Commons, creando al mismo tiempo sus respectivos elementos de Wikidata. Dado que esto sucede simultáneamente, o al menos dentro del mismo espacio conceptual (no los consideramos proyectos separados; es obvio que los cuadros deben tener elementos de Wikidata), no tiene sentido separarlos. Véase carga de WiR, Agencia Sueca de Artes Escénicas como ejemplo de una carga de contenido que abarca varios proyectos y tipos de recursos de Wikimedia.

Documentos

Wikimedia Sverige, como cualquier organización, produce una gran cantidad de documentos, tanto para uso interno como externo. Como mencionamos anteriormente, queremos mantener Metabase lo más sincronizado posible con Wikidata, y eso incluye los tipos de documentos. Pensamos que sería sencillo, pero al parecer no era tan fácil encontrar equivalentes de Wikidata para todos ellos. Por ejemplo, a menudo escribimos o contribuimos a remissvar, un documento que enviamos al parlamento donde damos nuestra opinion sobre alguna ley nueva que quieren aprobar. Wikidata tiene un elemento para consultas, que es el proceso en el que el parlamento le pide a otros actores su opinión sobre las leyes propuestas, no el documento ―¿una respuesta a la consulta?― en sí mismo.

No nos sorprenderá que otros afiliados encuentren desafíos similares al asignar a Wikidata los tipos de documentos con los que trabajan. Habrá diferencias a nivel local en cómo se definen los tipos de documentos. Una solución obvia es corregir o desarrollar los datos en Wikidata, lo que beneficiaría a todos, no sólo a los usuarios de Metabase. Decidimos no hacer eso como parte de nuestro trabajo experimental, ya que requeriría tiempo y conocimiento del dominio (y como todos los editores de Wikidata saben, es fácil caer en la tentación de seguir editando, hasta llegar al punto en el que uno pierde toda noción de lo que estaba haciendo en primer lugar); además, al "no" editar datos en Wikidata para contribuir mejor a Metabase, dejamos claro que tales problemas pueden surgir. Creemos que los editores de Metabase que no estén limitados por el tiempo puedan sentirse motivados a mejorar los datos en Wikidata aprovechando que están en eso, dependiendo de su experiencia, o al menos a plantear los problemas en comunidades de editores adecuadas.

Conclusiones

¿Metábase: un complemento o un reemplazo de las estructuras actuales?

Una gran pregunta que sigue sin tener respuesta es ¿hasta qué punto Metabase puede reemplazar o complementar nuestras estructuras actuales? Si bien solo podemos responderla por nosotros mismos, otros afiliados estarían haciendo consideraciones similares. Las necesidades de cada uno de ellos son diferentes.

En el caso de WMSE, nuestra wiki es una parte central de nuestro flujo de trabajo. La utilizamos para almacenar no sólo información que podría convertirse fácilmente en datos abiertos enlazados, como las métricas sobre nuestras actividades que presentamos a nuestros financiadores, sino también un gran número de documentos, como políticas y pautas, que deben ser fáciles de acceder y navegar. Esta información se remonta muchos años atrás, con la wiki cumpliendo la función de un archivo a medida que los empleados van y vienen. Trasladarla a una plataforma distinta, como el espacio de nombres sin datos en Metabase, requeriría mucho trabajo, por lo que no es algo que queramos hacer solo porque sí: los beneficios tienen que compensar la molestia. Con un historial tan grande a sus espaldas, deshacerse de nuestra wiki y sustituirla por una plataforma diferente no es realista; seguir con el flujo de trabajo que hemos estado utilizando exitosamente durante años tiene sus ventajas desde una perspectiva histórica, ya que facilita a los futuros usuarios orientarse en nuestro repositorio de conocimientos.

Creemos que sería posible algún tipo de división, donde los datos que podrían almacenarse como datos enlazados residen en la Metabase y se muestran en la wiki de WMSE (displayed está haciendo la mayor parte del trabajo, lo cual mencionaremos en un momento). Por ahora, como solo estamos experimentando, el personal no tiene la obligación de informar sus actividades en Metabase: la wiki de WMSE todavía está donde pertenece. ¿Qué debemos hacer en el futuro?

Es imposible pensar en las aplicaciones futuras de Metabase para nuestros datos internos sin preguntarnos si Metabase debería convertirse en el "único" lugar para los datos. ¿Debería informarse también en la wiki de WMSE, duplicando la carga de trabajo y aumentando el riesgo de discrepancias? Teniendo en cuenta el hecho de que muchas páginas en nuestra wiki están muy estructuradas ―presentamos las métricas de nuestro trabajo utilizando plantillas y diseños de página predefinidos, asegurándonos de que siempre tengan el mismo aspecto independientemente de quién las introduzca― tiene sentido pensar en posibles formas de automatizar el flujo de datos desde la wiki a la Metabase. Un bot podría transferir los datos, mantenerlos actualizados cuando se realicen correcciones en la wiki y notificarnos sobre cualquier discrepancia causada por ediciones manuales en la Metabase. Por supuesto, esto sólo es posible gracias a la rígida estructura de nuestra infraestructura de informes métricos: cada afiliado tendrá sus propios desafíos y consideraciones.

Sin embargo, por el momento esto no es más que un experimento. No existe una forma sencilla de mostrar el contenido de una wiki de Wikibase Cloud en una wiki de Wikimedia. Existen soluciones adecuadas para Wikidata, donde los datos se pueden transcluir en otras wikis de Wikimedia utilizando plantillas, como Plantilla:Ficha de persona/Wikidata y sus equivalentes localizados, o Listeria. Esta, en particular, es una herramienta muy interesante desde el punto de vista de los usuarios y administradores de Wikibase Cloud. Se usa ampliamente en las plataformas Wikimedia, por lo que si se adaptara para ingerir datos de Wikibase Cloud, el umbral para que los usuarios empezaran a utilizarla sería bajo. Podría convertirse en la clave para facilitar el flujo de datos desde las instancias de Wikibase Cloud a las wikis de Wikimedia, haciendo que la plataforma sea más útil y relevante para los nuevos usuarios.

Somos conscientes de que no podemos pedirle al personal que use Metabase si no han sido capacitados adecuadamente, y aunque la mayoría tiene al menos conocimientos básicos de Wikidata, están lejos de ser wikidatistas experimentados, algo que reduce significativamente el umbral para comprender y usar Metabase. Si bien tuvimos una introducción básica al proyecto para todo el personal (saben por qué se está desarrollando la plataforma y se les animó a intentar editarla), sabemos que se necesitaría tiempo y esfuerzo para que se sientan cómodos usándola como parte de su rutina diaria, como ocurre con cualquier herramienta digital nueva.

Primeros pasos como organización

Basándonos en nuestro trabajo con los datos de Wikimedia Sverige, podemos hacer algunas generalizaciones sobre los desafíos que podría enfrentar un afiliado al embarcarse en un viaje similar.

En primer lugar, habría que empezar por examinar los datos disponibles. ¿Qué tipo de información se ha escrito en primer lugar y hasta dónde llega? Esto determinará lo que es posible lograr en Metabase. Será útil observar cómo se modelan elementos similares, como presentaciones o eventos que ya están en Metabase, y reflexionar sobre cuántas de estas estructuras se pueden reutilizar. Es posible que se necesiten propiedades y estructuras específicas para afiliados, del mismo modo que WMSE necesita el ID de proyecto de WMSE y las áreas temáticas. La fortaleza de Metabase, en comparación con Wikidata, es que nos permite experimentar y crear fácilmente las propiedades que necesitamos aunque no sean de interés para usuarios externos.

Luego, se deberá desarrollar un flujo de trabajo para la fase de introducción de los datos. ¿Quién debe hacerlo y qué recursos tienen a su disposición? Si el responsable de esta tarea ya está familiarizado con Wikidata, la dificultad de su trabajo será mucho menor. Aún más si puede usar QuickStatements ―funciona en Metabase― y si sabe cómo analizar los datos de origen (por ejemplo, para extraer información del wikitexto en la wiki del afiliado). Ten en cuenta que incluso si hay una persona dedicada a la introducción de datos, es posible que necesite el apoyo de otros miembros del personal para acceder al conocimiento de la organización que no está explícitamente indicado en el material de origen.

De hecho, uno de los desafíos que encontramos al copiar datos de la wiki del capítulo fue que la información no siempre era clara. Las notas sobre un evento o una actividad eran caóticas y difíciles de entender para las personas que no participaron en el evento, y piezas de información cruciales —como por ejemplo, el tema de una presentación— eran difíciles de localizar. Como todos sabemos, cuando documentas un evento que organizaste tú mismo, puede suceder que omitas cosas que son obvias para ti, pero que no lo serán para tus colegas (o para ti...) en cinco años. En algunos casos, pudimos pedirle aclaraciones al miembro del personal a cargo de la organización del evento, pero no podemos asumir que este siempre será el caso. De esta manera, el experimento de Metabase proporcionó una lección adicional: debemos ser más conscientes al escribir cosas en nuestra wiki, para que puedan entenderse más tarde.

La documentación es crucial. En nuestro caso, documentar nuestras opciones de modelado tenía dos propósitos. En primer lugar, por supuesto, queríamos que los futuros colaboradores de Metabase pudieran entender el modelado y utilizarlo (o discutirlo y cambiarlo). Pero pronto nos dimos cuenta de que la documentación era igual de importante para nosotros. La memoria humana es poco fiable, y no tarda mucho en desviarse accidentalmente de las pautas de modelado que nosotros mismos ideamos.

El lugar de Metabase en el flujo de trabajo de una organización

Teniendo esto en cuenta, un afiliado interesado en incluir Metabase en su trabajo diario debe considerar cuidadosamente los requisitos previos y las consecuencias. ¿Quién debe aportar datos a la plataforma, con qué frecuencia y qué papel debe desempeñar Metabase a nivel organizacional?

Si bien sería beneficioso para todos en la organización entender qué es Metabase y cómo se puede utilizar, puede que no sea necesario que todos contribuyan a ella. Después de todo, cada miembro de una organización tiene su función y su responsabilidad (como realizar editatones o desarrollar planes financieros). Todos deberían poder concentrarse en sus tareas principales con la máxima productividad sin tener que aprender otra herramienta de generación de informes. Todas las personas son diferentes; algunos se sienten más cómodos trabajando con datos enlazados, a otras les resulta más fácil contribuir a una wiki o escribir documentos de texto. Además, cuando personas que no se sienten cómodas con los datos enlazados contribuyen a la recopilación de datos, la calidad de los mismos puede variar significativamente. Esto significa que hay que dedicar más tiempo y recursos a limpiar y verificar los datos, lo cual es ineficiente y costoso.

Contar con un miembro del personal dedicado a la introducción de datos podría proporcionar una solución a este problema. Un capítulo grande que genere una gran cantidad de datos y material de conocimiento que deba catalogarse en Metabase podría contratar a alguien para esta tarea, pero podría no ser realista desde el punto de vista económico en una zona de alto costo de vida. Otra posibilidad es que alguien (un miembro del personal o un voluntario) ofrezca sus conocimientos de Metabase como un servicio a varios afiliados, en nombre de un centro temático o regional. Gracias a su trabajo regular en Metabase, tendría una buena visión general de las estructuras y del modelado, asegurándose de que la calidad de los datos sea consistente entre las fuentes, algo que es difícil para alguien que contribuye de vez en cuando, y solo con datos relevantes para su experiencia particular. Con una estructura y una responsabilidad centralizadas, el riesgo de que se pasen por alto datos valiosos (como información sobre eventos organizados por voluntarios o material de desarrollo de capacidades no elaborado por el personal afiliado) es menor. Además, esta persona podría brindar orientación y apoyo a los usuarios de Metabase, como desarrollar consultas SPARQL para extraer y analizar datos específicos, así como desarrollar materiales instructivos y difundir el conocimiento sobre la plataforma en conferencias y otros eventos.

También está la cuestión de la sostenibilidad. Introducir datos históricos puede ser un proyecto único, pero una vez hecho, hay que decidir con qué frecuencia se deben actualizar. En WMSE, nuestro objetivo es añadir métricas a la wiki lo antes posible, tanto para mantener actualizados a los miembros de la asociación como para asegurarnos de que no se nos olvide nada cuando llegue el momento de informar nuestros resultados a la WMF, nuestros socios y otros patrocinadores. Pero al mismo tiempo ¿qué beneficios tendría actualizar Metabase? Esto depende, por supuesto, del papel que queramos que tenga la plataforma en nuestro trabajo. Si se trata sólo de un depósito de conocimientos con capacidad de búsqueda, en lugar de una parte crucial de nuestras operaciones diarias, podría tener sentido actualizarlo sólo periódicamente. Esa introducción de datos podría ser realizada por un miembro del personal especializado, familiarizado con la plataforma, en lugar de ser realizada por todos: lo que reduciría la carga mental de sus colegas, al no verse obligados a aprender otra plataforma de generación de informes.

En conclusión, si bien es posible que un afiliado que quiere comenzar a utilizar y contribuir activamente a Metabase pueda sentirse intimidado por la inversión necesaria de tiempo y recursos, existen formas de reducir los requisitos en una sola organización. Aunque se puede capacitar a todos los miembros del personal sobre lo que es Metabase, y alentarlos a contribuir si desarrollan un interés, existen soluciones alternativas para el ingreso de datos que no requieren grandes inversiones. Si queremos que Metabase se convierta en un Hub para el conocimiento del Movimiento, tendría sentido establecer un servicio centralizado para la introducción y mantenimiento de datos en el que puedan confiar los afiliados y voluntarios, sin exigir inversiones a los afiliados de comunidades infrarepresentadas que disponen de menos recursos.

Retrieved from "https://meta.wikimedia.org/w/index.php?title=Content_Partnerships_Hub/Metabase/Metabase_for_chapter_data/es&oldid=27522904"