diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml index 650957eb4..1286d664d 100644 --- a/.github/workflows/ci.yml +++ b/.github/workflows/ci.yml @@ -23,7 +23,10 @@ jobs: # https://help.github.com/en/actions/reference/software-installed-on-github-hosted-runners - name: Make run: | - if [ $GITHUB_REPOSITORY = 'open-contracting/standard_profile_template' ]; then python schema/build-profile.py; make extract; fi + if [ $GITHUB_REPOSITORY = 'open-contracting/standard_profile_template' ]; then + python schema/build-profile.py + make extract + fi make python util/add_translation_notes.py - run: pytest @@ -31,15 +34,15 @@ jobs: with: key: ${{ secrets.PRIVATE_KEY }} known_hosts: standard.open-contracting.org ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDWLziEiV46d9iInFXAR/PxPvotcpmMtbwO8GkTF2/AFUkyiSd8/Yg5HXUoWBz7hbRwg2O+q5F1QfD57vevBV7c+JKyBbKVOi/mXaf7uACxer419RTgKcpaMhNRi708XWhNlWiKp3Afs/MDMvMdWSrU+Ht7biNb1OMGjfNMDdlsJxPycxMQ7Fu7i+kdyMkKLYDIHNeEw0aW9PtMTReUE0y/Ghn44PDR2u9/oZsEhC0ELDQUfsjtCcoM91FH1tjRBZkOW/j5940nMoJpbVhFHTC3YY9Mh2kV+N6Whht5nghJ7Jl2vN5W0Uer+TNMVRV4QMu8xK5HXbjKFMpaK+j4gBs9 - - uses: little-core-labs/netrc-creds@v2.0.1 + - uses: little-core-labs/netrc-creds@v2.1.0 with: - creds: | - [{ - "machine": "standard.open-contracting.org", - "login": "manage", - "password": "${{ secrets.ELASTICSEARCH_PASSWORD }}" - }] + machine: standard.open-contracting.org + login: manage + password: ${{ secrets.ELASTICSEARCH_PASSWORD }} - if: success() env: PATH_PREFIX: '' - run: curl -Ss https://raw.githubusercontent.com/open-contracting/deploy/master/deploy-docs.sh | bash - + run: | + if [ $GITHUB_REPOSITORY != 'open-contracting/standard_profile_template' ]; then + curl -sS https://raw.githubusercontent.com/open-contracting/deploy/main/deploy-docs.sh | bash - + fi diff --git a/.github/workflows/lint.yml b/.github/workflows/lint.yml index faa621535..7c500a81d 100644 --- a/.github/workflows/lint.yml +++ b/.github/workflows/lint.yml @@ -1,7 +1,7 @@ name: Lint on: [push, pull_request] env: - BASEDIR: https://raw.githubusercontent.com/open-contracting/standard-maintenance-scripts/master + BASEDIR: https://raw.githubusercontent.com/open-contracting/standard-maintenance-scripts/main jobs: build: runs-on: ubuntu-latest diff --git a/common-requirements.in b/common-requirements.in index 71cfd0f6b..3351dc83e 100644 --- a/common-requirements.in +++ b/common-requirements.in @@ -1,11 +1,11 @@ -Sphinx<3 +-e git+https://github.com/sphinx-doc/sphinx.git@3207da1fa81a5d3171d3bbb15768e1c6f6b39b58#egg=sphinx # Sphinx ocds-babel>=0.2.1 # See https://ocds-babel.readthedocs.io/en/latest/api/translate.html#install-requirements-for-markdown-translation --e git+https://github.com/readthedocs/commonmark.py.git@dafae75015cc342f3fddb499674bab97ac4a6a96#egg=commonmark --e git+https://github.com/jpmckinney/recommonmark.git@hotfix#egg=recommonmark -e git+https://github.com/open-contracting/standard_theme.git@open_contracting#egg=standard_theme +myst-parser~=0.13.3 +mdit-py-plugins~=0.2.5 # Make sphinx-intl<1 @@ -18,5 +18,6 @@ ocdsindex>=0.0.4 ocdsextensionregistry>=0.0.23 # Tests +pip-tools pytest selenium diff --git a/common-requirements.txt b/common-requirements.txt index 9559cbef7..a3a6588ca 100644 --- a/common-requirements.txt +++ b/common-requirements.txt @@ -4,18 +4,19 @@ # # pip-compile common-requirements.in # --e git+https://github.com/readthedocs/commonmark.py.git@dafae75015cc342f3fddb499674bab97ac4a6a96#egg=commonmark +-e git+https://github.com/sphinx-doc/sphinx.git@3207da1fa81a5d3171d3bbb15768e1c6f6b39b58#egg=sphinx # via # -r common-requirements.in - # recommonmark --e git+https://github.com/jpmckinney/recommonmark.git@hotfix#egg=recommonmark - # via -r common-requirements.in + # myst-parser + # sphinx-intl -e git+https://github.com/open-contracting/standard_theme.git@open_contracting#egg=standard_theme # via -r common-requirements.in alabaster==0.7.12 # via sphinx attrs==19.3.0 - # via pytest + # via + # markdown-it-py + # pytest babel==2.8.0 # via # sphinx @@ -29,10 +30,11 @@ chardet==3.0.4 click==7.0 # via # ocdsindex + # pip-tools # sphinx-intl docutils==0.16 # via - # recommonmark + # myst-parser # sphinx elasticsearch==7.10.1 # via ocdsindex @@ -45,17 +47,30 @@ importlib-metadata==1.4.0 # pluggy # pytest jinja2==2.10.3 - # via sphinx + # via + # myst-parser + # sphinx json-merge-patch==0.2 # via ocdsextensionregistry jsonref==0.2 # via ocdsextensionregistry lxml==4.6.2 # via ocdsindex +markdown-it-py==0.6.1 + # via + # mdit-py-plugins + # myst-parser markupsafe==1.1.1 # via jinja2 +mdit-py-plugins==0.2.5 + # via + # -r common-requirements.in + # markdown-it-py + # myst-parser more-itertools==8.1.0 # via pytest +myst-parser==0.13.3 + # via -r common-requirements.in ocds-babel==0.2.1 # via -r common-requirements.in ocdsextensionregistry==0.0.23 @@ -66,6 +81,8 @@ packaging==20.0 # via # pytest # sphinx +pip-tools==5.5.0 + # via -r common-requirements.in pluggy==0.13.1 # via pytest py==1.8.1 @@ -80,6 +97,8 @@ python-slugify==1.2.6 # via transifex-client pytz==2019.3 # via babel +pyyaml==5.4.1 + # via myst-parser requests-cache==0.5.2 # via ocdsextensionregistry requests==2.22.0 @@ -99,11 +118,6 @@ snowballstemmer==2.0.0 # via sphinx sphinx-intl==0.9.12 # via -r common-requirements.in -sphinx==2.4.4 - # via - # -r common-requirements.in - # recommonmark - # sphinx-intl sphinxcontrib-applehelp==1.0.1 # via sphinx sphinxcontrib-devhelp==1.0.1 @@ -132,4 +146,5 @@ zipp==1.0.0 # via importlib-metadata # The following packages are considered to be unsafe in a requirements file: +# pip # setuptools diff --git a/docs/404.md b/docs/404.md index d8bdeb721..20cc5db40 100644 --- a/docs/404.md +++ b/docs/404.md @@ -1,6 +1,6 @@ -```eval_rst -:orphan: -``` +--- +orphan: true +--- # 404 Not found diff --git a/docs/_static/basic.css b/docs/_static/basic.css index b8b220cff..968938e49 100644 --- a/docs/_static/basic.css +++ b/docs/_static/basic.css @@ -2,6 +2,11 @@ div.spaced li { margin-bottom: 1em; } +.directive--field-description, +.directive--code-description { + font-style: italic; +} + /* Extensions */ .hide { display: none; diff --git a/docs/_static/extensions.js b/docs/_static/extensions.js index 24c480968..4e1cd4cda 100644 --- a/docs/_static/extensions.js +++ b/docs/_static/extensions.js @@ -14,7 +14,7 @@ if (document.querySelector('.extension_list')) { // Get the community extensions to add to the documentation. const request = new XMLHttpRequest() - request.open('GET', 'https://raw.githubusercontent.com/open-contracting/extension_registry/master/build/extensions.json') + request.open('GET', 'https://raw.githubusercontent.com/open-contracting/extension_registry/main/build/extensions.json') request.responseType = 'json' request.onload = () => { diff --git a/docs/conf.py b/docs/conf.py index 6fd8e2e8d..d1194c833 100644 --- a/docs/conf.py +++ b/docs/conf.py @@ -19,7 +19,6 @@ import standard_theme from ocds_babel.translate import translate -from recommonmark.transform import AutoStructify # -- Project information ----------------------------------------------------- @@ -37,10 +36,10 @@ # extensions coming with Sphinx (named 'sphinx.ext.*') or your custom # ones. extensions = [ - 'recommonmark', 'sphinxcontrib.jsonschema', 'sphinxcontrib.opencontracting', 'sphinxcontrib.opendataservices', + 'myst_parser', ] # Add any paths that contain templates here, relative to this directory. @@ -91,7 +90,7 @@ gettext_domain_prefix = '' # List the extension identifiers and versions that should be part of the standard. The extensions must be available in -# the extension registry: https://github.com/open-contracting/extension_registry/blob/master/extension_versions.csv +# the extension registry: https://github.com/open-contracting/extension_registry/blob/main/extension_versions.csv default_extension_version = 'v{}'.format(release) extension_versions = { 'bids': default_extension_version, @@ -103,16 +102,12 @@ 'process_title': default_extension_version, } +# Disable dollarmath, which uses MathJax for a string like: "If Alice has $100 and Bob has $1..." +# https://myst-parser.readthedocs.io/en/latest/using/intro.html#sphinx-configuration-options +myst_enable_extensions = [] -def setup(app): - app.add_config_value('extension_versions', extension_versions, True) - app.add_config_value('recommonmark_config', { - 'auto_toc_tree_section': 'Contents', - 'enable_eval_rst': True - }, True) - - app.add_transform(AutoStructify) +def setup(app): # The root of the repository. basedir = Path(os.path.realpath(__file__)).parents[1] # The `LOCALE_DIR` from `config.mk`. diff --git a/docs/examples/extended.json b/docs/examples/extended.json index bcfeb544c..bd542c4a1 100644 --- a/docs/examples/extended.json +++ b/docs/examples/extended.json @@ -11,7 +11,7 @@ "publicationPolicy": "https://github.com/open-contracting/sample-data/", "version": "1.1", "extensions": [ - "https://raw.githubusercontent.com/open-contracting/ocds_participationFee_extension/master/extension.json" + "https://raw.githubusercontent.com/open-contracting-extensions/ocds_participationFee_extension/master/extension.json" ], "releases": [ { diff --git a/docs/getting_started/building_blocks.md b/docs/getting_started/building_blocks.md index fffb058d8..fa5026d82 100644 --- a/docs/getting_started/building_blocks.md +++ b/docs/getting_started/building_blocks.md @@ -1,4 +1,4 @@ -## Building Blocks +# Building Blocks In mapping your data to OCDS, or using OCDS data, you will encounter a number of common data structures. @@ -12,7 +12,7 @@ In mapping your data to OCDS, or using OCDS data, you will encounter a number of -### Sections and structure +## Sections and structure An OCDS document is made up of a number of sections. These are: @@ -26,7 +26,7 @@ An OCDS document is made up of a number of sections. These are: These are represented in a JSON document as follows: -```eval_rst +```{eval-rst} .. code-block:: json :emphasize-lines: 8-13 @@ -48,7 +48,7 @@ These are represented in a JSON document as follows: } ``` -### Building blocks: fields +## Building blocks: fields The OCDS schema sets out the fields that ought to be included in each section (where applicable), making use of simple re-usable building blocks (field structures) to represent data. @@ -61,9 +61,9 @@ For example, common building blocks are provided for: * **Documents** * **Milestones** -#### Examples +### Examples -```eval_rst +```{eval-rst} .. jsoninclude:: ../examples/record.json :jsonpointer: /records/0/compiledRelease/parties/0 :expand: identifier, address, contactPoint @@ -71,7 +71,7 @@ For example, common building blocks are provided for: ``` -```eval_rst +```{eval-rst} .. jsoninclude:: ../examples/record.json :jsonpointer: /records/0/compiledRelease/awards/0/value :expand: @@ -79,7 +79,7 @@ For example, common building blocks are provided for: ``` -```eval_rst +```{eval-rst} .. jsoninclude:: ../examples/record.json :jsonpointer: /records/0/compiledRelease/awards/0/items :expand: classification, unit, additionalClassifications, value @@ -87,7 +87,7 @@ For example, common building blocks are provided for: ``` -```eval_rst +```{eval-rst} .. jsoninclude:: ../examples/record.json :jsonpointer: /records/0/compiledRelease/awards/0/contractPeriod :expand: @@ -95,7 +95,7 @@ For example, common building blocks are provided for: ``` -```eval_rst +```{eval-rst} .. jsoninclude:: ../examples/record.json :jsonpointer: /records/0/compiledRelease/awards/0/documents :expand: @@ -103,7 +103,7 @@ For example, common building blocks are provided for: ``` -```eval_rst +```{eval-rst} .. jsoninclude:: ../examples/record.json :jsonpointer: /records/0/compiledRelease/tender/milestones/0 :expand: @@ -111,7 +111,7 @@ For example, common building blocks are provided for: ``` -#### Using building blocks +### Using building blocks These building blocks can be used in various different sections. For example, **items** can occur in tender (to indicate the items that a buyer wishes to buy), in an award object (to indicate the items that an award has been made for) and in a contract object (to indicate the items listed in the contract). @@ -125,7 +125,7 @@ In addition to these building blocks, the OCDS schema sets out the specific ways Many of these fields make use of lightweight codelists provided by OCDS. -#### Extensions +### Extensions In some cases, publishers or users need building blocks and fields which are not provided in the core OCDS schema. @@ -139,7 +139,7 @@ The Open Contracting Data Standard helpdesk maintain a [field-level mapping temp -### Codelists +## Codelists OCDS defines two kinds of codelist: @@ -165,7 +165,7 @@ In the EU, contracts can be initiated through a number of different procedures i However, to support comparison across continents, the main OCDS procurement method codelist is a closed codelist with four values: -```eval_rst +```{eval-rst} .. codelisttable:: :header-rows: 1 :file: ../../build/current_lang/codelists/method.csv diff --git a/docs/getting_started/contracting_process.md b/docs/getting_started/contracting_process.md index fa1cb2e91..8208113a0 100644 --- a/docs/getting_started/contracting_process.md +++ b/docs/getting_started/contracting_process.md @@ -1,4 +1,4 @@ -## The Contracting Process +# The Contracting Process There are several stages to a contracting process. @@ -90,7 +90,7 @@ You are encouraged to publish OCDS data close to real-time: releasing data as ea This might involve generating output from a range of different systems. Data published from different systems can be tied together by use of a common Open Contracting ID (`ocid`). -### Defining a contracting process +## Defining a contracting process For public procurement OCDS defines a unique contracting process as: @@ -98,7 +98,7 @@ For public procurement OCDS defines a unique contracting process as: An initiation process might be a tender, a direct contract award, or a call to award a concession. -### The Open Contracting ID (ocid) +## The Open Contracting ID (ocid) Each unique contracting process needs to be assigned an `ocid`. This is an identifier which can be used to join up data between different stages (as often the data might be stored in different systems). @@ -136,6 +136,6 @@ The `ocid` is case sensitive. Case needs to be used consistently whenever an `oc -### Mapping your systems +## Mapping your systems The Open Contracting Data Standard helpdesk provide [a technical assessment template](http://www.open-contracting.org/resources/ocds-technical-assessment-template/) that can be used to identify the different systems involved in managing data on each stage of the contracting process. diff --git a/docs/getting_started/index.md b/docs/getting_started/index.md index 8d4f9ff0e..8773ec488 100644 --- a/docs/getting_started/index.md +++ b/docs/getting_started/index.md @@ -18,14 +18,14 @@ To get started publishing OCDS data: When you are done you could be producing data that looks something like the contract release below, which is compatible with a growing range of OCDS aware tools (you will encounter a range of different OCDS release types in the following pages). -```eval_rst +```{eval-rst} .. jsoninclude:: ../examples/contract.json :jsonpointer: /releases :expand: releases, tender, awards, contracts, period, value, items, tag, parties, documents ``` -```eval_rst +```{eval-rst} .. toctree:: :hidden: diff --git a/docs/getting_started/publication_patterns.md b/docs/getting_started/publication_patterns.md index f81c02bbb..4b82b0902 100644 --- a/docs/getting_started/publication_patterns.md +++ b/docs/getting_started/publication_patterns.md @@ -1,6 +1,6 @@ -## Publication Patterns +# Publication Patterns -### Packaging releases and records +## Packaging releases and records When publishing releases and records, they need to be provided within a release package or record package. These act as an envelope for the data. @@ -16,7 +16,7 @@ A package can contain one or more releases or records. Consult the [release package](../schema/release_package) and [record package](../schema/record_package) schemas to package up your data. -#### Example release package +### Example release package ```json { @@ -36,7 +36,7 @@ Consult the [release package](../schema/release_package) and [record package](.. } ``` -### Bulk and individual files +## Bulk and individual files You are encouraged to: diff --git a/docs/getting_started/quality.md b/docs/getting_started/quality.md index aad5590d3..b89cb28f5 100644 --- a/docs/getting_started/quality.md +++ b/docs/getting_started/quality.md @@ -105,7 +105,7 @@ _Measures_: Whether the publisher calculates any key performance indicators or u _Indicates_: Whether it is possible to answer the most fundamental questions of priority use cases (who buys what from who, when and for how much). _Measures_: Coverage of specific fields: tender value, tender period, tender title, buyer name, award value, award date, supplier name, contract period. -```eval_rst +```{eval-rst} .. note:: .. markdown:: diff --git a/docs/getting_started/releases_and_records.md b/docs/getting_started/releases_and_records.md index ab95520f2..ba1843d23 100644 --- a/docs/getting_started/releases_and_records.md +++ b/docs/getting_started/releases_and_records.md @@ -40,7 +40,7 @@ In software development terms, releases are analogous to Git commits on a branch Releases follow the [release schema](../schema/reference). The schema covers the whole contracting process, but there are only a few mandatory fields. The box below shows an example. -```eval_rst +```{eval-rst} .. jsoninclude:: ../examples/tender.json :jsonpointer: /releases :expand: @@ -90,19 +90,19 @@ The following example shows releases with minimal changes on each update. 3. The third release presents award data, and ignores the tender section. - ```eval_rst + ```{eval-rst} .. jsoninclude:: ../examples/minimal_updates/tender.json :jsonpointer: /releases/0 :expand: tender ``` -```eval_rst +```{eval-rst} .. jsoninclude:: ../examples/minimal_updates/tenderUpdate.json :jsonpointer: /releases/0 :expand: tender ``` -```eval_rst +```{eval-rst} .. jsoninclude:: ../examples/minimal_updates/award.json :jsonpointer: /releases/0 :expand: award @@ -114,7 +114,7 @@ The following example shows releases with minimal changes on each update. A record follows the structure defined in the [Records Reference](../schema/records_reference). Below is a full example. -```eval_rst +```{eval-rst} .. jsoninclude:: ../examples/merging/versioned.json :jsonpointer: /records/0 :expand: @@ -145,7 +145,7 @@ Compiled releases are not mandatory, but it helps to make OCDS data more accessi Consider how to calculate the **total value of active tenders** using compiled releases: -```eval_rst +```{eval-rst} .. csv-table-no-translate:: :header-rows: 1 :file: ../examples/compiledreleases_compiled.csv @@ -155,7 +155,7 @@ Working with compiled releases, this metric can be calculated by filtering on th Compare that to how to calculate the **total value of active tenders** using releases: -```eval_rst +```{eval-rst} .. csv-table-no-translate:: :header-rows: 1 :file: ../examples/compiledreleases_releases.csv diff --git a/docs/getting_started/use_cases.md b/docs/getting_started/use_cases.md index b486f6609..c08d301ca 100644 --- a/docs/getting_started/use_cases.md +++ b/docs/getting_started/use_cases.md @@ -1,4 +1,4 @@ -## Users and use cases +# Users and use cases Open data is a means, not an end in itself. The first stage of any work with OCDS is to consider who will use the data that is produced, and which fields and features of the data are important to them. @@ -17,9 +17,9 @@ You can read more about how people around the world are using OCDS, and other co As you start implementing OCDS, consider how you will engage with data users, and how you will ensure the data and documents you make available will meet their needs. -### Four example use cases +## Four example use cases -#### Value for money in procurement +### Value for money in procurement Open contracting data can help officials to get good value for money on the goods and services in the procurement process, and can also help in identifying whether value for money has been achieved in concluded contracts. @@ -27,7 +27,7 @@ These users want to analyze trends in prices and supplier performance, including Comparable data using common codelists and the availability of unit prices are particularly important for value for money use cases. -#### Detecting fraud and corruption +### Detecting fraud and corruption All stakeholders (civil society, the private sector, government and donors) have an interest in identifying and combating corruption in public contracting. Open contracting data can be used to scrutinize procurement documents and data for ‘red flags’ that might indicate public monies are being mis-used. @@ -37,7 +37,7 @@ A ‘systemic’ approach looks for suspicious patterns, and makes links between Data that can be linked up using globally unique identifiers for companies is particularly important for fraud and corruption detection use cases. -#### Competing for public contracts +### Competing for public contracts Open contracting data can be used by private firms to understand the potential pipeline of procurement opportunities. It is a core principle of open contracting that information ought to be made available at the early stages of a contracting process, including information on planned procurement, and invitations for tenders. @@ -45,7 +45,7 @@ Information on past contracts can allow firms to identify upcoming opportunities Forward looking and timely information is particularly important for private sector users, as well as being able to uniquely identify procuring entities, geographic locations, sectors, and the kinds of items which are being procured. -#### Monitoring Service Delivery +### Monitoring Service Delivery Monitoring groups want to ensure that public contracting delivers value to citizens in terms of quality of goods, works, and services provided. To monitor contracting effectively involves being able to link budgets and donor data to the contracts and results. It also involves being able to verify whether results are being delivered on the ground. diff --git a/docs/getting_started/validation.md b/docs/getting_started/validation.md index f81c88751..445e84a49 100644 --- a/docs/getting_started/validation.md +++ b/docs/getting_started/validation.md @@ -1,4 +1,4 @@ -## Validation +# Validation You can validate your OCDS documents at [standard.open-contracting.org/review/](https://standard.open-contracting.org/review/). @@ -8,7 +8,7 @@ However, this is just one step of checking your data. The OCDS helpdesk team can provide additional support to check the quality of the data you are producing, and to check for other common errors and omissions. -### Quality checks +## Quality checks Assessing how good your open contracting data is involves a number of elements: diff --git a/docs/governance/deprecation.md b/docs/governance/deprecation.md index 7297048ec..d6621571a 100644 --- a/docs/governance/deprecation.md +++ b/docs/governance/deprecation.md @@ -10,7 +10,7 @@ Deprecated fields are marked in the JSON schema with the presence of a `deprecat For example: -```eval_rst +```{eval-rst} .. code-block:: json { diff --git a/docs/governance/index.md b/docs/governance/index.md index 4a6ae5ee9..2868fbabe 100644 --- a/docs/governance/index.md +++ b/docs/governance/index.md @@ -182,7 +182,7 @@ Any current or potential OCDS publisher or data user of the standard can be cons "The principle of consensus has its origins in the desire to achieve the general acceptance and application of a Standard within its intended sphere of influence. This entails trying to ensure that the interests of all those likely to be affected by it are taken into account, and that individual concerns are carefully and fairly balanced against the wider public interest." [BSI, 2012](http://www.bsigroup.com/Documents/about-bsi/NSB/BSI-pocket-guide-to-standards-development-UK-EN.pdf) -```eval_rst +```{eval-rst} .. toctree:: :hidden: diff --git a/docs/guidance/build.md b/docs/guidance/build.md index 1d8b37fd5..eebf0da85 100644 --- a/docs/guidance/build.md +++ b/docs/guidance/build.md @@ -4,7 +4,7 @@ This phase is about creating a new IT system, or updating an existing IT system, Alternatively, if you don't have the capacity to create or update an IT system, you can consider reusing an existing [data collection tool](build/data_collection_tools). If you're reusing an existing tool, this phase is about customizing that tool to meet your needs and working out how to combine and publish your data. The [OCDS Helpdesk](../../support/#ocds-helpdesk) can help you to consider options for collecting, combining and publishing data. -```eval_rst +```{eval-rst} .. toctree:: :hidden: @@ -23,7 +23,7 @@ To publish OCDS data, you need to register an ocid prefix. **Action**: Email to request an OCID prefix. Provide the name of the publishing organization and the email address of a contact person at this organization. -```eval_rst +```{eval-rst} .. note:: .. markdown:: @@ -37,7 +37,7 @@ There are many ways to extract data from data sources, combine it, map it to OCD Your choice of architecture can determine how frequently your data is updated, whether you can publish a change history and the access methods available to your users. **Remember to check that your chosen architecture meets the needs you identified in the design stage.** -```eval_rst +```{eval-rst} .. toctree:: :hidden: @@ -73,7 +73,7 @@ Where resources allow, it is also best practice to provide multiple access metho **Tool:** [Flatten-tool](https://flatten-tool.readthedocs.io/en/latest/usage-ocds/) can be used to convert OCDS data between JSON and CSV/spreadsheet formats. -```eval_rst +```{eval-rst} .. toctree:: :hidden: @@ -87,7 +87,7 @@ Having determined your system architecture, it's time to implement it. This is o Whether your current infrastructure is low tech or high tech, we have tools and resources to help you publish OCDS. Depending on your [data sources](../map/#identify-your-data-sources) and system architecture, you might be able to reuse some of these OCDS tools: -```eval_rst +```{eval-rst} .. note:: .. markdown:: @@ -118,7 +118,7 @@ Contact the [OCDS Helpdesk](../../support/#ocds-helpdesk) for support and guidan **Resource:** To learn about how to create a spreadsheet input template for OCDS, check out our blog series on prototyping OCDS data using spreadsheets ([Part 1](https://www.open-contracting.org/2020/04/24/prototyping-ocds-data-using-spreadsheets/), [Part 2](https://www.open-contracting.org/2020/05/11/prototyping-ocds-data-using-spreadsheets-part-ii/), [Part 3](https://www.open-contracting.org/2020/05/28/prototyping-ocds-data-using-spreadsheets-part-iii/)). -```eval_rst +```{eval-rst} .. note:: .. markdown:: diff --git a/docs/guidance/build/change_history.md b/docs/guidance/build/change_history.md index c5183115e..aea7b9118 100644 --- a/docs/guidance/build/change_history.md +++ b/docs/guidance/build/change_history.md @@ -6,7 +6,7 @@ Each subsection refers to a stage or event in the contracting process lifetime. Refer to the [releases and records](../../getting_started/releases_and_records) guidance for an introduction to the concepts involved. -### Planning +## Planning The London Borough of Barnet plans to publish a tender for cycle lane improvements later in the year. To prepare the market they publish a *notice of planned procurement*. This is also known as *prior information notice*, or *future opportunity notice*. @@ -15,7 +15,7 @@ The publisher creates an OCDS release to represent this notice. The release uses The publisher also creates an OCDS record for the new contracting process. The releases list includes the new and only release so far. The compiled and versioned releases are also created for the record. Since there is only one release, the compiled version is expected look very much like this release. Compare the planning release and the record using the box below. -```eval_rst +```{eval-rst} .. jsoninclude:: ../../examples/planning.json :jsonpointer: /releases @@ -24,7 +24,7 @@ The publisher also creates an OCDS record for the new contracting process. The r ``` -```eval_rst +```{eval-rst} .. jsoninclude:: ../../examples/records/planning.json :jsonpointer: /records @@ -33,7 +33,7 @@ The publisher also creates an OCDS record for the new contracting process. The r ``` -### Tender +## Tender The London Borough of Barnet is ready to invite bids for the contract. They issue the tender via an *notice of intended procurement*. This is also known as *contract notice* or *opportunity notice*. @@ -52,7 +52,7 @@ There are no changes to the planning release published before. But the new relea The publisher adds the new release to the record, in the releases list. Also they update the compiled and versioned releases with the new information. Note that the bid submission date has changed in the compiled release. Also, note that the versioned release has a list of changes for each field that has been updated. -```eval_rst +```{eval-rst} .. jsoninclude:: ../../examples/tender.json :jsonpointer: /releases @@ -61,7 +61,7 @@ The publisher adds the new release to the record, in the releases list. Also the ``` -```eval_rst +```{eval-rst} .. jsoninclude:: ../../examples/records/tender.json :jsonpointer: /records @@ -70,7 +70,7 @@ The publisher adds the new release to the record, in the releases list. Also the ``` -### Tender Update +## Tender Update The enquiry period has ended, and a few questions from potential suppliers have been received. The procuring entity issues a document with the responses to the enquiries received from bidders. @@ -80,7 +80,7 @@ The previous releases of planning and tender are not changed. In the new release The record now has three immutable releases, and updated compiled and versioned releases. Note that the compiled release includes the enquiries document in the tender section. Also, the field `tender.hasEnquiries` has more than one entry in the versioned release. -```eval_rst +```{eval-rst} .. jsoninclude:: ../../examples/tenderUpdate.json :jsonpointer: /releases @@ -89,7 +89,7 @@ The record now has three immutable releases, and updated compiled and versioned ``` -```eval_rst +```{eval-rst} .. jsoninclude:: ../../examples/records/tenderUpdate.json :jsonpointer: /records @@ -98,7 +98,7 @@ The record now has three immutable releases, and updated compiled and versioned ``` -### Award +## Award The procuring entity makes the decision to award the contract to Balfour Beatty. They issue an award notice. @@ -108,7 +108,7 @@ The `parties` array has a new entry with the supplier's information. The complet The publisher adds the new release to the record. They also update the compiled and versioned releases. The compiled release reflects the changes to the `awards`, `tender` and `parties` sections. The versioned release includes a new change for the `tender.status` field. -```eval_rst +```{eval-rst} .. jsoninclude:: ../../examples/award.json :jsonpointer: /releases @@ -117,7 +117,7 @@ The publisher adds the new release to the record. They also update the compiled ``` -```eval_rst +```{eval-rst} .. jsoninclude:: ../../examples/records/award.json :jsonpointer: /records @@ -126,7 +126,7 @@ The publisher adds the new release to the record. They also update the compiled ``` -### Contract +## Contract By law, the procuring entity has to wait for complaints for a given period of time before signing a contract. Once the period ends with no complaints, the contract with the supplier is signed. @@ -135,7 +135,7 @@ The publisher creates a new OCDS release using the 'contract' tag. They include The record gets updated to include the new release. The compiled and versioned release now have the new `contract` section. There are no updates to other sections. -```eval_rst +```{eval-rst} .. jsoninclude:: ../../examples/contract.json :jsonpointer: /releases @@ -144,7 +144,7 @@ The record gets updated to include the new release. The compiled and versioned r ``` -```eval_rst +```{eval-rst} .. jsoninclude:: ../../examples/records/contract.json :jsonpointer: /records @@ -154,7 +154,7 @@ The record gets updated to include the new release. The compiled and versioned r ``` -### Implementation +## Implementation The supplier starts the construction work. After a while, the procuring entity makes the first payment to the supplier. The publisher creates a release to document this update in the process. @@ -179,7 +179,7 @@ OCDS can be used to combine data from different systems. For more information re The publisher adds the new release from the finance system to the releases list in the OCDS record. The compiled and versioned releases get updated to include the new transaction. -```eval_rst +```{eval-rst} .. jsoninclude:: ../../examples/implementation.json :jsonpointer: /releases @@ -188,7 +188,7 @@ The publisher adds the new release from the finance system to the releases list ``` -```eval_rst +```{eval-rst} .. jsoninclude:: ../../examples/records/implementation.json :jsonpointer: /records @@ -197,7 +197,7 @@ The publisher adds the new release from the finance system to the releases list ``` -### Contract Amendment +## Contract Amendment Unexpected complications causes delays in the construction work. Because of them the procuring entity and the supplier agree to a contract extension. This will cover the extra time and cost needed to complete the works. @@ -208,7 +208,7 @@ Note that contract amendments in OCDS involves more modelling considerations. Re The publisher updates the record for the contracting process with the new release. The compiled release has the new values. The versioned release shows new entries for the contract’s value and end date. -```eval_rst +```{eval-rst} .. jsoninclude:: ../../examples/contractAmendment.json :jsonpointer: /releases @@ -217,7 +217,7 @@ The publisher updates the record for the contracting process with the new releas ``` -```eval_rst +```{eval-rst} .. jsoninclude:: ../../examples/records/contractAmendment.json :jsonpointer: /records diff --git a/docs/guidance/build/easy_releases.md b/docs/guidance/build/easy_releases.md index 5d0e6f9f4..28475e5d5 100644 --- a/docs/guidance/build/easy_releases.md +++ b/docs/guidance/build/easy_releases.md @@ -65,7 +65,7 @@ The contracting process begins with a tender notice. The source tables contain t **ProcurementProcess** -```eval_rst +```{eval-rst} .. csv-table-no-translate:: :header-rows: 1 :file: ../../examples/easy-releases/worked-example-1/1-tender-procurementProcess.csv @@ -91,7 +91,7 @@ It is possible to use the date alone as the release identifier, but prepending t See the full JSON file below. -```eval_rst +```{eval-rst} .. jsoninclude:: ../../examples/easy-releases/worked-example-1/1-tender.json :jsonpointer: :expand: releases,tender @@ -103,7 +103,7 @@ The tender has been updated: the value increased slighly and the description has **ProcurementProcess** -```eval_rst +```{eval-rst} .. csv-table-no-translate:: :header-rows: 1 :file: ../../examples/easy-releases/worked-example-1/2-tenderUpdate-procurementProcess.csv @@ -119,7 +119,7 @@ The `lastModifiedDate` value has changed as well, therefore the value of the rel See the full JSON below: -```eval_rst +```{eval-rst} .. jsoninclude:: ../../examples/easy-releases/worked-example-1/2-tenderUpdate.json :jsonpointer: :expand: releases,tag,tender @@ -133,7 +133,7 @@ Now, the tender has been awarded. The related columns in 'ProcurementProcess' ta **ProcurementProcess** -```eval_rst +```{eval-rst} .. csv-table-no-translate:: :header-rows: 1 :file: ../../examples/easy-releases/worked-example-1/3-award-procurementProcess.csv @@ -141,7 +141,7 @@ Now, the tender has been awarded. The related columns in 'ProcurementProcess' ta **Supplier** -```eval_rst +```{eval-rst} .. csv-table-no-translate:: :header-rows: 1 :file: ../../examples/easy-releases/worked-example-1/3-award-supplier.csv @@ -157,7 +157,7 @@ As the 'ProcurementProcess' table has been updated, the related release will hav And the 'awards' section will be filled with the corresponding data. See the full JSON below. -```eval_rst +```{eval-rst} .. jsoninclude:: ../../examples/easy-releases/worked-example-1/3-award.json :jsonpointer: :expand: releases,awards @@ -171,7 +171,7 @@ At the last stage there is a signed contract. The 'ProcurementProcess' table cha **ProcurementProcess** -```eval_rst +```{eval-rst} .. csv-table-no-translate:: :header-rows: 1 :file: ../../examples/easy-releases/worked-example-1/4-contract-procurementProcess.csv @@ -179,7 +179,7 @@ At the last stage there is a signed contract. The 'ProcurementProcess' table cha **Contract** -```eval_rst +```{eval-rst} .. csv-table-no-translate:: :header-rows: 1 :file: ../../examples/easy-releases/worked-example-1/4-contract-contract.csv @@ -195,7 +195,7 @@ A new release id is generated: See the full JSON below. -```eval_rst +```{eval-rst} .. jsoninclude:: ../../examples/easy-releases/worked-example-1/4-contract.json :jsonpointer: :expand: releases,contracts @@ -215,7 +215,7 @@ The example starts with the tender, and the following data in the 'ProcurementPr **ProcurementProcess** -```eval_rst +```{eval-rst} .. csv-table-no-translate:: :header-rows: 1 :file: ../../examples/easy-releases/worked-example-1/1-tender-procurementProcess.csv @@ -240,7 +240,7 @@ It is important to include *all* data fields that are included in OCDS data in t See the full JSON below. -```eval_rst +```{eval-rst} .. jsoninclude:: ../../examples/easy-releases/worked-example-2/1-tender.json :jsonpointer: :expand: releases,tender @@ -252,7 +252,7 @@ Now that tender data has changed: there are updates in the value and description **ProcurementProcess** -```eval_rst +```{eval-rst} .. csv-table-no-translate:: :header-rows: 1 :file: ../../examples/easy-releases/worked-example-2/2-tenderUpdate-procurementProcess.csv @@ -268,7 +268,7 @@ The same hash operation is repeated over the updated row and the resulting value See the full JSON below. -```eval_rst +```{eval-rst} .. jsoninclude:: ../../examples/easy-releases/worked-example-2/2-tenderUpdate.json :jsonpointer: :expand: releases,tag,tender @@ -280,7 +280,7 @@ The tender has been awarded, therefore the 'ProcurementProcess' table has been u **ProcurementProcess** -```eval_rst +```{eval-rst} .. csv-table-no-translate:: :header-rows: 1 :file: ../../examples/easy-releases/worked-example-2/3-award-procurementProcess.csv @@ -288,7 +288,7 @@ The tender has been awarded, therefore the 'ProcurementProcess' table has been u **Supplier** -```eval_rst +```{eval-rst} .. csv-table-no-translate:: :header-rows: 1 :file: ../../examples/easy-releases/worked-example-2/3-award-supplier.csv @@ -317,7 +317,7 @@ The result of the query is `610d5900f947bcf67100449999ea49ce`, and the new relea See the full JSON below. -```eval_rst +```{eval-rst} .. jsoninclude:: ../../examples/easy-releases/worked-example-2/3-award.json :jsonpointer: :expand: releases,awards @@ -329,7 +329,7 @@ In the last stage the contract is signed, the 'ProcurementProcess' table is upda **ProcurementProcess** -```eval_rst +```{eval-rst} .. csv-table-no-translate:: :header-rows: 1 :file: ../../examples/easy-releases/worked-example-2/4-contract-procurementProcess.csv @@ -337,7 +337,7 @@ In the last stage the contract is signed, the 'ProcurementProcess' table is upda **Contract** -```eval_rst +```{eval-rst} .. csv-table-no-translate:: :header-rows: 1 :file: ../../examples/easy-releases/worked-example-2/4-contract-contract.csv @@ -369,7 +369,7 @@ The new hash value is `1a87b0662990c66e140e62e813165107`, and the new release id See the final JSON below. -```eval_rst +```{eval-rst} .. jsoninclude:: ../../examples/easy-releases/worked-example-2/4-contract.json :jsonpointer: :expand: releases,contracts diff --git a/docs/guidance/build/merging.md b/docs/guidance/build/merging.md index 283ba3efc..aebb49e11 100644 --- a/docs/guidance/build/merging.md +++ b/docs/guidance/build/merging.md @@ -19,42 +19,42 @@ In each release, the agency also updates the record, which combines all the rele * The compiled release contains all the information about the opportunity and awards, using the same schema as a release. * The versioned release makes it easy to see how the description and total estimated value changed over time. -```eval_rst +```{eval-rst} .. jsoninclude:: ../../examples/merging/merge-tender-1.json :jsonpointer: :expand: releases, tag, tender :title: tender ``` -```eval_rst +```{eval-rst} .. jsoninclude:: ../../examples/merging/merge-tender-2.json :jsonpointer: :expand: releases, tag, tender :title: tenderUpdate ``` -```eval_rst +```{eval-rst} .. jsoninclude:: ../../examples/merging/merge-tender-3.json :jsonpointer: :expand: releases, tag, tender :title: tenderAmendment ``` -```eval_rst +```{eval-rst} .. jsoninclude:: ../../examples/merging/merge-award-1.json :jsonpointer: :expand: releases, tag, awards :title: awardOne ``` -```eval_rst +```{eval-rst} .. jsoninclude:: ../../examples/merging/merge-award-2.json :jsonpointer: :expand: releases, tag, awards :title: awardTwo ``` -```eval_rst +```{eval-rst} .. jsoninclude:: ../../examples/merging/versioned.json :jsonpointer: :expand: records, compiledRelease, versionedRelease, tag, tender, awards @@ -71,21 +71,21 @@ After a few weeks, the tender is ready to be announced. The officer in charge no In the final record, both the compiled and versioned releases show the changes. The `planning/rationale` field has disappeared from the `compiledRelease`, and the `versionedRelease` shows both its previous value and the `null` value used to delete the field. The entry with the `null` value can be used to determine when the field was deleted. -```eval_rst +```{eval-rst} .. jsoninclude:: ../../examples/merging/example02-field-planning.json :jsonpointer: :expand: releases, tag, planning :title: planning ``` -```eval_rst +```{eval-rst} .. jsoninclude:: ../../examples/merging/example02-field-tender.json :jsonpointer: :expand: releases, tag, planning, tender :title: tender ``` -```eval_rst +```{eval-rst} .. jsoninclude:: ../../examples/merging/example02-field-record.json :jsonpointer: :expand: records, compiledRelease, versionedRelease @@ -102,21 +102,21 @@ A release with a 'tenderAmendment' tag is published, in which both the `startDat The final record is shown below. Note that the fields in the `contractPeriod` block have disappeared in the `compiledRelease`, and the `versionedRelease` contains the previous values. -```eval_rst +```{eval-rst} .. jsoninclude:: ../../examples/merging/example02-object-tender.json :jsonpointer: :expand: releases, tag, tender :title: tender ``` -```eval_rst +```{eval-rst} .. jsoninclude:: ../../examples/merging/example02-object-tenderAmendment.json :jsonpointer: :expand: releases, tag, tender, amendments :title: tenderAmendment ``` -```eval_rst +```{eval-rst} .. jsoninclude:: ../../examples/merging/example02-object-record.json :jsonpointer: :expand: records, compiledRelease, versionedRelease @@ -131,28 +131,28 @@ Two weeks later, the authority publishes a new release. Due to negotiations with The NGO generates a record. In the record, all the fields of the removed item have disappeared, and only its `id` is left. -```eval_rst +```{eval-rst} .. jsoninclude:: ../../examples/merging/example03-award.json :jsonpointer: :expand: releases, tag, awards :title: award ``` -```eval_rst +```{eval-rst} .. jsoninclude:: ../../examples/merging/example03-awardAmendment.json :jsonpointer: :expand: releases, tag, awards, amendments, items :title: awardAmendment ``` -```eval_rst +```{eval-rst} .. jsoninclude:: ../../examples/merging/example03-record.json :jsonpointer: :expand: records, compiledRelease, versionedRelease :title: record ``` -```eval_rst +```{eval-rst} .. note:: The current `merge routine <../../../schema/merging#merge-routine>`__ does not include a strategy to completely remove an entry from an array. We invite discussion on how to remove objects from arrays in issue `#232 `__. diff --git a/docs/guidance/build/serialization.md b/docs/guidance/build/serialization.md index 57829eb89..6d1cf588c 100644 --- a/docs/guidance/build/serialization.md +++ b/docs/guidance/build/serialization.md @@ -40,7 +40,7 @@ In each case, fields are identified in CSV headers by their [JSON Pointer](http: **JSON** -```eval_rst +```{eval-rst} .. jsoninclude:: ../../examples/serialization-flat.json :jsonpointer: :expand: releases, tender, items @@ -49,7 +49,7 @@ In each case, fields are identified in CSV headers by their [JSON Pointer](http: **CSV** -```eval_rst +```{eval-rst} .. csv-table-no-translate:: :header-rows: 1 :file: ../../examples/serialization-flat.csv @@ -68,7 +68,7 @@ It is, however, theoretically possible to represent a full release in a single f For example, to represent a tender release with two items, the CSV file would include: -```eval_rst +```{eval-rst} .. csv-table-no-translate:: :header-rows: 1 :file: ../../examples/serialization-flat-two-items.csv @@ -77,7 +77,7 @@ For example, to represent a tender release with two items, the CSV file would in The JSON equivalent of this would be: -```eval_rst +```{eval-rst} .. jsoninclude:: ../../examples/serialization-flat-two-items.json :jsonpointer: :expand: releases, tender, items @@ -88,7 +88,7 @@ Whilst this allows complex data to be expressed in flat CSV, users will need to Instead, data with a one-to-many relationship can be represented using a multi-table serialization. -```eval_rst +```{eval-rst} .. admonition:: CSV encoding :class: note @@ -102,7 +102,7 @@ The multi-table serialization separates objects with many to one relationships Multiple tables can be packaged together as the tabs of an Excel spreadsheet, or in a collection of CSV files. -An example multi-table template can be found [in the sample data repository](https://github.com/open-contracting/sample-data/tree/master/flat-template). +An example multi-table template can be found [in the sample data repository](https://github.com/open-contracting/sample-data/tree/main/flat-template). For further information on multi-table serializations please see the [flatten tool documentation](http://flatten-tool.readthedocs.io/en/latest/). diff --git a/docs/guidance/design.md b/docs/guidance/design.md index 9708c9424..7d75c6cbc 100644 --- a/docs/guidance/design.md +++ b/docs/guidance/design.md @@ -11,7 +11,7 @@ On this page, you will find guidance on how to: * Understand your key decisions and publication goals * Include OCDS in requirements for software developers and technical consultants -```eval_rst +```{eval-rst} .. note:: .. markdown:: @@ -86,6 +86,7 @@ To achieve success, an OCDS implementation team ought to include the following r * A **procurement expert** who will identify where data put forward for publication in OCDS exists at a semantic level. They need to be familiar with procurement legislation and procedures. * A **policy champion** who can help navigate the policy decisions of publishing and using OCDS data * A **system architect** who will define the architecture for publishing OCDS data. They can be an internal team member or an external consultant. +* A **software developer**, or developers, who will write the code for publishing OCDS data. They can be an internal team member or an external consultant. If you're updating an existing system, ideally the developer should be familiar with that system, or at least the relevant technologies, frameworks, and programming languages. * A **user champion** who will represent the needs of data users throughout the project. They can be an internal team member, an outside partner, or a representative of external stakeholders. **Action:** Identify your team members. diff --git a/docs/guidance/index.md b/docs/guidance/index.md index b1a90b14e..7d92397be 100644 --- a/docs/guidance/index.md +++ b/docs/guidance/index.md @@ -6,7 +6,7 @@ The four phases of implementation described in this guide have helped implemente Read the guidance to understand the main steps to implement OCDS and to find supporting resources. Detailed guidance on specific topics and tasks is provided in sub-pages. -```eval_rst +```{eval-rst} .. toctree:: :maxdepth: 2 diff --git a/docs/guidance/map.md b/docs/guidance/map.md index 2a7ddc649..49d08aaa4 100644 --- a/docs/guidance/map.md +++ b/docs/guidance/map.md @@ -47,7 +47,7 @@ You can [contact the OCDS Helpdesk](../../support/#ocds-helpdesk) for support an Before working on mapping individual fields and codes, consider whether to first [localize OCDS](map/localization) to your context. Localization can be useful when you need to map several different systems, or when multiple organizations will work on implementing OCDS in your country. -```eval_rst +```{eval-rst} .. toctree:: :hidden: @@ -88,7 +88,7 @@ Whichever approach you take, it's important that your eventual OCDS publication Mapping data to OCDS is not always obvious. Please refer to our how-to guides and worked examples to learn how to map data for specific cases: -```eval_rst +```{eval-rst} .. toctree:: :maxdepth: 2 :titlesonly: @@ -120,7 +120,7 @@ Some data elements might not match any field or code in OCDS. To cover such case **Action:** If you are stuck on a particular concept and are concerned about how it is modelled in OCDS, search the issues in our [Github tracker](https://github.com/open-contracting/standard/issues) to see what others in the community are saying about the topic. If you do not see your issue, create a new one! -```eval_rst +```{eval-rst} .. toctree:: :hidden: diff --git a/docs/guidance/map/amendments.md b/docs/guidance/map/amendments.md index b7f5fd3c3..c06698e0e 100644 --- a/docs/guidance/map/amendments.md +++ b/docs/guidance/map/amendments.md @@ -26,7 +26,7 @@ This example goes through updates during the **tender** stage in a contracting p A publisher issues a tender for a "Data merge tool". A new release with the `tag` 'tender' is built, see the JSON example below. -```eval_rst +```{eval-rst} .. jsoninclude:: ../../_static/json/amendments/amendments-tender-example.json :jsonpointer: /records/0/releases/0 @@ -39,7 +39,7 @@ A publisher issues a tender for a "Data merge tool". A new release with the `tag Weeks later, the publisher expands the `description` of the tender to provide more details about the tool being procured. A new release with the `tag` 'tenderUpdate' is built. The publisher does not consider this to be a formal 'amendment' to the tender, so does not publish any amendment information. See the JSON release below. -```eval_rst +```{eval-rst} .. jsoninclude:: ../../_static/json/amendments/amendments-tender-example.json :jsonpointer: /records/0/releases/1 @@ -52,7 +52,7 @@ Weeks later, the publisher expands the `description` of the tender to provide mo A few days later, the publisher increases the value of the tender and extends the deadline for bid submissions. These changes are considered as an 'amendment' by the publisher (depending on jurisdiction, certain changes can need to be disclosed as amendments), and so the new release has the `tag` 'tenderAmendment' and an `amendments` block under `tender`. The release reflects the updated value (USD 2000 instead of USD 1000) and the updated closing date for bid submissions (`2012-02-20` instead of `2012-02-15`). See the JSON example below. -```eval_rst +```{eval-rst} .. jsoninclude:: ../../_static/json/amendments/amendments-tender-example.json :jsonpointer: /records/0/releases/2 @@ -65,7 +65,7 @@ A few days later, the publisher increases the value of the tender and extends th A full record is provided below, with all the releases for the process and a `compiledRelease` and `versionedRelease`. The `versionedRelease` block reflects all the changes made in the tender. -```eval_rst +```{eval-rst} .. jsoninclude:: ../../_static/json/amendments/amendments-tender-example.json :jsonpointer: @@ -100,7 +100,7 @@ A contract notice is published for the purchase of domestic appliances. The publ See the JSON release below. -```eval_rst +```{eval-rst} .. jsoninclude:: ../../_static/json/amendments/amendments-contract-example.json :jsonpointer: /records/0/releases/0 @@ -115,7 +115,7 @@ A few days after the contract release, its scope is increased to include the pur See the example release below. -```eval_rst +```{eval-rst} .. jsoninclude:: ../../_static/json/amendments/amendments-contract-example.json :jsonpointer: /records/0/releases/1 @@ -134,7 +134,7 @@ An example record for the whole process is shown below. Consider downloading the Note that the `compiledRelease` contains all the items, included the latest one added in the contract amendment. -```eval_rst +```{eval-rst} .. jsoninclude:: ../../_static/json/amendments/amendments-contract-example.json :jsonpointer: @@ -151,7 +151,7 @@ Where the source system stores a history of contract amendments, either as separ The table below shows an example of a contract notices table from a procurement system, with an original contract in the first row and an amendment of the same contract in the second. The amendment increases the value of the original contract and changes the contract period. -```eval_rst +```{eval-rst} .. csv-table-no-translate:: :file: ../../examples/amendments-contract-notice.csv :header-rows: 1 @@ -159,7 +159,7 @@ The table below shows an example of a contract notices table from a procurement This can be modelled as the separate releases in OCDS as shown below. The original `contract` release includes all the fields from the first entry in the contract notices table. A `contractAmendment` release is built for each contract amendment identified in the table (by verifying that the `amendmentId` column in the contract notices table is not empty). -```eval_rst +```{eval-rst} .. jsoninclude:: ../../_static/json/amendments/amendments-easy-releases-example.json :jsonpointer: /records/0/releases/1 @@ -168,7 +168,7 @@ This can be modelled as the separate releases in OCDS as shown below. The origin ``` -```eval_rst +```{eval-rst} .. jsoninclude:: ../../_static/json/amendments/amendments-easy-releases-example.json :jsonpointer: /records/0/releases/2 diff --git a/docs/guidance/map/award_notices_decisions.md b/docs/guidance/map/award_notices_decisions.md index 98d4393cb..8562cfad5 100644 --- a/docs/guidance/map/award_notices_decisions.md +++ b/docs/guidance/map/award_notices_decisions.md @@ -13,7 +13,7 @@ In Paraguay, a single award notice is used to disclose many award decisions. Det Using a single award object to model such a notice in OCDS would make it impossible to determine which items related to which suppliers or how much of the total award value related to each supplier: -```eval_rst +```{eval-rst} .. csv-table-no-translate:: :header-rows: 1 :file: ../../examples/award_decisions/single_award.csv @@ -21,7 +21,7 @@ Using a single award object to model such a notice in OCDS would make it impossi For the award object in OCDS to communicate a direct relationship between items, suppliers, and values, Paraguay's award notice is split into multiple award objects, one for each supplier/value pairing on the notice. -```eval_rst +```{eval-rst} .. csv-table-no-translate:: :header-rows: 1 :file: ../../examples/award_decisions/multi_award.csv @@ -29,13 +29,13 @@ For the award object in OCDS to communicate a direct relationship between items, There are no identifiers for the individual supplier/value pairings on the original award notice, so it is necessary to create a new identifier for each award object in OCDS. The approach to creating an identifier will depend on the properties of the dataset; for example, in Paraguay a combination of the award notice identifier, supplier name, and a consecutive number is used. -```eval_rst +```{eval-rst} .. csv-table-no-translate:: :header-rows: 1 :file: ../../examples/award_decisions/identifiers.csv ``` -```eval_rst +```{eval-rst} .. admonition:: View the example in JSON :class: tip diff --git a/docs/guidance/map/awards_contracts_buyers_suppliers.md b/docs/guidance/map/awards_contracts_buyers_suppliers.md index 0d96d7a74..ec29cf76a 100644 --- a/docs/guidance/map/awards_contracts_buyers_suppliers.md +++ b/docs/guidance/map/awards_contracts_buyers_suppliers.md @@ -16,7 +16,7 @@ The [UNCITRAL Model Law on Public Procurement (2011)](https://uncitral.un.org/en In OCDS, the `Award` object is intended to communicate a direct relationship between items, suppliers, and values. It ought to be possible to know, at the award stage, in OCDS data, which items will later be supplied by which suppliers, and what the value of those contracts will be. -```eval_rst +```{eval-rst} .. admonition:: Note :class: note @@ -36,7 +36,7 @@ Contracting processes can result in different types of contract between buyers a In OCDS, the `Contract` object is intended to communicate a legally binding agreement between a buyer and suppliers to provide items. This excludes agreements to set-up a structure through which contracts are later awarded to provide items, for example: a contract to set up or add suppliers to a framework agreement or dynamic purchasing system. -```eval_rst +```{eval-rst} .. admonition:: Note :class: note @@ -50,9 +50,11 @@ In OCDS, the `Contract` object is intended to communicate a legally binding agre OCDS defines the buyer as: -> *an entity whose budget will be used to pay for goods, works or services related to a contract. This may be different from the procuring entity who may be specified in the tender data.* +```{eval-rst} +.. field-description:: ../../../build/current_lang/release-schema.json /properties/buyer +``` -```eval_rst +```{eval-rst} .. admonition:: Note :class: note @@ -70,17 +72,20 @@ OCDS defines the buyer as: OCDS defines a supplier as: -> *An entity awarded or contracted to provide goods, works or services.* - -### Electronic Catalog +```{eval-rst} +.. code-description:: ../../../build/current_lang/codelists/partyRole.csv supplier +``` -[EU directive 2014/24/EU](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex%3A32014L0024) on public procurement categorises an electronic catalog as a techniques, or instrument, for electronic and aggregated procurement and describes an electronic catalog as: +### Electronic catalog -> *...a format for the presentation and organisation of information in a manner that is common to all the participating bidders and which lends itself to electronic treatment* +```{eval-rst} +.. admonition:: Hint + :class: hint -The [Chartered Institute of Procurement and Supply](https://www.cips.org/en-NZ/knowledge/procurement-topics-and-skills/ecommerce---systems/e-sourcing--e-procurement-systems-p2p/catalogue-management/) describes an electronic catalog as: + .. markdown:: -> *a web resource that provides information on products and services offered and sold by a vendor, and supports on-line ordering and payment capabilities.* + Electronic catalogs can often be found in more complicated procedures, usually together with framework agreements and involving multiple bidders. However, on their own, they are simply an electronic format (typically prescribed by the buyer) that participants in the contracting process must follow when exchaning information about technical specifications, evaluation criteria, bids, lots, etc. As such, catalogs do not influence the relationship between awards, contracts, buyers and suppliers. +``` ### Purchase order @@ -161,14 +166,13 @@ That said, many organizations can be assigned the 'buyer' role in the `parties` ## Examples -```eval_rst +```{eval-rst} .. toctree:: :maxdepth: 1 award_notices_decisions mapping_awards_contracts consortia - catalogs frameworks purchase_orders diff --git a/docs/guidance/map/catalogs.md b/docs/guidance/map/catalogs.md deleted file mode 100644 index 5173863b7..000000000 --- a/docs/guidance/map/catalogs.md +++ /dev/null @@ -1,53 +0,0 @@ -# Purchases from electronic catalogs - -Electronic catalogs are a technique, or instrument, for electronic procurement, in which the exact quantity or value of items to be provided by each supplier are not known in advance when the catalog is set-up. - -When a buyer makes a purchase from an electronic catalog, an order is placed with a supplier for a specific quantity or value of items. - -In OCDS, purchases from electronic catalogs ought to be modelled using `awards` and `contracts`, since catalog purchases: - -1. Create a direct relationship between the items being purchased, the supplier providing the items, and the value of the items (an award in OCDS) - -2. Result in a legally binding agreement for the supplier to provide the items (a contract in OCDS) - -Modelling purchases from electronic catalogs using `awards` and `contracts` makes it easier to combine data on electronic catalog purchases with data on purchases made using other procurement techniques. - -## Example: Combining data from different procurement techniques - -Australia's Department of Defence uses an electronic catalog for purchases of basic office supplies (pens, paper, toner cartridges, etc.). - -3 suppliers provide the items in the catalog: COS, Office National and Mega Office Supplies. Each provides different categories of office supplies. - -In July 2019, the department makes 3 separate purchases from the catalog: envelopes that are supplied by COS, whiteboard markers that are supplied by Office National, and sticky notes that are supplied by Mega Office Supplies. These purchases are represented in the `awards` section of OCDS as follows: - -```eval_rst -.. csv-table-no-translate:: - :header-rows: 1 - :file: ../../examples/catalogs/catalog_purchases.csv -``` - -During the same month, the department also concludes a separate contracting process to procure 30 office desks by awarding a contract to Office National. This purchase is also represented in the `awards` section of OCDS: - -```eval_rst -.. csv-table-no-translate:: - :header-rows: 1 - :file: ../../examples/catalogs/separate_process.csv -``` - -By using the `awards` section consistently for both contracting processes, it is possible to calculate the total value of purchases from Office National in July 2019, using only the `awards` section: - -```eval_rst -.. csv-table-no-translate:: - :header-rows: 1 - :file: ../../examples/catalogs/combined.csv -``` - -```eval_rst -.. admonition:: Note - :class: note - - .. markdown:: - - The approach for modelling the set-up and second stages of electronic catalogs in OCDS is under discussion ([GitHub issue](https://github.com/open-contracting/standard/issues/396)). - -``` diff --git a/docs/guidance/map/consortia.md b/docs/guidance/map/consortia.md index f043c406e..35cf8701f 100644 --- a/docs/guidance/map/consortia.md +++ b/docs/guidance/map/consortia.md @@ -14,7 +14,7 @@ The contract is awarded to the consortium; however, the legal entity for the con Both Siemens and Microsoft are listed as suppliers on the contract award in OCDS, with the respective legal entity identifiers for each organization: -```eval_rst +```{eval-rst} .. csv-table-no-translate:: :header-rows: 1 :file: ../../examples/consortia_simple.csv diff --git a/docs/guidance/map/extensions.md b/docs/guidance/map/extensions.md index 67fd29055..1ad65cadd 100644 --- a/docs/guidance/map/extensions.md +++ b/docs/guidance/map/extensions.md @@ -18,7 +18,7 @@ Extensions are applied by adding their URLs to the `extensions` array in the rel This version of OCDS uses these specific versions of core extensions: -```eval_rst +```{eval-rst} .. extensionexplorerlinklist:: ``` @@ -41,11 +41,11 @@ Groups of extensions can be combined into **profiles**. OCDS provides a common c ### OCDS for the European Union -[OCDS for the European Union](https://standard.open-contracting.org/profiles/eu/master/en/) describes how to express, in OCDS, the information in Tenders Electronic Daily (TED) notices as obliged by law within the EU. +[OCDS for the European Union](https://standard.open-contracting.org/profiles/eu/latest/en/) describes how to express, in OCDS, the information in Tenders Electronic Daily (TED) notices as obliged by law within the EU. ### OCDS for the Agreement on Government Procurement -[OCDS for the Agreement on Government Procurement](https://standard.open-contracting.org/profiles/gpa/master/en/) (GPA) describes how to use OCDS to publish information as obliged by the World Trade Organization’s [Agreement on Government Procurement](https://www.wto.org/english/docs_e/legal_e/rev-gpr-94_01_e.htm). +[OCDS for the Agreement on Government Procurement](https://standard.open-contracting.org/profiles/gpa/latest/en/) (GPA) describes how to use OCDS to publish information as obliged by the World Trade Organization’s [Agreement on Government Procurement](https://www.wto.org/english/docs_e/legal_e/rev-gpr-94_01_e.htm). ## Linked standards diff --git a/docs/guidance/map/frameworks.md b/docs/guidance/map/frameworks.md index daf36345f..354c41dc2 100644 --- a/docs/guidance/map/frameworks.md +++ b/docs/guidance/map/frameworks.md @@ -1,6 +1,6 @@ # Framework agreements -```eval_rst +```{eval-rst} .. admonition:: Note :class: note diff --git a/docs/guidance/map/localization.md b/docs/guidance/map/localization.md index a2a07d69c..6ce2ce8ca 100644 --- a/docs/guidance/map/localization.md +++ b/docs/guidance/map/localization.md @@ -20,7 +20,7 @@ You can use the [field-level mapping template](https://www.open-contracting.org/ To localize a field title or description, edit the values columns C or D. We recommend that you keep the original title or description in brackets after your localized version. For example: -```eval_rst +```{eval-rst} .. csv-table:: :file: ../../examples/localization.csv :widths: 30,70 @@ -29,7 +29,7 @@ To localize a field title or description, edit the values columns C or D. We rec This makes it easier for reviewers to check that localization has not changed the meaning of titles and descriptions. You can use the comments feature of Google Docs to discuss the proposed localization. -```eval_rst +```{eval-rst} .. admonition:: Warning :class: warning @@ -46,7 +46,7 @@ Similarly, you can use the [codelist mapping template](https://www.open-contract To localize a code title or description, edit the values in columns B and C. As with field titles and descriptions, we recommend that you keep the original title or description in brackets after your localized version. -```eval_rst +```{eval-rst} .. admonition:: Warning :class: warning diff --git a/docs/guidance/map/milestones.md b/docs/guidance/map/milestones.md index e69f10971..7e4a656bc 100644 --- a/docs/guidance/map/milestones.md +++ b/docs/guidance/map/milestones.md @@ -54,7 +54,7 @@ In the tender release: * The `.dateMet` field in the tender notice milestone is updated with the actual date the notice was issued and `.status` is set to 'met'. To explore differences between the planned and actual date of the tender milestone, users can then compare the values of `tender/milestones/dueDate` and `tender/milestones/dateMet` in a single (compiled) release. -```eval_rst +```{eval-rst} .. jsoninclude:: ../../examples/milestones/planning-tender-milestones.json :jsonpointer: @@ -96,7 +96,7 @@ Users can compare the project commencement milestone's `.dueDate` and `.dateMet` In the second implementation update release, which is published after the project completes: * In the project completion milestone, `.dateMet` is set to the actual completion date for the project and `.status` is set to 'met'. -```eval_rst +```{eval-rst} .. jsoninclude:: ../../examples/milestones/implementation-milestones-1.json :jsonpointer: @@ -105,7 +105,7 @@ In the second implementation update release, which is published after the projec ``` -```eval_rst +```{eval-rst} .. jsoninclude:: ../../examples/milestones/implementation-milestones-2.json :jsonpointer: @@ -114,7 +114,7 @@ In the second implementation update release, which is published after the projec ``` -```eval_rst +```{eval-rst} .. jsoninclude:: ../../examples/milestones/implementation-milestones-3.json :jsonpointer: @@ -145,7 +145,7 @@ In the second implementation update release: * The construction company has received payment for the work done so far, so the milestone for the wall restoration with type 'financing' is updated. A new `transaction` is disclosed, with the amount paid to the company. -```eval_rst +```{eval-rst} .. jsoninclude:: ../../examples/milestones/af-implementation-milestones-1.json :jsonpointer: @@ -154,7 +154,7 @@ In the second implementation update release: ``` -```eval_rst +```{eval-rst} .. jsoninclude:: ../../examples/milestones/af-implementation-milestones-2.json :jsonpointer: @@ -163,7 +163,7 @@ In the second implementation update release: ``` -```eval_rst +```{eval-rst} .. jsoninclude:: ../../examples/milestones/af-implementation-milestones-3.json :jsonpointer: diff --git a/docs/guidance/map/organization_classifications.md b/docs/guidance/map/organization_classifications.md index 7e18a3670..9985007c1 100644 --- a/docs/guidance/map/organization_classifications.md +++ b/docs/guidance/map/organization_classifications.md @@ -21,7 +21,7 @@ A third, discouraged, example approach using local extensions is also given belo In the example below, Moldova has disclosed information about the 'Companie mică' organization using the [party scale extension](https://extensions.open-contracting.org/en/extensions/partyScale/master/). The scale is given as 'micro', from the [partyScale codelist](https://extensions.open-contracting.org/en/extensions/partyScale/master/codelists/). -```eval_rst +```{eval-rst} .. jsoninclude:: ../../examples/organization-classification/moldova_organization_scale.json :jsonpointer: @@ -46,7 +46,7 @@ In the first fictional example below, the UK has disclosed a code from two diffe Note that the `classification.id` relates to the id of the code in the `classification.scheme` given, rather than its position in the `classifications` array. Therefore, the first `classification` shows that the `id` of 'Regional or local authority' in the 'TED_CA_TYPE' scheme is 'REGIONAL_AUTHORITY', and the second `classification` shows that the `id` of 'General public services' in the 'COFOG' scheme is '01'. -```eval_rst +```{eval-rst} .. jsoninclude:: ../../examples/organization-classification/uk_organization_classification.json :jsonpointer: @@ -61,7 +61,7 @@ The second example below is set in the fictional city of Ciudad Ficticia in Colo In their publication policy, the procurement team documents all possible codes for COL-CF-MON with definitions of each code, including explaining that 'NPDM' is for businesses registered with the local Chamber of Commerce where ownership and control is at least 51% women. -```eval_rst +```{eval-rst} .. jsoninclude:: ../../examples/organization-classification/fictional_wob_organization_classification.json :jsonpointer: @@ -78,7 +78,7 @@ For example, although tracking women-owned organizations is shown example 2.2 ab To disambiguate these cases, a publisher can choose to publish a flag field for the relevant organization classification. In the fictional example below, Dhanghadi has created a local extension so they can publish data in the `parties.details` block on an organization that is `femaleChaired`, with the values of the field being either 'true' or 'false'. The publisher would document the structure of this field and its meaning in the local extension files. -```eval_rst +```{eval-rst} .. jsoninclude:: ../../examples/organization-classification/dhangadhi_female_chaired_example.json :jsonpointer: diff --git a/docs/guidance/map/organization_identifiers.md b/docs/guidance/map/organization_identifiers.md index 23c15c8e3..f2151a64a 100644 --- a/docs/guidance/map/organization_identifiers.md +++ b/docs/guidance/map/organization_identifiers.md @@ -10,7 +10,7 @@ If a publisher chooses not to register an organization list with org-id.guide, t The Government of UK uses identifiers from the UK Companies House to uniquely identify suppliers. The UK Companies House has an entry in [org-id.guide](http://org-id.guide/list/GB-COH), which specifies the "GB-COH" code for the registry. IBM has been assigned the company number ‘04336774’ by the Companies House. The globally unique organization identifier for IBM can then be expressed as in the `identifier` section in the sample below: -```eval_rst +```{eval-rst} .. jsoninclude:: ../../examples/organization-identifiers.json :jsonpointer: /releases/0/parties/1 :expand: identifier, additionalIdentifiers diff --git a/docs/guidance/map/organization_personal_identifiers.md b/docs/guidance/map/organization_personal_identifiers.md index 9eb8215d3..d4a8281b6 100644 --- a/docs/guidance/map/organization_personal_identifiers.md +++ b/docs/guidance/map/organization_personal_identifiers.md @@ -28,7 +28,7 @@ In the example below: * `.identifier.scheme` is constructed from the ISO 3166-1 alpha-3 country code for Colombia ('COL') and the type of the identifier ('IDCARD') -```eval_rst +```{eval-rst} .. jsoninclude:: ../../examples/organization-personal-identifier.json :jsonpointer: :expand: releases, parties, identifier diff --git a/docs/guidance/map/organization_reference.md b/docs/guidance/map/organization_reference.md index 234fbcb70..5b0bee3f9 100644 --- a/docs/guidance/map/organization_reference.md +++ b/docs/guidance/map/organization_reference.md @@ -16,7 +16,7 @@ In the example below: * The same needs to be applied to each `OrganizationReference` instance. -```eval_rst +```{eval-rst} .. jsoninclude:: ../../examples/organization_reference.json :jsonpointer: diff --git a/docs/guidance/map/organizational_units.md b/docs/guidance/map/organizational_units.md index a80ca3202..b136cb8b4 100644 --- a/docs/guidance/map/organizational_units.md +++ b/docs/guidance/map/organizational_units.md @@ -25,7 +25,7 @@ In the release below, the publisher adds the hospital name at the end of the pro An identifier for the hospital has been added using the "HN-ONCAE-UNIT" list code. The `address` and `contactPoint` information belongs to the hospital only. -```eval_rst +```{eval-rst} .. jsoninclude:: ../../examples/organizational-units/honduras-planning.json :jsonpointer: @@ -40,7 +40,7 @@ In Moldova, the national procurement agency needs to include a division code for In the release below, a branch of the Bank of Moldova announces a contract opportunity for the provision of consumables for electrical appliances. -```eval_rst +```{eval-rst} .. jsoninclude:: ../../examples/organizational-units/moldova-tender.json :jsonpointer: @@ -49,7 +49,7 @@ In the release below, a branch of the Bank of Moldova announces a contract oppor ``` -```eval_rst +```{eval-rst} .. jsoninclude:: ../../examples/organizational-units/ocds_divisionCode_extension/extension.json :jsonpointer: @@ -58,7 +58,7 @@ In the release below, a branch of the Bank of Moldova announces a contract oppor ``` -```eval_rst +```{eval-rst} .. jsoninclude:: ../../examples/organizational-units/ocds_divisionCode_extension/release-schema.json :jsonpointer: @@ -79,7 +79,7 @@ It is important to note that OCDS ought to not be used to publish organizational The release below shows how the publisher chooses to model the hospital as an organizational unit of the Medical School (*Facultad de Ciencias Médicas*). The source systems collect the name of the organizational unit only, and this is appended to the organization name. -```eval_rst +```{eval-rst} .. jsoninclude:: ../../examples/organizational-units/paraguay-planning.json :jsonpointer: @@ -90,7 +90,7 @@ The release below shows how the publisher chooses to model the hospital as an or In a separate dataset, the publisher discloses the organizational hierarchy. This dataset, in combination with the OCDS publication, would allow users to summarize contracting information. The table below shows an extract of the dataset. -```eval_rst +```{eval-rst} .. csv-table-no-translate:: :file: ../../examples/organizational-units/paraguay-organizations.csv diff --git a/docs/guidance/map/pre-qualification.md b/docs/guidance/map/pre-qualification.md index 927182ffb..554da498c 100644 --- a/docs/guidance/map/pre-qualification.md +++ b/docs/guidance/map/pre-qualification.md @@ -4,7 +4,7 @@ In single-stage procedures, procuring entities invite suppliers to bid without s But, many jurisdictions also use multi-stage procedures. Such procedures follow a process like: -```eval_rst +```{eval-rst} .. csv-table:: :file: ../../examples/pre-qualification/multi-stage.csv :widths: 50,50 @@ -27,7 +27,7 @@ The model law obliges procuring entities to publish an invitation to pre-qualify The procuring entity assesses the qualifications of the suppliers based on their responses. Only pre-qualified suppliers can take part in the later proceedings. -```eval_rst +```{eval-rst} .. note:: .. markdown:: @@ -43,7 +43,7 @@ The UNCITRAL model law defines pre-selection as a procedure to: Pre-selection follows the same process as pre-qualification, with some additional requirements. The invitation to pre-qualify needs to specify how many suppliers the procuring entity will later request proposals from. The invitation also needs to specify how the procuring entity will select the suppliers to request proposals from. -```eval_rst +```{eval-rst} .. note:: .. markdown:: @@ -112,7 +112,7 @@ In OCDS, a contracting process has a single competitive stage, the `tender` sect The `tender` section is also used to disclose information about the procedure used by the contracting process. In particular, the `tender.procurementMethod` field classifies the procedure using the following codelist: -```eval_rst +```{eval-rst} .. csv-table-no-translate:: :header-rows: 1 :file: ../../../build/current_lang/codelists/method.csv @@ -124,7 +124,7 @@ The Bank of England issues a [restricted procedure contract notice](https://ted. The notice represents the initiation of the contracting process, so it is modelled using the `tender` section in OCDS: -```eval_rst +```{eval-rst} .. jsoninclude:: ../../examples/pre-qualification/pre-qualification-package.json :jsonpointer: /releases/0/tender :title: Tender section @@ -133,7 +133,7 @@ The notice represents the initiation of the contracting process, so it is modell Any supplier can submit a request to take part in the first stage, but only qualified suppliers will be invited to submit a tender for the contract. Therefore, `tender/procurementMethod` is set to ‘selective’. -```eval_rst +```{eval-rst} .. note:: .. markdown :: @@ -151,7 +151,7 @@ The notice represents the initiation of the contracting process, so it is modell The procuring entitiy will invite a maximum of 5 qualified suppliers to submit a tender at the next stage, so `tender/procurementMethod` is set to ‘selective’. The [selectionCriteria extension](https://github.com/open-contracting-extensions/ocds_selectionCriteria_extension) is used to disclose the criteria for choosing which suppliers to invite proposals from. -```eval_rst +```{eval-rst} .. jsoninclude:: ../../examples/pre-qualification/pre-selection-package.json :jsonpointer: /releases/0/tender :title: Tender section @@ -166,14 +166,14 @@ The invitation represents the initiation of a contracting process to establish a Only qualified suppliers will be invited to bid in subsequent tenders that use the list, so `tender.procurementMethod` is set to ‘selective’. -```eval_rst +```{eval-rst} .. jsoninclude:: ../../examples/pre-qualification/pre-qualification-paraguay-package.json :jsonpointer: /releases/0/tender :title: Tender section ``` -```eval_rst +```{eval-rst} .. note:: .. markdown :: diff --git a/docs/guidance/map/purchase_orders.md b/docs/guidance/map/purchase_orders.md index 8d707d997..654e76a74 100644 --- a/docs/guidance/map/purchase_orders.md +++ b/docs/guidance/map/purchase_orders.md @@ -6,7 +6,7 @@ Purchase orders that are made against contracts with a definite quantity or valu The UK's Department for Transport awards a £1.2m, 12-month contract to KPMG to provide the Project Management Office function for a project to construct a new highway bypass. The contract specifies that payment will be made quarterly in arrears in four equal amounts. The contract is represented in the `contracts` section of OCDS as follows: -```eval_rst +```{eval-rst} .. csv-table-no-translate:: :header-rows: 1 :file: ../../examples/purchase_orders/parent_contract.csv @@ -18,7 +18,7 @@ The Department for Transport issues a purchase order on the final day of each qu If purchase orders were also disclosed in the `contracts` section of OCDS, by the end of the contract term, the `contracts` section of OCDS would be populated as follows: -```eval_rst +```{eval-rst} .. csv-table-no-translate:: :header-rows: 1 :file: ../../examples/purchase_orders/contracts_pos.csv @@ -26,7 +26,7 @@ If purchase orders were also disclosed in the `contracts` section of OCDS, by th Calculating the sum of the contract value in the above example gives an incorrect result of £2.4m - double the actual value of the contract. -```eval_rst +```{eval-rst} .. admonition:: Note :class: note diff --git a/docs/guidance/map/unsuccessful_tender.md b/docs/guidance/map/unsuccessful_tender.md index 2056a29be..5ef8f3eb7 100644 --- a/docs/guidance/map/unsuccessful_tender.md +++ b/docs/guidance/map/unsuccessful_tender.md @@ -1,4 +1,4 @@ -## Unsuccessful tenders +# Unsuccessful tenders In the case of procurement, a contracting process can be defined as a procurement procedure. There is a one-to-one correspondence between the first stage of a procurement procedure (tender) and a contracting process. @@ -20,13 +20,13 @@ This relationship can be modelled using the `relatedProcess` array at the releas ![Unsuccessful Tender](../../_static/png/unsuccessful-tender.png) -### Example: Modelling unsuccessful tenders in Paraguay +## Example: Modelling unsuccessful tenders in Paraguay The [Sistema de Información de las Contrataciones Públicas (SICP)](https://contrataciones.gov.py/) discloses information about contracting processes for all public entities in Paraguay. SICP is managed by the National Directorate of Public Procurement (DNCP in Spanish). Paraguay discloses all stages of the contracting process, from planning to implementation. The first data disclosed is about the planning stage. Planning data includes an estimate of what an entity is going to buy, when and for how much. SICP assigns an `ocid` when the planning data is first disclosed, before the tender stage. In this example, the ocid is 'ocds-03ad3f-331547-1'. -```eval_rst +```{eval-rst} .. jsoninclude:: ../../examples/unsuccessful-tender-planning.json :jsonpointer: :expand: releases, planning @@ -36,7 +36,7 @@ Paraguay discloses all stages of the contracting process, from planning to imple Next, the tender data is disclosed, but the tender was unsuccessful, so the tender status is ‘unsuccessful’. -```eval_rst +```{eval-rst} .. jsoninclude:: ../../examples/unsuccessful-tender-tender.json :jsonpointer: :expand: releases, tender, status @@ -54,7 +54,7 @@ Paraguay could also have used the identifier for the second tender as the `ocid` The `relatedProcess` block links the two processes, with the relationship set to ‘unsuccessfulProcess’. -```eval_rst +```{eval-rst} .. jsoninclude:: ../../examples/unsuccessful-tender-related-process.json :jsonpointer: :expand: releases, relatedProcesses, relationship diff --git a/docs/guidance/publish.md b/docs/guidance/publish.md index e714b2753..dafb91ddb 100644 --- a/docs/guidance/publish.md +++ b/docs/guidance/publish.md @@ -35,7 +35,7 @@ When using custom licenses, publishers are encouraged to check that they are [co In structured data file you ought to embed a link to the license in the `license` field of the release or record package as indicated below: -```eval_rst +```{eval-rst} .. code-block:: json :emphasize-lines: 4 diff --git a/docs/history/index.md b/docs/history/index.md index 656544caf..16b32cef1 100644 --- a/docs/history/index.md +++ b/docs/history/index.md @@ -2,7 +2,7 @@ The [Changelog](changelog) describes what's new in each version of OCDS. [Development and Appreciation](history_and_development) describes the development of early versions of OCDS, and thanks all contributors. -```eval_rst +```{eval-rst} .. toctree:: :hidden: diff --git a/docs/index.md b/docs/index.md index 8aefb4525..31e5d326d 100644 --- a/docs/index.md +++ b/docs/index.md @@ -1,19 +1,17 @@ Open Contracting Data Standard: Documentation ============================================= -```eval_rst -.. localization-note:: +```{localization-note} - TRANSLATORS: DO NOT TRANSLATE THIS MESSAGE DIRECTLY +TRANSLATORS: DO NOT TRANSLATE THIS MESSAGE DIRECTLY - Instead if this is a **Community translation** translate the following: +Instead if this is a **Community translation** translate the following: - This is a community translation of OCDS carried out by [ TRANSLATORS ]. + This is a community translation of OCDS carried out by [ TRANSLATORS ]. - This translation was last updated on [ DATE ]. If the source OCDS documentation has changed since this date, some strings in this documentation might not appear translated. - - If this is an officially supported translation (French and Spanish) please translate as a single dash '-'. + This translation was last updated on [ DATE ]. If the source OCDS documentation has changed since this date, some strings in this documentation might not appear translated. +If this is an officially supported translation (French and Spanish) please translate as a single dash '-'. ``` Governments around the world spend an estimated US$9.5 trillion through contracts every year. Yet, contracting information is often unavailable for public scrutiny. @@ -32,12 +30,10 @@ In this documentation, you will find: If you are interested to learn more about Open Contracting advocacy and how it can be used to support wider reform and measurable improvements in public contracting, please visit [www.open-contracting.org](https://www.open-contracting.org/). -```eval_rst -.. note:: - - This is the 1.1 release of OCDS, published on 31st May 2017. Version 1.0 documentation is still available from the version switcher at the bottom left of the page. +```{note} +This is the 1.1 release of OCDS, published on 31st May 2017. Version 1.0 documentation is still available from the version switcher at the bottom left of the page. - This is the English (and canonical) version of the OCDS documentation. You can switch to the Spanish, French, or Italian translations using the language switcher at the bottom left of the page. +This is the English (and canonical) version of the OCDS documentation. You can switch to the Spanish, French, or Italian translations using the language switcher at the bottom left of the page. ``` ## About @@ -50,14 +46,13 @@ Version 1.0 of the standard was developed for the OCP by the [World Wide Web Fou A [free helpdesk service](support/index) is available to support implementation and use of OCDS. -```eval_rst -.. toctree:: - :hidden: +```{toctree} +:hidden: - getting_started/index - guidance/index - schema/index - support/index - history/index - governance/index +getting_started/index +guidance/index +schema/index +support/index +history/index +governance/index ``` diff --git a/docs/privacy-notice.md b/docs/privacy-notice.md index afce00051..8f34fdd65 100644 --- a/docs/privacy-notice.md +++ b/docs/privacy-notice.md @@ -1,5 +1,8 @@ -Privacy Notice --------------- +--- +orphan: true +--- + +# Privacy Notice Open Contracting Partnership is committed to ensuring that your privacy is protected. This privacy notice sets out how we collect and process any personal data when you use this website. @@ -22,7 +25,7 @@ We process personal data for the following purposes: We rely on [legitimate interests](https://ico.org.uk/for-organisations/guide-to-the-general-data-protection-regulation-gdpr/lawful-basis-for-processing/legitimate-interests/) ([GDPR Article 6(1)(f)](https://gdpr-info.eu/art-6-gdpr/)) as the lawful basis for this processing. Details about the type of data, the purpose of the processing and legitimate interests, and the storage and retention of the data are set out below. -### Understanding website visitor and traffic patterns +## Understanding website visitor and traffic patterns We collect data about your visits to the website, for the purpose of analysing how the website is used, so that we can improve it. We use Google Analytics for this. @@ -42,7 +45,7 @@ Data is transferred to Google Analytics, who may transfer data to third countrie The data is kept indefinitely, in pseudonymised form. -### Understanding server behaviour +## Understanding server behaviour We collect data about your visits to the website in server logs. This is for the purpose of debugging network issues, monitoring server usage, and identifying malicious usage. diff --git a/docs/schema/codelists.md b/docs/schema/codelists.md index b34eb9e51..ab1f340c7 100644 --- a/docs/schema/codelists.md +++ b/docs/schema/codelists.md @@ -6,7 +6,7 @@ Codelists can either be open or closed. **Closed codelists** are intended to be Publishers must use the codes in the codelists, unless no code is appropriate. If no code is appropriate and the codelist is **open**, then a publisher may use a new code outside those in the codelist. If no code is appropriate and the codelist is **closed**, then a publisher is encouraged to create an issue in the [OCDS GitHub repository](https://github.com/open-contracting/standard/issues) about adding a new code. -```eval_rst +```{eval-rst} .. admonition:: Extending open codelists :class: note @@ -15,7 +15,7 @@ Publishers must use the codes in the codelists, unless no code is appropriate. I If you use new codes outside those in an open codelist, please document the codes in an [OCDS extension](../guidance/map/extensions) and in your [publication policy](../../guidance/publish/#finalize-your-publication-policy). Please also create an issue in the [OCDS GitHub repository](https://github.com/open-contracting/standard/issues), so that the codes can be considered for inclusion in the codelist. ``` -The release schema, in [JSON Schema](../../release-schema.json), has a `codelist` property to indicate the [CSV file](../../codelists/) that defines the codes in the codelist (shown as tables below). It also has an `openCodelist` property, to indicate whether the codelist is open or closed. +The release schema, in {download}`JSON Schema <../../schema/release-schema.json>`, has a `codelist` property to indicate the CSV File) that defines the codes in the codelist (shown as tables below). It also has an `openCodelist` property, to indicate whether the codelist is open or closed. Codes are case-sensitive, and are generally provided as English language camelCase. Codes must not be translated, though the OCDS team will work with publishers to translate code titles and definitions. @@ -25,7 +25,7 @@ Codes are case-sensitive, and are generally provided as English language camelCa The organizations, economic operators or other participants in a contracting process are listed in the [parties section](../reference/#parties). A single party can have one or more roles in the contracting process. -```eval_rst +```{eval-rst} .. codelisttable:: :header-rows: 1 :file: ../../build/current_lang/codelists/partyRole.csv @@ -37,7 +37,7 @@ Items should be classified using existing item classification schemes, such as t The `itemClassificationScheme` codelist is referenced by the `scheme` field of the `Classification` object, which can be used in multiple contexts. You can find the codes relevant to a given context by filtering the codelist by its `Category` column. -```eval_rst +```{eval-rst} .. codelisttable:: :header-rows: 1 :file: ../../build/current_lang/codelists/itemClassificationScheme.csv @@ -47,7 +47,7 @@ The `itemClassificationScheme` codelist is referenced by the `scheme` field of t Item quantities can be provided using an established codelist for units of measurement. Codelists might provide human-readable descriptions of units, or symbols for use in input and display interfaces. -```eval_rst +```{eval-rst} .. codelisttable:: :header-rows: 1 :file: ../../build/current_lang/codelists/unitClassificationScheme.csv @@ -66,7 +66,7 @@ The Organization Identifier Scheme uses the codes from [org-id.guide](http://www To add new codes to the codelist, contact the [OCDS Helpdesk](../../support/index). -```eval_rst +```{eval-rst} .. note:: This list was formerly maintained by the International Aid Transparency Initiative and contained in OCDS documentation as organizationIdentifierRegistrationAgency_iati.csv. This was removed in OCDS 1.1.1. @@ -80,7 +80,7 @@ The code descriptions are necessarily broad, to cover their usage in a range of Publishers must map their existing document codes to this list, where possible. If using this list within a user interface, publishers can re-write the codelist titles and descriptions appropriately for the context they are being used in. -```eval_rst +```{eval-rst} .. codelisttable:: :header-rows: 1 :widths: 10 10 10 20 50 @@ -91,14 +91,14 @@ Publishers must map their existing document codes to this list, where possible. The award criteria codelist describes the basis on which contract awards will be made. -```eval_rst +```{eval-rst} .. note:: This codelist was revised in OCDS 1.1, deprecating earlier codes and introducing a new set of codelist entries. Publishers ought to review the mapping from their internal systems to this updated list of award criteria. ``` -```eval_rst +```{eval-rst} .. codelisttable:: :header-rows: 1 :widths: 20 20 50 10 @@ -109,7 +109,7 @@ The award criteria codelist describes the basis on which contract awards will be The submission method codelist is used to identify the mechanism through which a submission can be made. -```eval_rst +```{eval-rst} .. codelisttable:: :header-rows: 1 :file: ../../build/current_lang/codelists/submissionMethod.csv @@ -119,7 +119,7 @@ The submission method codelist is used to identify the mechanism through which a The related process block is used at the release level to point backwards to prior processes, such as planning or framework establishment, and at the contract level to point onwards to subcontracts or to renewal or replacement processes. The related process codelist determines the kind of relationship that is being described. -```eval_rst +```{eval-rst} .. codelisttable:: :header-rows: 1 :file: ../../build/current_lang/codelists/relatedProcess.csv @@ -129,7 +129,7 @@ The related process block is used at the release level to point backwards to pri The related process scheme describes the kind of identifier used to cross-reference another process. -```eval_rst +```{eval-rst} .. codelisttable:: :header-rows: 1 :file: ../../build/current_lang/codelists/relatedProcessScheme.csv @@ -140,7 +140,7 @@ The related process scheme describes the kind of identifier used to cross-refere The milestone block can be used to represent a wide variety of events in the lifetime of a contracting process. The milestone type codelist is used to indicate the nature of each milestone. -```eval_rst +```{eval-rst} .. codelisttable:: :header-rows: 1 :file: ../../build/current_lang/codelists/milestoneType.csv @@ -150,7 +150,7 @@ The milestone block can be used to represent a wide variety of events in the lif The extended procurement category codelist is used to provide additional detail about the focus of a contracting process. -```eval_rst +```{eval-rst} .. codelisttable:: :header-rows: 1 :file: ../../build/current_lang/codelists/extendedProcurementCategory.csv @@ -163,7 +163,7 @@ The extended procurement category codelist is used to provide additional detail A contracting process can result in a number of releases of information over time. These must be tagged to indicate the stage of the contracting process they relate to. -```eval_rst +```{eval-rst} .. codelisttable:: :header-rows: 1 :file: ../../build/current_lang/codelists/releaseTag.csv @@ -173,7 +173,7 @@ A contracting process can result in a number of releases of information over tim Contracting processes can be formed under a number of different processes. Currently, only 'tender' is supported in this codelist. Future versions of the standard might support other initiation types. The initiation type is used to provide information to consuming applications on the different blocks of data and releases they can expect from a contracting process. -```eval_rst +```{eval-rst} .. codelisttable:: :header-rows: 1 :file: ../../build/current_lang/codelists/initiationType.csv @@ -183,13 +183,13 @@ Contracting processes can be formed under a number of different processes. Curre The `tender.status` field is used to indicate the current status of a tender process. The following options are available: -```eval_rst +```{eval-rst} .. codelisttable:: :header-rows: 1 :file: ../../build/current_lang/codelists/tenderStatus.csv ``` -```eval_rst +```{eval-rst} .. note:: The 'planning' status was introduced in version 1.1. ``` @@ -198,7 +198,7 @@ The `tender.status` field is used to indicate the current status of a tender pro A contracting process aims to fulfill the requirements identified at the planning stage. The procurement method is the procedure used to purchase the relevant works, goods or services. The method codelist draws upon [the definitions of open, selective and limited provided by the WTO Government Procurement Agreement](http://www.wto.org/english/docs_e/legal_e/rev-gpr-94_01_e.htm), and adds an additional 'direct' code for awards without competition. -```eval_rst +```{eval-rst} .. codelisttable:: :header-rows: 1 :file: ../../build/current_lang/codelists/method.csv @@ -210,7 +210,7 @@ Note: The 'direct' code was introduced in Version 1.1. Publishers who completed The procurement category codelist is used to indicate the **primary** focus of a contracting process. Where a contracting process covers more than one of the options below, publishers should use the `additionalProcurementCategories` field with an array of entries from the open [extendedProcurementCategory](#extended-procurement-category) codelist. -```eval_rst +```{eval-rst} .. codelisttable:: :header-rows: 1 :file: ../../build/current_lang/codelists/procurementCategory.csv @@ -220,7 +220,7 @@ The procurement category codelist is used to indicate the **primary** focus of a An award moves through multiple states. Releases over time can update the status of an award. -```eval_rst +```{eval-rst} .. codelisttable:: :header-rows: 1 :file: ../../build/current_lang/codelists/awardStatus.csv @@ -232,7 +232,7 @@ The `awardStatus` field and codelist is used to indicate when a tender did not r Contracts can move through multiple states. Releases over time can update the status of a contract. -```eval_rst +```{eval-rst} .. codelisttable:: :header-rows: 1 :file: ../../build/current_lang/codelists/contractStatus.csv @@ -240,7 +240,7 @@ Contracts can move through multiple states. Releases over time can update the st ### Milestone Status -```eval_rst +```{eval-rst} .. codelisttable:: :header-rows: 1 :file: ../../build/current_lang/codelists/milestoneStatus.csv @@ -250,7 +250,7 @@ Contracts can move through multiple states. Releases over time can update the st The currency for each amount must be specified using the uppercase 3-letter currency code from [ISO4217](http://www.iso.org/iso/home/standards/currency_codes.htm). -```eval_rst +```{eval-rst} .. codelisttable:: :header-rows: 1 :file: ../../build/current_lang/codelists/currency.csv diff --git a/docs/schema/identifiers.md b/docs/schema/identifiers.md index 7268eac09..9d501a2f4 100644 --- a/docs/schema/identifiers.md +++ b/docs/schema/identifiers.md @@ -124,7 +124,7 @@ There are two parts to expressing an **organization identifier** in open contrac The **organization register prefix** for UK Companies House is GB-COH. The organization **Development Initiatives** has been assigned the company number ‘06368740’ by Companies House. The globally unique organization identifier for Development Initiatives can then expressed as follows: -```eval_rst +```{eval-rst} .. code-block:: json { diff --git a/docs/schema/index.md b/docs/schema/index.md index a76fcee8b..14349412d 100644 --- a/docs/schema/index.md +++ b/docs/schema/index.md @@ -10,7 +10,7 @@ The [release schema reference](reference) provides guidance on using each of the OCDS data must follow the I-JSON (Internet JSON) specification in [RFC7493](https://tools.ietf.org/html/rfc7493), according to which JSON text must be encoded using [UTF-8](https://en.wikipedia.org/wiki/UTF-8), and which introduces a number of requirements for numbers, objects and dates. -```eval_rst +```{eval-rst} .. toctree:: :hidden: diff --git a/docs/schema/merging.md b/docs/schema/merging.md index e7193ba51..6256eec84 100644 --- a/docs/schema/merging.md +++ b/docs/schema/merging.md @@ -25,7 +25,7 @@ At each release, the agency also updates the record, which combines all the rele * The compiled release contains all the information about the opportunity and awards, using the same schema as a release. * The versioned release makes it easy to see how the description and total estimated value changed over time. -```eval_rst +```{eval-rst} .. jsoninclude:: ../examples/merging/merge-tender-1.json :jsonpointer: /releases :expand: releases, tag, tender @@ -33,7 +33,7 @@ At each release, the agency also updates the record, which combines all the rele ``` -```eval_rst +```{eval-rst} .. jsoninclude:: ../examples/merging/merge-tender-3.json :jsonpointer: /releases :expand: releases, tag, tender @@ -41,7 +41,7 @@ At each release, the agency also updates the record, which combines all the rele ``` -```eval_rst +```{eval-rst} .. jsoninclude:: ../examples/merging/merge-award-1.json :jsonpointer: /releases :expand: releases, tag, awards @@ -49,7 +49,7 @@ At each release, the agency also updates the record, which combines all the rele ``` -```eval_rst +```{eval-rst} .. jsoninclude:: ../examples/merging/merge-award-2.json :jsonpointer: /releases :expand: releases, tag, awards @@ -57,7 +57,7 @@ At each release, the agency also updates the record, which combines all the rele ``` -```eval_rst +```{eval-rst} .. jsoninclude:: ../examples/merging/merged.json :jsonpointer: :expand: records, compiledRelease, tag, tender, awards @@ -65,7 +65,7 @@ At each release, the agency also updates the record, which combines all the rele ``` -```eval_rst +```{eval-rst} .. jsoninclude:: ../examples/merging/versioned.json :jsonpointer: :expand: records, versionedRelease, tag, tender, awards @@ -88,7 +88,7 @@ In the release schema, `"omitWhenMerged": true` is declared on fields that must If `omitWhenMerged` is set to `false`, ignore it. -```eval_rst +```{eval-rst} .. note:: .. markdown:: @@ -125,7 +125,7 @@ In a **versioned release**, with a few exceptions, a field's value is replaced w For example, in the above worked example, the estimated value was $1,000 in a release published January 1, 2016 and then $2,000 in a release published February 5, 2016. In a versioned release, this is serialized as below: -```eval_rst +```{eval-rst} .. jsoninclude:: ../examples/merging/versioned.json :jsonpointer: /records/0/versionedRelease/tender/value :expand: value, amount @@ -133,7 +133,7 @@ For example, in the above worked example, the estimated value was $1,000 in a re ``` -```eval_rst +```{eval-rst} .. jsoninclude:: ../examples/merging/versioned.json :jsonpointer: :expand: records, versionedRelease @@ -141,7 +141,7 @@ For example, in the above worked example, the estimated value was $1,000 in a re ``` -The structure of the versioned release is described by the [versioned release schema](../../versioned-release-validation-schema.json); note that the `ocid` field's value is not versioned. +The structure of the versioned release is described by the {download}`versioned release schema <../../schema/versioned-release-validation-schema.json>`; note that the `ocid` field's value is not versioned. ### Merge routine @@ -181,7 +181,7 @@ If the **input** array contains anything other than objects, treat the array as ##### Whole list merge -An **input** array must be treated as a literal value if the corresponding field in a [dereferenced copy](../../dereferenced-release-schema.json) of the release schema has `"array"` in its `type` and if any of the following are also true: +An **input** array must be treated as a literal value if the corresponding field in a {download}`dereferenced copy <../../schema/dereferenced-release-schema.json>` of the release schema has `"array"` in its `type` and if any of the following are also true: * The field has `"wholeListMerge": true` * The field sets `items/type`, and has anything other than `"object"` in `items/type` @@ -198,7 +198,7 @@ This case is encountered if the above conditions aren't met. If the array is emp * If there is an object in the array in **output** with the same `id` value as the object in **input**, merge the matching objects in **input** and **output** according to the [merge routine](#merge-routine) *except for the `id` field*, which is not versioned and instead kept as-is * Otherwise, merge an empty JSON object and the object in **input** according to the [merge routine](#merge-routine) *except for the `id` field*, which is not versioned and instead kept as-is, and append the result to the array in **output** -```eval_rst +```{eval-rst} .. note:: .. markdown:: @@ -207,7 +207,7 @@ This case is encountered if the above conditions aren't met. If the array is emp ``` -```eval_rst +```{eval-rst} .. note:: .. markdown:: diff --git a/docs/schema/record_package.md b/docs/schema/record_package.md index d704b0ed1..1a54353fa 100644 --- a/docs/schema/record_package.md +++ b/docs/schema/record_package.md @@ -1,20 +1,20 @@ -## Record Package Schema +# Record Package Schema The record package schema describes the structure of the container for publishing records. The contents of a record are based on the release schema. The package contains important metadata. -A separate, auto-generated [versioned release schema](../../versioned-release-validation-schema.json) is provided for validating versioned releases within records. +A separate, auto-generated {download}`versioned release schema <../../schema/versioned-release-validation-schema.json>` is provided for validating versioned releases within records. For this version of OCDS, the canonical URL for the record package schema is and for the versioned release schema is . Using the canonical URL guarantees that your software, documentation or other resources will always refer to the specific version of the schema with which they were authored and tested. Click on schema elements to expand the tree, or use the '+' icon to expand all elements. Use { } to view the underlying schema for any section. Required fields are indicated in **bold**. [Deprecated fields](../governance/deprecation) and [multilingual fields](../reference/#language) are omitted. -```eval_rst +```{eval-rst} .. admonition:: Browsing the schema :class: note .. markdown:: - This page presents the record package schema in an interactive browser. You can also download the canonical version of the record package schema as [JSON Schema](../../record-package-schema.json), or view it as [tables](records_reference). + This page presents the record package schema in an interactive browser. You can also download the canonical version of the record package schema as {download}`JSON Schema <../../schema/record-package-schema.json>`), or view it as [tables](records_reference). ``` diff --git a/docs/schema/records_reference.md b/docs/schema/records_reference.md index 6212e048c..4d9a6586d 100644 --- a/docs/schema/records_reference.md +++ b/docs/schema/records_reference.md @@ -4,20 +4,20 @@ Whereas there can be multiple releases about a contracting process, there should **Note: If any conflicts are found between this text, and the text within the schema, the schema takes precedence.** -```eval_rst +```{eval-rst} .. admonition:: Browsing the schema :class: note .. markdown:: - This page presents the record package schema as tables. You can also download the canonical version of the record package schema as [JSON Schema](../../record-package-schema.json), or view it in an [interactive browser](record_package). + This page presents the record package schema as tables. You can also download the canonical version of the record package schema as {download}`JSON Schema <../../record-package-schema.json>`, or view it in an [interactive browser](record_package). ``` ## Package metadata Records must be published within a [record package](record_package). The record package provides metadata about the record(s) that it contains. -```eval_rst +```{eval-rst} .. jsonschema:: ../../build/current_lang/record-package-schema.json :include: :collapse: records @@ -34,7 +34,7 @@ The record package metadata has two differences from the release package metadat The following example demonstrates all package metadata and record fields. -```eval_rst +```{eval-rst} .. jsoninclude:: ../examples/merging/versioned.json :jsonpointer: :expand: packages, records @@ -57,7 +57,7 @@ Each release in a record can be provided as either a linked release or an embedd A linked release follows a simple schema: -```eval_rst +```{eval-rst} .. jsonschema:: ../../build/current_lang/record-package-schema.json :pointer: /definitions/record/properties/releases/oneOf/0/items ``` @@ -66,7 +66,7 @@ For each `url` value, it must be possible for a consuming application to retriev The following example demonstrates the use of linked releases. -```eval_rst +```{eval-rst} .. jsoninclude:: ../examples/merging/versioned.json :jsonpointer: /records/0 :expand: releases, tag @@ -83,7 +83,7 @@ An embedded release follows the [release schema](reference). In other words, ins The following example demonstrates the use of embedded releases. -```eval_rst +```{eval-rst} .. jsoninclude:: ../examples/record-embedded-releases.json :jsonpointer: /records/0 :expand: releases,tag @@ -116,7 +116,7 @@ If the versioned release is not provided, third parties can generate it by proce The following example displays a single field's [versioned values](../merging/#versioned-values). This shows that the amount changed between the planning stage and the tender stage, while the currency did not. -```eval_rst +```{eval-rst} .. jsoninclude:: ../examples/merging/versioned.json :jsonpointer: /records/0/versionedRelease/tender/value :expand: amount, releaseTag diff --git a/docs/schema/reference.md b/docs/schema/reference.md index 20501ccd5..88ed6f863 100644 --- a/docs/schema/reference.md +++ b/docs/schema/reference.md @@ -6,13 +6,13 @@ Releases are immutable – presenting information about a particular event in th **Note: If any conflicts are found between this text, and the text within the schema, the schema takes precedence.** -```eval_rst +```{eval-rst} .. admonition:: Browsing the schema :class: note .. markdown:: - This page presents the release schema in tables, with additional information in paragraphs. You can also download the canonical version of the release schema as [JSON Schema](../../release-schema.json), download it as a [CSV spreadsheet](https://toucan.open-contracting.org/mapping-sheet/?source=https://standard.open-contracting.org/1.1/en/release-schema.json), view it in an [interactive browser](release), or access it through the [Field-Level Mapping Template](https://www.open-contracting.org/resources/ocds-field-level-mapping-template/). + This page presents the release schema in tables, with additional information in paragraphs. You can also download the canonical version of the release schema as {download}`JSON Schema <../../schema/release-schema.json>`), download it as a [CSV spreadsheet](https://toucan.open-contracting.org/mapping-sheet/?source=https://standard.open-contracting.org/1.1/en/release-schema.json), view it in an [interactive browser](release), or access it through the [Field-Level Mapping Template](https://www.open-contracting.org/resources/ocds-field-level-mapping-template/). ``` ## Release handling @@ -53,7 +53,7 @@ A contract for ‘Software consultancy services’ is published in a release wit **json** -```eval_rst +```{eval-rst} .. jsoninclude:: ../examples/language.json :jsonpointer: :expand: tender,item @@ -62,7 +62,7 @@ A contract for ‘Software consultancy services’ is published in a release wit **csv** -```eval_rst +```{eval-rst} .. csv-table-no-translate:: :header-rows: 1 :widths: 20 65 15 @@ -90,7 +90,7 @@ For example, a publisher announcing the signing of a contract with a 'contract' Releases must be published within a [release package](release_package). The release package provides metadata about the release(s) that it contains. -```eval_rst +```{eval-rst} .. jsonschema:: ../../build/current_lang/release-package-schema.json :include: :collapse: releases,publisher @@ -105,14 +105,14 @@ See the [publication policy](../../guidance/publish/#finalize-your-publication-p All new information about a contracting process is described within a release. -```eval_rst +```{eval-rst} .. jsonschema:: ../../build/current_lang/release-schema.json :include: :collapse: planning,tender,awards,contracts,parties,buyer,relatedProcesses ``` -```eval_rst +```{eval-rst} .. extensionlist:: The following extensions are available for release :list: release ``` @@ -121,7 +121,7 @@ All new information about a contracting process is described within a release. Each of the parties (organizations or other participants) referenced in a release must be included in the parties section. -```eval_rst +```{eval-rst} .. admonition:: Parties :class: note @@ -135,21 +135,21 @@ Each of the parties (organizations or other participants) referenced in a releas The following details can be provided for each party. -```eval_rst +```{eval-rst} .. jsonschema:: ../../build/current_lang/release-schema.json :pointer: /definitions/Organization :collapse: identifier,additionalIdentifiers,address,contactPoint ``` -```eval_rst +```{eval-rst} .. extensionlist:: The following extensions are available for parties :list: parties ``` Each party has a `details` object. Through extensions, this can be used to provide detailed classification of parties. -```eval_rst +```{eval-rst} .. extensionlist:: The following extensions are available for party details :list: partyDetail ``` @@ -158,30 +158,25 @@ Each party has a `details` object. Through extensions, this can be used to provi The planning section can be used to describe the background to a contracting process. This can include details of the budget from which funds are drawn, or related projects for this contracting process. Background documents such as a needs assessment, feasibility study and project plan can also be included in this section. -```eval_rst +```{eval-rst} .. jsonschema:: ../../build/current_lang/release-schema.json :pointer: /definitions/Planning :collapse: budget,documents,milestones ``` -```eval_rst -.. extensionlist:: The following extensions are available for planning - :list: planning -``` - Apart from documents, the majority of information is held within the budget block. This is designed to allow both machine-readable linkable data about budgets, cross-referencing to data held in other standards such as the [Fiscal Data Package](https://frictionlessdata.io/specs/fiscal-data-package/) or [International Aid Transparency Initiative Standard](http://www.iatistandard.org), and human readable description of the related budgets and projects, supporting users to understand the relationship of the contracting process to existing projects and budgets even where linked data is not available. #### Budget -```eval_rst +```{eval-rst} .. jsonschema:: ../../build/current_lang/release-schema.json :pointer: /definitions/Budget :collapse: amount ``` -```eval_rst +```{eval-rst} .. extensionlist:: The following extensions are available for budget :list: budget ``` @@ -192,14 +187,14 @@ The tender section includes details of the announcement that an organization int It can contain details of a forthcoming process to receive and evaluate proposals to supply these goods and services, and can also be used to record details of a completed tender process, including details of bids received. -```eval_rst +```{eval-rst} .. jsonschema:: ../../build/current_lang/release-schema.json :pointer: /definitions/Tender :collapse: items,tenderPeriod,enquiryPeriod,awardPeriod,contractPeriod,tenderers,documents,milestones,amendment,amendments,minValue,value,procuringEntity ``` -```eval_rst +```{eval-rst} .. extensionlist:: The following extensions are available for the tender section :list: tender ``` @@ -212,14 +207,14 @@ The [Bid statistics and details](https://extensions.open-contracting.org/en/exte The award section is used to announce any awards issued for this tender. There can be multiple awards made. Releases can contain all, or a subset, of these awards. A related award block is required for every contract block, as the award contains information on the suppliers. -```eval_rst +```{eval-rst} .. jsonschema:: ../../build/current_lang/release-schema.json :pointer: /definitions/Award :collapse: items,value,suppliers,contractPeriod,documents,amendment,amendments ``` -```eval_rst +```{eval-rst} .. extensionlist:: The following extensions are available for award :list: award ``` @@ -228,14 +223,14 @@ The award section is used to announce any awards issued for this tender. There c The contract section is used to provide details of contracts that have been entered into. Every contract must have a related award, linked via the `awardID` field. This is because supplier information is contained within the 'award'. The framework contract details below help illustrate the reasons for this. -```eval_rst +```{eval-rst} .. jsonschema:: ../../build/current_lang/release-schema.json :pointer: /definitions/Contract :collapse: period,value,items,documents,implementation,relatedProcesses,milestones,amendment,amendments ``` -```eval_rst +```{eval-rst} .. extensionlist:: The following extensions are available for contracts :list: contract ``` @@ -244,14 +239,14 @@ The contract section is used to provide details of contracts that have been ente Implementation information can be updated over the course of a contract. It belongs nested within the contract it relates to. Implementation blocks include the following elements: -```eval_rst +```{eval-rst} .. jsonschema:: ../../build/current_lang/release-schema.json :pointer: /definitions/Implementation :collapse: transactions,milestones,documents ``` -```eval_rst +```{eval-rst} .. extensionlist:: The following extensions are available for implementation :list: implementation ``` @@ -260,7 +255,7 @@ Information on subcontracts is not currently included in the core OCDS schema, b #### Transaction -```eval_rst +```{eval-rst} .. jsonschema:: ../../build/current_lang/release-schema.json :pointer: /definitions/Transaction :collapse: providerOrganization,receiverOrganization,amount,payer,payee,value @@ -272,7 +267,7 @@ The transaction block is modelled on the [International Aid Transparency Initiat In most circumstances, the `payer` identifier will match that of the `buyer`, and the `payee` identifier will match that of the `supplier`. -```eval_rst +```{eval-rst} .. extensionlist:: The following extensions are available for transactions :list: transaction ``` @@ -295,7 +290,7 @@ A release may amend values from a previous release. Whilst the release & record The amendment array in a tender, award or contract block provides the ability to detail the amendments that have taken place with dates, rationale and free-text descriptions of the change, as well as to point to the releases that contain information from before and after the amendment. -```eval_rst +```{eval-rst} .. jsonschema:: ../../build/current_lang/release-schema.json :pointer: /definitions/Amendment :collapse: changes @@ -317,7 +312,7 @@ The following building blocks are commonly re-used throughout the standard. ### OrganizationReference -```eval_rst +```{eval-rst} .. admonition:: Organizations :class: note @@ -342,7 +337,7 @@ The identifier block provides a way to [identify the legal entities](../identifi If a contracting process represents a contract arranged by the department or branch of a larger organization, the legal entity (usually the registered organization) should be described in the [identifier](#identifier) section, with details of the branch or department given in the name, [address](#address) and [contact point](#contactpoint) as relevant. -```eval_rst +```{eval-rst} .. jsonschema:: ../../build/current_lang/release-schema.json :pointer: /definitions/Identifier :collapse: @@ -351,7 +346,7 @@ If a contracting process represents a contract arranged by the department or bra #### Address -```eval_rst +```{eval-rst} .. jsonschema:: ../../build/current_lang/release-schema.json :pointer: /definitions/Address :collapse: @@ -360,7 +355,7 @@ If a contracting process represents a contract arranged by the department or bra #### ContactPoint -```eval_rst +```{eval-rst} .. jsonschema:: ../../build/current_lang/release-schema.json :pointer: /definitions/ContactPoint :collapse: @@ -370,36 +365,26 @@ If a contracting process represents a contract arranged by the department or bra Documents can be attached at a number of points within the standard: to planning, tenders, awards, contracts and implementation. Each document block can consist of multiple documents, classified using the [documentType](../codelists/#document-type) codelist. -```eval_rst +```{eval-rst} .. jsonschema:: ../../build/current_lang/release-schema.json :pointer: /definitions/Document :collapse: ``` -```eval_rst -.. extensionlist:: The following extensions are available for document - :list: document -``` - ### Period A period has a start date, end date, and/or duration. Start and end dates are represented using date-times. Durations are represented as a number of days. Periods can also include a `maxExtentDate` which indicates the latest possible end date of this period, or the latest date up until which the period could be extended without an amendment. -```eval_rst +```{eval-rst} .. jsonschema:: ../../build/current_lang/release-schema.json :pointer: /definitions/Period :collapse: ``` -```eval_rst -.. extensionlist:: The following extensions are available for period - :list: period -``` - #### Date OCDS makes use of [ISO8601](http://en.wikipedia.org/wiki/ISO_8601) date-times, following [RFC3339 §5.6](http://tools.ietf.org/html/rfc3339#section-5.6). @@ -428,21 +413,21 @@ In the event that a date field is not bound to a specific time at all, publisher The items block is used to list the line-items associated with a tender, award or contract. -```eval_rst +```{eval-rst} .. jsonschema:: ../../build/current_lang/release-schema.json :pointer: /definitions/Item :collapse: classification,additionalClassifications,unit ``` -```eval_rst +```{eval-rst} .. extensionlist:: These are extensions related to Items. :list: item ``` #### Classification -```eval_rst +```{eval-rst} .. jsonschema:: ../../build/current_lang/release-schema.json :pointer: /definitions/Classification :collapse: @@ -456,7 +441,7 @@ If the [Quantities, Units, Dimensions and Data Types Ontologies](http://www.qudt Other unit classification schemes can be used, including those in the [unitClassificationScheme codelist](../codelists/#unit-classification-scheme). -```eval_rst +```{eval-rst} .. jsonschema:: ../../build/current_lang/release-schema.json :pointer: /definitions/Item/properties/unit :collapse: value @@ -467,7 +452,7 @@ Other unit classification schemes can be used, including those in the [unitClass Milestone information can be included in the [planning](#planning), [tender](#tender), [contract](#contract) and [contract implementation](#implementation) blocks. -```eval_rst +```{eval-rst} .. jsonschema:: ../../build/current_lang/release-schema.json :pointer: /definitions/Milestone :collapse: documents @@ -478,7 +463,7 @@ Notes: * The `dateModified` field should be changed whenever the progress towards a milestone is reviewed, and the `status` either updated, or re-confirmed. -```eval_rst +```{eval-rst} .. extensionlist:: The following extensions to milestone are available :list: milestones ``` @@ -487,7 +472,7 @@ Notes: Financial values should be published with a currency attached. -```eval_rst +```{eval-rst} .. jsonschema:: ../../build/current_lang/release-schema.json :pointer: /definitions/Value :collapse: @@ -496,11 +481,6 @@ Financial values should be published with a currency attached. Support for exchange rates, and tax information, can be provided using extensions. -```eval_rst -.. extensionlist:: The following extensions for value are available - :list: value -``` - ### RelatedProcess In OCDS each contracting process can have only one planning and tender stage. There are a number of cases where it is important to know about related planning and tendering processes, including: @@ -512,7 +492,7 @@ In OCDS each contracting process can have only one planning and tender stage. Th In all these cases, the `relatedProcess` block should be used to cross-reference between the relevant open contracting processes using their `ocid`. -```eval_rst +```{eval-rst} .. jsonschema:: ../../build/current_lang/release-schema.json :pointer: /definitions/RelatedProcess :collapse: @@ -539,7 +519,7 @@ The [Location](https://extensions.open-contracting.org/en/extensions/location/v1 The publisher block is used in release and record packages to identify the source of a dataset. -```eval_rst +```{eval-rst} .. jsonschema:: ../../build/current_lang/release-package-schema.json :include: publisher :collapse: diff --git a/docs/schema/release.md b/docs/schema/release.md index 26388ece6..e2bff2e5a 100644 --- a/docs/schema/release.md +++ b/docs/schema/release.md @@ -6,13 +6,13 @@ For this version of OCDS, the canonical URL of the release schema is: `, download it as a [CSV spreadsheet](https://toucan.open-contracting.org/mapping-sheet/?source=https://standard.open-contracting.org/1.1/en/release-schema.json), view it as [tables](reference), or access it through the [Field-Level Mapping Template](https://www.open-contracting.org/resources/ocds-field-level-mapping-template/). ``` diff --git a/docs/schema/release_package.md b/docs/schema/release_package.md index c294641c8..487ab2c73 100644 --- a/docs/schema/release_package.md +++ b/docs/schema/release_package.md @@ -1,4 +1,4 @@ -## Release Package Schema +# Release Package Schema The release package schema describes the structure of the container for publishing releases. The package contains important metadata. @@ -6,13 +6,13 @@ For this version of OCDS, the canonical URL of the release package schema is: `). ``` diff --git a/include/common.mk b/include/common.mk index 0a3dcd008..1aada4a81 100644 --- a/include/common.mk +++ b/include/common.mk @@ -44,7 +44,7 @@ extract_schema: $(POT_DIR) # See http://www.sphinx-doc.org/en/stable/builders.html#sphinx.builders.gettext.MessageCatalogBuilder .PHONY: extract_markdown extract_markdown: current_lang.en - sphinx-build -q -b gettext $(DOCS_DIR) $(POT_DIR) + sphinx-build -nW --keep-going -q -b gettext $(DOCS_DIR) $(POT_DIR) .PHONY: extract extract: extract_codelists extract_schema $(EXTRACT_TARGETS) extract_markdown clean_current_lang @@ -96,11 +96,11 @@ clean_current_lang: # See http://www.sphinx-doc.org/en/stable/builders.html#sphinx.builders.html.DirectoryHTMLBuilder .PHONY: build_source build_source: current_lang.en - sphinx-build -q -b dirhtml $(DOCS_DIR) $(BUILD_DIR)/en + sphinx-build -nW --keep-going -q -b dirhtml $(DOCS_DIR) $(BUILD_DIR)/en # Build the translated documentation. (Same as source, but with a language configuration setting.) $(TRANSLATIONS:.%=build.%): build.%: current_lang.% - sphinx-build -q -b dirhtml $(DOCS_DIR) $(BUILD_DIR)/$* -D language="$*" + sphinx-build -nW --keep-going -q -b dirhtml $(DOCS_DIR) $(BUILD_DIR)/$* -D language="$*" .PHONY: source source: build_source clean_current_lang diff --git a/include/config.mk b/include/config.mk index 0d30904e7..0f20302ef 100644 --- a/include/config.mk +++ b/include/config.mk @@ -1,6 +1,3 @@ -# Compare this file to: -# https://github.com/open-contracting/standard_profile_template/blob/master/include/config.mk - # Edit these variables as appropriate. # The space-separated, period-prefixed translations to build (for easier substitutions). diff --git a/requirements.txt b/requirements.txt index 9895d255d..367bca675 100644 --- a/requirements.txt +++ b/requirements.txt @@ -2,8 +2,6 @@ # Add your own requirements below. --e git+https://github.com/open-contracting/sphinxcontrib-opencontracting.git@2b01a27cdb7b8a2b5e77f18c4792083f2ff5fc22#egg=sphinxcontrib-opencontracting +sphinxcontrib-opencontracting==0.0.1 -e git+https://github.com/OpenDataServices/sphinxcontrib-jsonschema.git@75e4427b0f6f6a23dff9019aeb5d64833aab104a#egg=sphinxcontrib-jsonschema -e git+https://github.com/OpenDataServices/sphinxcontrib-opendataservices.git@fab0ff0167d32ec243d42f272e0e50766299c078#egg=sphinxcontrib-opendataservices - -# utils/fetch_currency_codelist.py diff --git a/schema/codelists/partyRole.csv b/schema/codelists/partyRole.csv index 03ec37fba..5faea3bda 100644 --- a/schema/codelists/partyRole.csv +++ b/schema/codelists/partyRole.csv @@ -1,7 +1,7 @@ Code,Title,Description buyer,Buyer,"A buyer is an entity whose budget will be used to pay for goods, works or services related to a contract." procuringEntity,Procuring entity,"The entity managing the procurement. This can be different from the buyer who pays for, or uses, the items being procured." -supplier,Supplier,"An entity awarded or contracted to provide goods, works or services." +supplier,Supplier,"An entity with which a buyer or a procuring entity decided to conclude a contract." tenderer,Tenderer,All entities who submit a tender. funder,Funder,The funder is an entity providing money or finance for this contracting process. enquirer,Enquirer,A party who has made an enquiry during the enquiry phase of a contracting process. diff --git a/script/diff b/script/diff index 9a9ce5142..e9d4fe5d1 100755 --- a/script/diff +++ b/script/diff @@ -2,14 +2,14 @@ # No -e, because diff fails. set -uo pipefail -curl -sS https://raw.githubusercontent.com/open-contracting/standard_profile_template/master/docs/conf.py | diff -u - docs/conf.py +curl -sS https://raw.githubusercontent.com/open-contracting/standard_profile_template/latest/docs/conf.py | diff -u - docs/conf.py -for f in .github/workflows/ci.yml include/config.mk; do - curl -sS https://raw.githubusercontent.com/open-contracting/standard_profile_template/master/$f | diff -u - $f +for f in .github/workflows/ci.yml .github/workflows/js.yml include/config.mk; do + curl -sS https://raw.githubusercontent.com/open-contracting/standard_profile_template/latest/$f | diff -u - $f done if [ -d util ] || [ -d schema/project-level ]; then - curl -sS https://raw.githubusercontent.com/open-contracting/standard_profile_template/master/.gitignore | diff -u - .gitignore + curl -sS https://raw.githubusercontent.com/open-contracting/standard_profile_template/latest/.gitignore | diff -u - .gitignore else - curl -sS https://raw.githubusercontent.com/open-contracting/standard_profile_template/master/schema/build-profile.py | diff -u - schema/build-profile.py + curl -sS https://raw.githubusercontent.com/open-contracting/standard_profile_template/latest/schema/build-profile.py | diff -u - schema/build-profile.py fi diff --git a/script/update b/script/update index f96078ba3..060c4c6c1 100755 --- a/script/update +++ b/script/update @@ -5,11 +5,11 @@ function main { mkdir -p script include tests for f in Makefile common-requirements.in common-requirements.txt .github/workflows/lint.yml include/common.mk include/prologue.mk include/header.html script/diff script/update tests/conftest.py tests/test_common.py; do - curl -sS -o $f https://raw.githubusercontent.com/open-contracting/standard_profile_template/master/$f + curl -sS -o $f https://raw.githubusercontent.com/open-contracting/standard_profile_template/latest/$f done if [ ! -d schema/project-level ]; then - curl -sS -o .gitignore https://raw.githubusercontent.com/open-contracting/standard_profile_template/master/.gitignore + curl -sS -o .gitignore https://raw.githubusercontent.com/open-contracting/standard_profile_template/latest/.gitignore fi chmod +x script/* diff --git a/util/add_translation_notes.py b/util/add_translation_notes.py index 321cb8f05..bdef231e1 100644 --- a/util/add_translation_notes.py +++ b/util/add_translation_notes.py @@ -22,6 +22,7 @@ localedir = os.path.join(base_dir, 'docs', 'locale') base_url = 'https://standard.open-contracting.org/1.1' supported_translations = ['es', 'fr'] +excluded = ('.doctrees', '_downloads', '_images', '_sources', '_static', 'codelists', 'genindex', 'search') def add_translation_notes(): @@ -31,7 +32,7 @@ def add_translation_notes(): for root, dirs, files in os.walk(build_dir): # Skip Sphinx directories. - for directory in ('.doctrees', '_images', '_sources', '_static', 'codelists', 'genindex', 'search'): + for directory in excluded: if directory in dirs: dirs.remove(directory)