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.

A partir de febrero de 2016, el OCP es administrado fiscalmente por el Fondo para la Ciudad de Nueva York (FCNY). Bajo los términos de este acuerdo, la Propiedad Intelectual es mantenida por FCNY en nombre de OCP, pero se transferirá a cualquier entidad jurídica futura que aloje a OCP.

El equipo técnico de OCDS trabaja bajo contrato para OCP, bajo la dirección del director de Datos y Participación de OCP, dando un servicio de mesa de ayuda y siendo responsables de la administración día a día de la documentación del estándar y herramientas de validación. El equipo técnico puede ser contactado via data@open-contracting.org.

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 grupo de trabajo ligero de gobernanza del estándar, compuesto por representantes del personal de OCP, el comité consultivo de partes interesadas y el equipo técnico será responsable de dar la aprobación final a las mejoras formales del estándar y asegurar que los procesos en este documento se han llevado a cabo correctamente.

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 aceptan transferir cualquier derecho de autor sobre sus contribuciones a la Open Contracting Partnership (a través de su patrocinador fiscal) a través de un proceso de acuerdo de contribuyente, a fin de 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.

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 hacer 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.

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 con cambios en los campos y estructuras existentes.

El proceso de revisión está diseñado para asegurar:

  • 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;

Cambios al esquema OCDS deben de hacerse periódicamente, con el número de versión del estándar incrementando para indicar los cambios que se han hecho, y se debe mantener 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 typos en las descripciones de los campos, o actualizar la guía de implementación).

Versiones

Distintos branches del estándar se mantendrán dentro de Github para cada versión.

Las branches 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 en una base 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 a la API incompatibles con versiones anteriores

  • Versiones menores que agregan funcionalidad de una manera compatible hacia atrás

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.

image alt text

Principios generales:

  • Publicidad: Todas las etapas del proceso de revisión serán anunciadas a través de la lista de correo electrónico 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 técnico es responsable de generar la documentación clave durante el proceso, pero debe estar guiado por el consenso de la comunidad, sometiendo todas las decisiones a discusión.

  • Apelación: Cualquier parte puede apelar contra las decisiones que se hicieron durante el proceso, escribiendo al grupo de trabajo de gobernanza del estándar, al cual se puede acceder a través de Lindsey Marchessault. El grupo de trabajo tienen la autoridad de rechazar revisiones propuestas al estándar como respuesta a las 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 contribuyentes a plantear discusiones antes de realizar pull requests para buscar un consenso sobre los cambios propuestos.

Los cambios pueden proponerse cuando:

  • Extensiones - que agregan nuevas características al estándar.

  • Cambios - como definiciones de campo actualizadas 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 “característica experimental”.

Priorización

El equipo técnico, con referencia a los puntos de vista de la comunidad, identifiquen propuestas de cambios y extensiones que pueden considerarse para adopción en la próxima versión del estándar, asignando estos a hitos en el rastreador de issues cuando estén abiertas para 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, una lista final se propone por el equipo técnico con todos los issues que se llevarán adelante en el resto del proceso. Una propuesta que ha llegado a este punto puede o no llegar hasta la actualización final. Al trabajar la propuesta a ejemplos finales concretos y cambios al esquema, pueden surgir nuevos issues.

Desarrollo y Documentos

El equipo técnico, trabajando con los miembros de la comunidad, trabajará en un branch de desarrollo para preparar actualizaciones del esquema, la documentación y 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 editores 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 técnico, con referencia al equipo de trabajo como 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 de enviarse a los revisores para 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 (una clase o propiedad) está programado para ser cambiado de nombre o eliminado de la especificación como resultado del proceso de revisión, la siguiente versión menor de la especificación debe descontinuar el término dentro del esquema, y ​​la siguiente versión principal debe cambiar el nombre o eliminar el término del esquema, haciendo que el término sea obsoleto. Las implementaciones pueden usar términos obsoletos, pero recibirán advertencias del validador OCDS descrito a continuación. Las implementaciones no pueden usar términos obsoletos y recibirán errores del validador 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 reciente, 1.0 será compatible con el validador y otras herramientas. Cuando se libera 1.2, el soporte para 1.0 finalizará.

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 y procedimientos

Parte interesada

Cualquier persona que sea publicador actual o potencial o usuario del estándar puede considerarse como stakeholder. Cuando se trata con los stakeholders, 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