Tidy repository structure: reorganise content and fix typos

ADR/ADR-Guidelines.md

@@ -4,7 +4,7 @@ This document provides a Guidelines and a template for creating Architectural De
 
 ## Template for Architectural Decision Records (ADRs)
 
-Please find the template for creatinsg ADRs in the [ADR-Template.md](./ADR-Template.md) file. This template should be used for all ADRs to ensure consistency and clarity.
+Please find the template for creating ADRs in the [ADR-Template.md](./ADR-Template.md) file. This template should be used for all ADRs to ensure consistency and clarity.
 
 ## Purpose
 
@@ -22,7 +22,7 @@ Create an ADR when making decisions that:
 - **Require justification and analysis** - Trade-offs between options, risk assessments, cost-benefit
 - **Involve trade-offs between alternatives** - For example performance vs. maintainability, cost vs. functionality
 - **Establish important conventions** - Coding standards, deployment processes, monitoring strategies
-- **Address compliance or regulatory requirements** - Adherance to standards like OGC and Data governance, but also security policies and identity managment
+- **Address compliance or regulatory requirements** - Adherence to standards like OGC and Data governance, but also security policies and identity management
 
 ## Writing Guidelines
 
@@ -126,10 +126,10 @@ Before finalizing an ADR, ensure it meets these criteria:
 
 ## Numbering and Filing
 
-- Use sequential numbering: ADR-001-Meaningfull-Title, ADR-002-Another-Meaningfull-Title, etc.
+- Use sequential numbering: ADR-001-Meaningful-Title, ADR-002-Another-Meaningful-Title, etc.
 - Store ADRs in the central **Codex** repository under `/ADR/`
 - Use descriptive filenames: `ADR-001-Git-Branching-Model.md`
-- Use the [ADR index](./ADR/ADR-Index.md) to track all ADRs and their statuses
+- Use the [ADR index](./ADR-Index.md) to track all ADRs and their statuses
 
 ## Review Process
 

Documentation and Training/README.md

@@ -1,5 +1,5 @@
-Documentation
-=============
+Documentation and Training
+==========================
 
 1. Documentation can be generated via any sensible tool that generates static pages (mkdocs, sphinx, etc.)
 2. Documentation should be published to readthedocs, github pages or sites.ecmwf.int

Guidelines/README.md

@@ -0,0 +1,11 @@
+# Guidelines
+
+Development guidelines for ECMWF software projects.
+
+## Contents
+
+- [Pull Request Guidelines](./pull-requests.md) — responsibilities for reviewers and reviewees, and the PR workflow
+- [AI Contributions to Software](./ai_contributions_to_software.md) — policy guidelines for AI-assisted code generation and AI agents
+- [Containerisation](./Containerisation.md) — guidelines for containerising ECMWF software
+- [Observability](./Observability.md) — observability guidelines for ECMWF services
+- [External Contributions](./external-contributions.md) — guidelines for accepting external contributions to ECMWF projects

Legal/ai_contributions_to_software.md → Guidelines/ai_contributions_to_software.md

@@ -35,7 +35,7 @@ At ECMWF, we view AI Code Agents and Large Language Models (LLMs) as powerful pr
 
 ### Working with AI Agents
 
-* **Data Privacy and Prompt Security:** Developers must not paste sensitive ECMWF data, proprietary keys, unreleased model architectures, or sensitive infrastructure details into *public* AI prompts (e.g., consumer ChatGPT) versus approved internal enterprise tools like GitHub Copilot Enterprise. We have guarrantees from our enterprise providers that data is kept secure, but we should still avoid sharing sensitive information in prompts.
+* **Data Privacy and Prompt Security:** Developers must not paste sensitive ECMWF data, proprietary keys, unreleased model architectures, or sensitive infrastructure details into *public* AI prompts (e.g., consumer ChatGPT) versus approved internal enterprise tools like GitHub Copilot Enterprise. We have guarantees from our enterprise providers that data is kept secure, but we should still avoid sharing sensitive information in prompts.
 
 * **Warning on Intellectual Property and Licensing:** Note that AI models can occasionally reproduce snippets of copyrighted code (e.g., strictly GPL-licensed code). Developers should be reasonably confident the generated code does not violate ECMWF's open-source licensing strategy (mostly Apache 2.0).
 

Guidelines/pr_guidelines.md → Guidelines/pull-requests.md

@@ -67,7 +67,7 @@ merge commits such as "WIP" or "Fix Review Comment", commits like this make it
 more difficult in the future to reason about changes. Be aware that this means
 rewriting your PRs history. While history rewriting is strongly discourraged
 for the primary branches, it is explicitly encouraged on your development
-branch to create meaningfull commits.
+branch to create meaningful commits.
 
 ## General Guidelines
 

Languages/README.md

@@ -0,0 +1,9 @@
+# Languages
+
+Language-specific guidelines and tooling for ECMWF software projects.
+
+## Contents
+
+- [C++](./C++/README.md) — coding standards, clang-format and clang-tidy configuration
+- [Python Wheels](./python_wheels.md) — building and using Python wheels with compiled libraries
+- [Versioning](./versioning.md) — versioning guidance for multi-language repositories

Languages/python_wheels.md

@@ -5,7 +5,7 @@ This document describes the existing mechanism for Python Wheels to interface wi
 * Compiled library: e.g. `eckit`, `eccodes`, `mir`, `atlas`, ... code in e.g. C++ with ecbuild-based compilation
 * Python interface library: e.g. `eccodes-python`, `mir-python`, `pyodc`, ... either cffi or cython interface to a Compiled library
 * Python wrapper wheel: a trivial wheel containing only a Compiled library. We currently use `-lib` naming convention. For example, `eckitlib.whl` is a wheel (zip archive) of compiled `eckit`, including `lib64`, `include`, `etc`, ... everything found in install target.
