Gobernanza¶
El Estándar de Datos de Contrataciones Abierta (OCDS, por sus siglas en inglés) tiene muchas partes interesadas: gobiernos (entidades compradoras, autoridades de monitoreo y supervisión, gerentes de proyectos y formuladores de políticas), el sector privado y organizaciones de la sociedad civil. Las necesidades y los intereses de estas partes interesadas, como publicadores y usuarios de los datos, son variados. A medida que el OCDS se desarrolla con el tiempo, con versiones actualizadas y nuevas características, es importante que un grupo diverso de partes interesadas se involucren en el proceso.
Este documento establece los procesos de revisión para OCDS.
Gestión y gobernanza¶
La Open Contracting Partnership (OCP) se estableció como una organización sin fines de lucro independiente a principios de 2015 y actúa como administrador principal del Estándar de Datos de Contrataciones Abiertas.
OCP está dirigida por un director ejecutivo y cuenta con el apoyo de un comité consultivo de múltiples partes interesadas, con representación de gobiernos, organizaciones multilaterales, académicos, ONGs y empresas.
En la búsqueda de consenso y un proceso guiado por la comunidad, los suscriptores a la lista de discusión standard-discuss@open-contracting.org (puede unirse enviando un mail a standard-discuss+subscribe@open-contracting.org) y aquellos observando e interactuando con el repositorio del estándar en GitHub se les informará en todas las etapas sobre revisiones planeadas al OCDS, y se les dará oportunidades claras y oportunas para aportar y comentar.
Para asegurar la pertinencia, la calidad y la implementación efectiva de las actualizaciones propuestas al estándar, las versiones nuevas están sometidas a un proceso de revisión por pares con revisores invitados de las comunidades de publicadores y usuarios, en un proceso abierto de revisión.
Un reducido grupo de trabajo de gobernanza del estándar, formado por representantes del equipo de OCP, el consejo asesor multisectorial, y el equipo de desarrollo del estándar será responsable de dar la aprobación final a las actualizaciones formales del estándar y de asegurar que los procesos en este documento han sido llevados a cabo apropiadamente.
En el futuro, el Open Contracting Data Standard puede ser sometido a un organismo formal de normalización, como el World Wide Web Consortium, u OASIS. Antes de tomar esa decisión, se buscará establecer un modelo de gobernanza guiada por la comunidad basado en procesos abiertos y bajo consenso para actualizar el estándar.
Propiedad intelectual¶
El Estándar de Datos de Contrataciones Abiertas es Propiedad Intelectual de la Open Contracting Partnership. El esquema está licenciado bajo la licencia Licencia Apache 2.0, con la documentación que lo acompaña bajo una licencia Creative Commons Atribución 4.0 Internacional donde se indica.
Los contribuidores al estándar acuerdan transferir cualquier derecho de autor sobre sus contribuciones a Open Contracting Partnership a través de un proceso de acuerdo de contribución, para que esas contribuciones se mantengan en fideicomiso como parte del estándar.
No se incluirá en el estándar ningún contenido que infrinja derechos de propiedad intelectual de terceros.
Principios de gobernanza¶
Estamos comprometidos con los principios de Open Stand para el desarrollo de estándares. El Estándar de Datos de Contrataciones Abiertas se desarrollará con:
Debido proceso. Decisiones tomadas con equidad y justicia entre los participantes. A través de un proceso abierto para la presentación de problemas, extensiones y solicitudes de actualizaciones, ninguna de las partes dominará o guiará el desarrollo estándar. Todos los procesos serán transparentes y existirán oportunidades para apelar decisiones. Los procesos para la revisión periódica del estándar y su actualización están bien definidos en este documento.
Amplio consenso. El proceso permitirá que todas las opiniones sean consideradas y tratadas, de tal manera que el acuerdo pueda ser encontrado a través de un rango de intereses.
Transparencia. Proveeremos un aviso público anticipado de las actividades propuestas para el desarrollo de estándares, el alcance del trabajo a realizar y las condiciones para la participación. Se facilitarán registros fácilmente accesibles de las decisiones y los materiales utilizados para alcanzar esas decisiones. Los periodos de comentarios públicos serán proporcionados antes de la aprobación y adopción de las estándares finales.
Balance. Las actividades de estándares no estarán exclusivamente dominadas por ninguna persona en particular, compañía o grupo de interés.
Apertura. Los procesos del Open Contracting Data Standard están abiertos a todas las partes interesadas e informadas.
Versionamiento y proceso de actualización¶
Con el tiempo, se necesitarán cambios en el estándar, incluyendo la adición de nuevos códigos y campos, y ocasionalmente cambios en los campos y estructuras existentes.
El proceso de revisión está diseñado para asegurar que:
Se identifican y consideran las consecuencias de cualquier cambio para las diferentes partes interesadas;
Está claro por qué son necesarios los cambios, y que hay un amplio apoyo para cualquier cambio propuesto;
Los cambios son fáciles de identificar y son transparentes, y los publicadores, usuarios e intermediarios tienen una documentación clara que les permite actualizar sus datos y herramientas;
Los cambios en el esquema de OCDS serán hechos periódicamente, incrementando el número de versión del estándar para indicar que se han hecho cambios, y manteniendo un registro de cambios.
La página web de la documentación se compone de contenido normativo (la parte prescriptiva de OCDS) y contenido no-normativo (la parte no-prescriptiva, o ‘descriptiva’ de OCDS) como se define y describe en la Política de Contenido y Cambios Normativos y No Normativos. Esta política establece qué cambios a qué partes de la documentación deben de involucrar el proceso de revisión descrito más abajo (ej. añadir nuevos campos al esquema de entrega), y qué cambios pueden hacerse sin el proceso de revisión (e.j. corregir errores de tipeo en las descripciones de los campos, o actualizar la guía de implementación).
Versiones¶
Distintos ramas del estándar se mantendrán dentro de Github para cada versión.
Las ramas pueden estar en uno de dos estados:
Desarrollo- se indica por un sufijo -dev (e.j. 1.1-dev) Tanto el esquema como la documentación en una rama de desarrollo pueden ser actualizados y deben ser implementados de forma experimental.
Live - sin sufijo (e.j. 1.0) Sólo la documentación puede actualizarse en una rama "live". Los cambios a la documentación deben revisarse para asegurar que no se hicieron cambios al significado del estándar.
Las prácticas de Versionamiento Semántico se utilizarán para distinguir entre:
Versiones mayores que realizan cambios incompatibles hacia atrás (ej. 2.0)
Versiones menores que añaden funcionalidades que son compatibles hacia atrás (ej. 1.2)
Estos son capturados por un número de versión en el formato MAJOR.MINOR
Proceso de revisión¶
Para lanzar una nueva actualización de versión menor o mayor, se incluirán varias etapas descritas en el diagrama de flujo siguiente y se describirán con mayor profundidad en las siguientes secciones.
Principios generales:
Publicidad: Todas las etapas del proceso de revisión serán anunciadas a través de la lista de correo electrónico del estándar y mediante las incidencias de GitHub. Estos son los canales formales de notificación durante el proceso.
Consenso: Todos los procesos buscan generar consenso de la comunidad para los cambios.
El equipo de desarrollo del estándar es responsable de generar documentaciones clave durante el proceso, pero debería ser guiado por el consenso de la comunidad, sometiendo todas las decisiones a discusión.
Apelación: Cualquier parte puede apelar en contra de las decisiones hechas durante el proceso escribiendo al equipo de trabajo de gobernanza del estándar, que puede ser contactado a través de la Directora de Datos y Participación, Lindsey Marchessault. El grupo de trabajo tiene la autoridad de rechazar revisiones propuestas sobre el estándar en respuesta a apelaciones.
Propuestas¶
Los cambios a OCDS pueden ser propuestos por cualquier persona en cualquier punto a través del issue tracker público del estándar ya sea como cuestiones para la discusión, o hacer pull requests con una descripción clara del cambio propuesto.
Se alienta a los contribuidores a plantear discusiones antes de realizar pull requests para buscar un consenso sobre los cambios propuestos.
Los cambios pueden proponerse como:
Extensiones - que agregan nuevas características al estándar.
Cambios - como actualizaciones a las definiciones de campos o entradas de lista de códigos.
Si hay al menos dos partes interesadas en utilizar una extensión, y después de discutir el borrador de extensión, entonces se puede mostrar en la versión actual de la documentación como una "funcionalidad experimental".
Priorización¶
El equipo de desarrollo del estándar, con referencia a los puntos de vista de la comunidad, identifica propuestas de cambios y extensiones que deberían considerarse para su adopción en la próxima versión del estándar, asignando estos a hitos en el rastreador de issues donde están abiertos para su discusión.
Periódicamente, al comienzo de un proceso de revisión, se anunciará una fecha límite para las propuestas con un aviso mínimo de dos semanas. Después de esa fecha se produce una lista de actualizaciones con prioridades. Cualquier nueva propuesta de ampliaciones o cambios recibidos después de este período no puede ser considerado hasta la siguiente fase de priorización.
Revisión de priorización¶
La lista se comparte para comentarios, con al menos una ventana de dos semanas para la discusión.
Basado en las discusiones, el Jefe de Productos y Servicios de Datos de OCP propone una lista final con todas las cuestiones que se abordarán en el resto del proceso. Una propuesta que ha llegado hasta aquí puede o no llegar a la actualización final. A medida que la propuesta se traduce en ejemplos concretos finales y cambios en el esquema, pueden surgir otros problemas.
Desarrollo¶
El equipo de desarrollo del estándar, trabajando con los miembros de la comunidad, trabajará en una rama de desarrollo para preparar actualizaciones al esquema, a la documentación y a las listas de códigos, de acuerdo con la lista de prioridades.
Es probable que esta etapa involucre un amplio compromiso de la comunidad y la discusión de decisiones específicas a través de los issues de GitHub.
Al punto en el cual todos los issues abiertos se han abordado adecuadamente, la rama de desarrollo está lista para ser sometida a revisión por pares.
Revisión por pares¶
El esquema actualizado, la documentación junto con un registro de cambios y una descripción narrativa de los cambios se publicarán para la revisión por pares.
Se invitará a un grupo de revisores, que representen a las diferentes partes interesadas, incluidos los publicadores de datos y los usuarios, a completar una revisión completa de los cambios y a presentar:
Un juicio sobre si toda la actualización, y/o cambios específicos se deben de aceptar, aceptar con cambios menores, revisar substancialmente, o rechazar.
Comentarios sobre cada solicitud de revisión o rechazo.
Todas las revisiones, con los nombres de los revisores, se publicarán. Los miembros de la comunidad también pueden enviar sus propias revisiones de toda la revisión, o elementos específicos. El período mínimo para revision por pares es un mes.
Revisiones¶
El equipo de desarrollo del estándar, con referencia al equipo de trabajo cuando sea apropiado, evalúa las revisiones, y decide si toda la actualización, o características específicas de los mismos, deben ser revisadas, rechazadas o pospuestas a procesos futuros.
Si sólo se sugieren cambios menores, entonces el estándar revisado debe enviarse nuevamente a los revisores por un breve período de revisión de al menos dos semanas.
Si se necesitan cambios mayores, se debe permitir un proceso de revisión de seguimiento más largo de al menos un mes.
Entrega¶
Una vez que todos los comentarios de revisión se hayan tomado en cuenta para la satisfacción del revisor en cuestión, entonces la versión actualizada del estándar debe de enviarse al grupo de trabajo de gobernanza del estándar para su aprobación final, junto con un breve informe del proceso.
Siguiendo la aprobación del grupo de trabajo, la rama de revisión puede publicarse.
Política de descontinuación¶
Si un término (definición o campo) se agenda para ser renombrado o borrado de la especificación como resultado del proceso de revisión, la siguiente versión menor debe descontinuar el término dentro del esquema, y la siguiente versión mayor debe renombrar o quitar el término del esquema, haciéndolo obsoleto. Las implementaciones pueden usar términos descontinuados, pero van a recibir advertencias de la Herramienta de Revisión de Datos OCDS descrita más abajo. Las implementaciones no deben usar términos obsoletos, y van a recibir errores de la Herramienta de Revisión de Datos OCDS.
Políticas de traducción y localización¶
El estándar se traduce y se localiza en línea con la última versión de la política de traducción y localización.
Política de soporte¶
Se ofrecerá soporte para una versión anterior del estándar. El soporte para cualquier versión anterior a esta se terminará cuando se publique una nueva versión.
Por ejemplo, cuando 1.1 es la versión más nueva, el 1.0 va a ser soportado en la Herramienta de Revisión de Datos OCDS y otras herramientas. Cuando se libera 1.2, se terminará el soporte para 1.0.
Se recomienda a los publicadores revisar cada nueva versión cuando se publique, y considerar cómo podrían adoptar nuevas características.
Los publicadores deben tratar de pasar a una nueva versión mayor dentro de los 18 meses de su publicación.
Definiciones¶
Parte interesada
Cualquier publicador de OCDS actual o potencial o usuario del estándar puede ser considerado como un interesado. Cuando se trata con los interesados, se debe poner atención a la representación tanto de usuarios como de publicadores; tener representación de los sectores público, privados y sociedad civil; y una representación geográfica amplia.
Consenso
"El principio del consenso tiene su origen en el deseo de lograr la aceptación general y la aplicación de una norma dentro de su esfera de influencia prevista, lo que implica tratar de asegurar que se tengan en cuenta los intereses de todos los que puedan verse afectados por ella, Y que las preocupaciones individuales estén equilibradas de manera cuidadosa y justa en contra del mayor interés público ".BSI, 2012