Gestione

Open Contracting Data Standard (OCDS) ha diversi portatori di interesse: nelle pubbliche amministrazioni (enti appaltanti, autorità di monitoraggio e supervisione, responsabili di progetto e responsabili politici), nel settore privato e organizzazioni della società civile. I bisogni e gli interessi di queste parti interessate, come i responsabili e gli utenti dei dati, sono vari. Poiché l”OCDS si sviluppa nel tempo, con versioni aggiornate e nuove funzionalità, è importante che un gruppo eterogeneo di parti interessate sia coinvolto nel processo.

Questo documento illustra i processi di revisione per OCDS.

Amministrazione e gestione

La Open Contracting Partnership (OCP) è stata istituita come ente no profit indipendente all”inizio del 2015 e funge da amministratore delegato dell”Open Contracting Data Standard.

L”OCP è guidato da un direttore esecutivo ed è supportato da un comitato consultivo con portatori di interesse di diverse organizzazioni e con rappresentanze di governi, organizzazioni multilaterali, università, ONG e imprese.

A partire da febbraio 2016, l”OCP è fiscalmente ospitato dal Fondo per la città di New York (FCNY). Secondo i termini di questo accordo, la proprietà intellettuale è detenuta da FCNY per conto di OCP, ma verrà trasferita a qualsiasi entità giuridica futura che ospita OCP.

In the pursuit of a consensus and community-driven process, subscribers to the standard-discuss@open-contracting.org discussion list (join by sending an email to standard-discuss+subscribe@open-contracting.org) and those watching and engaging with the standard GitHub repository should be kept informed at all stages about planned revisions to OCDS, and should be offered clear and timely opportunities to input and comment.

Per garantire la pertinenza, la qualità e l”effettiva attuazione degli aggiornamenti proposti allo standard, i rilasci delle nuove versioni sono sottoposti a un processo di peer review con revisori invitati dalle comunità delle organizzazioni che pubblicano i dati e gli utenti attraverso un processo di revisione aperto e condiviso.

A lightweight standard governance working group, made up of representatives from OCP staff, the multi-stakeholder advisory board, and the standard development team will be responsible for giving final approval to formal upgrades of the standard and ensuring the processes in this document have been properly carried out.

In the future, the Open Contracting Data Standard may be submitted to a formal standardization body, such as the World Wide Web Consortium, or OASIS. Before such a decision is made, a model of community-driven governance must be established based on an open and consensus-based processes for updating the standard.

Proprietà intellettuale