-* Python interface wheel: a regular wheel you can import in python and invoke code from, containing e.g. `eccodes-python` or `pyodc`. Whether its a binary wheel or pure python wheel depends on whether cython or cfii are used. Does not contain the Compiled library itself, but obviously requires it at runtime.
+* Python interface wheel: a regular wheel you can import in python and invoke code from, containing e.g. `eccodes-python` or `pyodc`. Whether its a binary wheel or pure python wheel depends on whether cython or cffi are used. Does not contain the Compiled library itself, but obviously requires it at runtime.
 * Wheelmaker: utility docker image used in local or github actions builds of Python wrapper wheels
 * Findlibs: python library for dynamic discovery of libraries at python import time -- this is the glue that binds together at runtime the Python interface wheel to Compiled libraries (whether via Python wrapper wheel or manually compiled).
 

Languages/versioning.md

@@ -1,3 +1,3 @@
 # TODO
 
-How do we manage multi-language repositories with a single version number>
+How do we manage multi-language repositories with a single version number?

Legal/copyright_and_licensing.md

@@ -23,7 +23,7 @@ Alternatively, you can use the [apache-licence](apache-licence) file provided in
 
 4. Each original source document (code and documentation, but excluding generated files) **must** include a short license header at the top. To facilitate this, please you may use the script provided in the [Available Tooling](#available-tooling) section below.
 
-Each source file shall begin with the following license and liability discalimer:
+Each source file shall begin with the following license and liability disclaimer:
 
 ```
 (C) Copyright <FILE-CREATED-YEAR>- ECMWF and individual contributors.

Legal/open_sourcing_software.md

@@ -9,7 +9,7 @@ When open sourcing an ECMWF software, either as an ECMWF member or as a sub-cont
    - Seek approval for open source:
      - Verify the package is right for ECMWF GitHub page and discuss the suitablility for it to be open.
      - Discuss the scope of the software, what it does and what it does not
-     - Agree the initial access, i.e. start closed and then open or start immedietly open even if incomplete.
+     - Agree the initial access, i.e. start closed and then open or start immediately open even if incomplete.
      - Agree that only once the following check list is complete, will this software be open sourced.
 
 - Contact GitHub space administrator, typically a Team Leader in Development:
@@ -20,7 +20,7 @@ When open sourcing an ECMWF software, either as an ECMWF member or as a sub-cont
 
 - To give access, Maintainers and Contributors need to have a GitHub account. Currently for github.com/ecmwf this is a Github Enterprise account, for which the following applies:
    - Maintainers should be ECMWF staff
-   - External contributions must follow the policy for [External Contributions](../External%20Contributions/README.md)
+   - External contributions must follow the policy for [External Contributions](../Guidelines/external-contributions.md)
    - External contributors will be asked to agree with a contribution license agreement (CLA) on pull request.
 
 - Ensure a `README` file exists in the root directory

README.md

@@ -13,10 +13,14 @@ The Codex is a set of guidelines for development of software and services at ECM
 - [Architectural Decision Records](./ADR)
 - [Repository Structure](./Repository%20Structure)
 - [Project Maturity](./Project%20Maturity)
-- [Containerisation](./Containerisation)
 - [Testing](./Testing)
-- [Observability](./Development%20Practices/Observability.md)
+- [Containerisation](./Guidelines/Containerisation.md)
+- [Observability](./Guidelines/Observability.md)
 - [ECMWF Software EnginE (ESEE)](./ESEE)
-- [External Contributions](./External%20Contributions/)
+- [External Contributions](./Guidelines/external-contributions.md)
 - [Documentation and Training](./Documentation%20and%20Training/)
-- [Contributing to External Projects](./Contributing%20Externally/)
+- [Contributing to External Projects](./Contributing%20Upstream/)
+- [Guidelines](./Guidelines/)
+- [Languages](./Languages/)
+- [Legal](./Legal/)
+- [Software Management Plan](./Software%20Management%20Plan/)

Repository Structure/README.md

@@ -3,7 +3,7 @@
 These are the guidelines for how a software package repository should be structured.
 If creating a new software package repository you should
 [use the cookiecutter template](https://github.com/ecmwf/cookie-cutter) which will create
-respository following the guidelines documented below.
+repository following the guidelines documented below.
 
 - [Repository Structure](#repository-structure)
   - [Readme](#readme)

Sofware Management Plan/README.md → Software Management Plan/README.md

@@ -1,6 +1,6 @@
 # Software Management Plan Guidelines
 
-A sofware management plan (SMP) should be provided for all projects which contribute to the ECMWF software stack.
+A software management plan (SMP) should be provided for all projects which contribute to the ECMWF software stack.
 This is to ensure that contributions are appropriate, visible, follow guidelines and there is a clear roadmap
 for development and ownership.
 
@@ -98,8 +98,8 @@ Optional:
   - If using a repository template, please provide the link here.
 - **Licence**
   - If not the standard [Apache 2.0 licence](../Legal/apache-licence)
-- **Long-term maintenence owner**
-  - If this is not consistent across all repostories
+- **Long-term maintenance owner**
+  - If this is not consistent across all repositories
 
 ## 6. Development and Maintenance Roadmap
 
@@ -142,7 +142,7 @@ Include:
 - **Documentation location**
   - read-the-docs/github-pages/confluence?
 - **Support model**
-  - Who is the point of conact for support
+  - Who is the point of contact for support
   - Where and how is support provided, e.g. github issues and/or jira tickets.
   - SLAs, expected response times
   - What support is and what support is not covered (optional)