La proprietà intellettuale dell”Open Contracting Data Standard è della Open Contracting Partnership. Lo schema è concesso in licenza con la licenza Apache 2.0 License, e dove dichiarato con documentazione di accompagnamento in (licenza internazionale Creative Commons Attribution 4.0)( https://creativecommons.org/licenses/by/4.0/).

I contributori allo standard accettano di trasferire qualsiasi copyright nei loro contributi alla Open Contracting Partnership (tramite il suo sponsor fiscale) attraverso un processo di accordo di contribuzione, in modo che tali contributi siano considerati di fiducia come parte dello standard.

Nessun contenuto che viola i diritti di proprietà intellettuale di terze parti sarà incluso nello standard.

Principi di gestione

Ci impegniamo a rispettare i principi di Open Stand per lo sviluppo degli standard. L”Open Contracting Data Standard sarà sviluppato con:

  • Oblighi di Procedura. Le decisioni sono prese con equità e correttezza tra i partecipanti. Attraverso una procedura aperta per l”invio di problemi, estensioni e richieste di aggiornamenti, nessuna parte domina o guida lo sviluppo standard. Tutti i processi saranno trasparenti e ci saranno opportunità per fare appello alle decisioni. I processi per la revisione e l”aggiornamento periodici degli standard sono ben definiti in questo documento.

  • Consenso diffuso Il processo consentirà di considerare e affrontare tutte le opinioni, in modo tale che l”accordo possa essere trovato attraverso una varietà di interessi diversi

  • Trasparenza. Forniremo un preavviso pubblico delle attività di sviluppo delle norme proposte, lo scopo del lavoro da svolgere e le condizioni per la partecipazione. Verranno forniti registri delle decisioni facilmente accessibili e i materiali utilizzati per raggiungere tali decisioni. I periodi utili per i commenti pubblici saranno forniti prima dell”approvazione e dell”adozione degli standard finali.

  • Bilanciamento Le attività standard non saranno dominate esclusivamente da una particolare persona, società o gruppo di interesse.

  • Apertura. I processi di Open Contracting Data Standard sono aperti a tutte le parti interessate.

Versionamento e processo di aggiornamento

Nel corso del tempo, saranno necessari cambiamenti allo standard, inclusa l”aggiunta di nuovi identificativi e campi, e occasionalmente modifiche ai campi e alle strutture dati esistenti.

The revision process is designed to ensure:

  • Le conseguenze di qualsiasi cambiamento per i diversi portatori di interesse sono identificate e prese in considerazione;

  • È chiaro il motivo per cui sono necessari cambiamenti e che esiste un ampio sostegno per eventuali modifiche proposte;

  • Le modifiche sono facili da identificare e trasparenti e gli enti che pubblicano dati, gli utenti e gli intermediari dispongono di una documentazione chiara che consente loro di aggiornare i propri dati e i relativi strumenti di utilità

Changes to the OCDS schema will be made periodically, with the version number of the standard incremented to indicate that changes have been made, and a changelog maintained.

This documentation website is composed of normative content (the prescriptive part of OCDS) and non-normative content (the non-prescriptive, or ‘descriptive’, part of OCDS) as defined and described in the Normative and non-normative content and changes policy. This policy establishes which changes to which parts of the documentation must involve the revision process described below (e.g. adding new fields to the release schema), and which changes may be made without the revision process (e.g. correcting typos in field descriptions, or updating implementation guidance).

Versioni

Distinti rami dello standard saranno mantenuti all”interno di GitHub per ogni versione.

I rami possono essere in uno dei due stati:

  • Development - indicated by a -dev suffix (e.g. 1.1-dev) Both schema and documentation on a development branch may be updated and should be implemented on an experimental basis.

  • Live - with no suffix ( e.g. 1.0) Only documentation may be updated on a live branch. All documentation changes must be reviewed to ensure they do not make any changes to the meaning of the standard.

Verranno utilizzate pratiche di versionamento semantico per distinguere tra:

  • Major versions which make backwards-incompatible changes (e.g. 2.0)

  • Minor versions which add functionality in a backwards-compatible manner (e.g. 1.2)

Questi sono catturati da un numero di versione nel formato MAJOR.MINOR

Processo di revisione

Per rilasciare un nuovo aggiornamento di versione minore o maggiore comporteranno un numero di fasi delineate nel diagramma di flusso sottostante e descritte in modo più approfondito nelle seguenti sezioni.

image alt text

Principi generali:

  • Pubblicità: Tutte le fasi del processo di revisione saranno annunciate tramite la «standard-discuss» mailing-list e tramite le issue di GitHub. Questi sono i canali formali per la notifica durante il processo.

  • Consensus: All processes will aim towards gaining community consensus for changes.

The standard development team is responsible for generating key documentation during the process, but should be guided by community consensus, submitting all decisions for discussion.

  • Appeal: Any party can appeal against decisions made during the process by writing to the standard governance working group, which can be reached through OCP”s Director for Data & Engagement, Lindsey Marchessault. The working group has the authority to reject proposed revisions on the standard in response to appeals.

Proposte

Le modifiche a OCDS possono essere proposte online da chiunque e in qualsiasi momento tramite [standard issue tracker di GitHub] (https://github.com/open-contracting/standard/issues) sia come come argomenti di discussione o come richieste di pull con un chiara descrizione della modifica proposta.

I contributori sono incoraggiati a sollevare le discussioni prima di inviare richieste per ottenere il consenso sulle modifiche proposte.

Changes can be proposed as:

  • Estensioni - che aggiungono nuove funzionalità allo standard.

  • Modifiche - come definizioni di campi aggiornate o voci della lista di codici.

Se ci sono almeno due parti interessate a utilizzare un”estensione e dopo aver discusso la bozza dell”estensione, può essere visualizzata nella versione corrente della documentazione come una «funzione sperimentale».

Definizione delle priorità

The standard development team, with reference to community views, identify change proposals and extensions which ought to be considered for adoption in the next version of the standard, assigning these to milestones in the issue tracker where they are open for discussion.

Periodicamente, all”inizio di un processo di revisione, verrà annunciata una data limite per le proposte con un preavviso di almeno due settimane. Dopo tale data viene prodotto un elenco di aggiornamenti con relativa priorità. Eventuali nuove estensioni o modifiche proposte dopo questo periodo potrebbero non essere considerate fino alla successiva fase di definizione delle priorità.

Revisione delle priorità

L”elenco è condiviso per il feedback, con almeno una finestra temporale di due settimane per la discussione.

Based on discussions, a final list is then proposed by the OCP”s Head of Data Products & Services with all the issues that will be taken forward into the rest of the process. A proposal that has made it this far might or might not make it into the final upgrade. As the proposal is worked into final concrete examples and schema changes further issues can arise.

Development

The standard development team, working with community members, will work on a development branch to prepare updates to the schema, documentation and codelists, according to the prioritized list.

È probabile che questa fase implichi un ampio coinvolgimento della comunità e la discussione di decisioni specifiche attraverso le issue di GitHub.

At the point where all open issues are suitably addressed, the development branch is ready to be submitted for peer review.

Revisione tra pari

Lo schema aggiornato, la documentazione, il log delle modifiche e la descrizione narrativa delle modifiche saranno rilasciati per la revisione tra pari.

Un gruppo di revisori invitati, che rappresentano diversi portatori di interesse inclusi i rappresentanti degli enti che pubblicano dati e gli utenti, sarà invitato a completare una revisione completa delle modifiche e a inviare:

  • A judgment on whether the overall upgrade, and/or specific changes ought to be accepted, accepted with minor changes, substantially revised, or rejected.

  • Commenti su ogni richiesta di revisione o rifiuto.

All reviews, with reviewer names, will be published. Community members can also submit their own reviews of the whole revision, or specific elements. The minimum period for peer-review is one month.

Revisioni

The standard development team, with reference to the working group as appropriate, evaluates reviews, and decides whether the whole upgrade, or specific features thereof, need to be revised, rejected or postponed to future processes.

If only minor changes are suggested, then the revised standard should be submitted back to reviewers for a brief review period of at least two weeks.

If major changes are needed, then a longer follow up review process of at least one month should be allowed for.

Rilascio

Once all reviewer comments have been addressed to the satisfaction of the reviewer in question, then the updated version of the standard must be submitted to the standard governance working group for final approval, along with a short report of the process.

Following working group approval, the revision branch may be set to live.

Politica di deprecazione

If a term (a definition or field) is scheduled to be renamed or removed from the specification as a result of the revision process, the next minor release of the specification must deprecate the term within the schema, and the following major release must rename or remove the term from the schema, making the term obsolete. Implementations may use deprecated terms, but will receive warnings from the OCDS Data Review Tool described below. Implementations may not use obsolete terms, and will receive errors from the OCDS Data Review Tool.

Translation and localization policy

The standard is translated and localized in line with the latest version of the translation and localization policy.

Politica di supporto

Il supporto sarà offerto fino ad una versione precedente dello standard. Il supporto per tutte le versioni precedenti di questo verrà terminato quando viene rilasciata una nuova versione.

For example, when 1.1 is the latest release, 1.0 will be supported in the OCDS Data Review Tool and other tooling. When 1.2 is released, support for 1.0 will end.

Publishers are encouraged to review each new version when it is released, and to consider how they might adopt new features.

Le organizzazioni che pubblicano dati dovrebbero mirare a passare a una nuova versione principale entro 18 mesi dalla sua pubblicazione.

Definitions

portatori di interesse

Any current or potential OCDS publisher or data user of the standard can be considered a stakeholder. When engaging with stakeholders, attention ought to be paid to representation of both publishers and users; representation of public and private sectors and civil society; and broad geographical representation.

Consenso

«Il principio del consenso ha origine dal desiderio di ottenere l”accettazione generale e l”applicazione di uno standard nella sua sfera di influenza naturale, il che implica cercare di garantire che gli interessi di tutti coloro che ne sono coinvolti siano presi in considerazione, e le preoccupazioni individuali siano attentamente ed equamente bilanciate contro il più ampio interesse pubblico «. BSI, 2012