fdwg/fdwg-agreements
1
0
Fork 5
Code Issues Pull requests 1 Projects Releases Packages Wiki Activity Actions
No description
10 commits 1 branch 0 tags 68 KiB
  • Shell 97.1%
  • Python 2.9%
Find a file
Exact
bsellier 8a117eb873
 Sign Agreement: barnabe
2026-05-20 10:16:48 -05:00
agreements Initial commit 2026-05-05 17:15:57 -05:00
signatories Sign Agreement: barnabe 2026-05-20 10:16:48 -05:00
delegate_workflow.sh Add helper scripts 2026-05-08 09:19:01 -05:00
README.md We need GPG keys in Forge to validate 2026-05-07 16:03:31 -05:00

README.md

FDWG Authorized Analytics Volunteers

This repository is the authoritative record of volunteers who have executed the Fedora Data Working Group Authorized Analytics Volunteer Agreement ("the Agreement"), and who are therefore recognized as Authorized Analytics Volunteers under GDPR Article 29 for purposes of FDWG analytics work.

Note that the current agreement is in Draft status, pending full review by the Fedora Council. Should they approve the language as-is, this agreement will become binding.

Quick start: How to sign the Agreement

If you have been asked to sign the Agreement to participate in FDWG analytics work, the steps are:

  1. Read the Agreement. The current adopted version is agreements/volunteer-access-agreement-v0.3.1-draft.md. Do not skim. The obligations are real and continue after your involvement ends.

  2. Make sure your GPG key is registered in FAS. This is required. See "Registering a GPG key in FAS" below if you have not done this.

  3. Add the same GPG key to your Forge account. In the future this will be automated, but today it's still manual.

  4. Fork this repository and create a branch.

  5. Add an entry to signatories/signatories-v0.3.1-draft.yaml in the form described in the "Signatory entry format" section below. Make sure all fields are correct — especially agreement_version, agreement_sha256, and attestation.

  6. Commit the change with a GPG-signed commit (git commit -S -m "Sign Agreement: [your FAS username]"). Push to your fork.

  7. Open a pull request against the main branch of this repository. The PR title should be Sign Agreement: [your FAS username].

  8. Wait for the Delegate to review and merge. You will become an Authorized Analytics Volunteer at the moment of merge. Do not begin processing FDWG data before that point. Note that this does not automatically grant any access rights.

Signatory entry format

Each entry in signatories.yaml must have exactly this structure:

- legal_name: "Jane Carolyn Doe"
  fas_username: "jdoe"
  date: "2026-05-04"
  agreement_version: "1.0"
  agreement_sha256: "[sha256 hash of the agreement file you are signing]"
  attestation: |
    I have read the Authorized Analytics Volunteer Agreement
    version 1.0 (sha256 above) and agree to be bound by it.
    The legal name above is mine and is associated with the
    FAS username above.

Notes:

  • legal_name is your real legal name. This is a deliberate departure from Fedora's general pseudonymity-friendly posture; see "Why the legal name requirement" below. If you have a strong reason this is impossible, contact the Delegate before opening the PR.
  • fas_username must match the FAS account you authenticated with to open the PR.
  • date is the date of execution, in ISO 8601 format (YYYY-MM-DD).
  • agreement_version must be the version of the Agreement you read and are signing. It must be the current adopted version (you cannot sign an outdated version).
  • agreement_sha256 is the sha256 hash of the agreement file. Compute it with sha256sum agreements/volunteer-access-agreement-v[VERSION].md. The hash pins your signature to the exact text you read; if the Agreement is later amended, your signature continues to refer to the version you actually agreed to.
  • attestation must be reproduced exactly as shown in the template, with the version number updated to match what you are signing. Do not paraphrase or shorten.

The Delegate will reject pull requests where any of these fields is missing, malformed, or inconsistent with the others.

What the Delegate verifies before merging

The Delegate (currently Michael Winters, FAS username mwinters) verifies, before merging:

  1. The pull request is from an FAS-authenticated account.
  2. The commit is GPG-signed.
  3. The GPG key used to sign the commit is registered in FAS for that account.
  4. The signatory entry is well-formed (matches the schema above).
  5. The agreement_version and agreement_sha256 refer to the current adopted version of the Agreement.
  6. The fas_username in the entry matches the FAS account that opened the PR.
  7. The attestation language is reproduced exactly.

If any check fails, the PR is closed with a comment explaining why. The volunteer is welcome to fix issues and re-open.

The Delegate does not exercise discretion beyond these checks. Admissions are mechanical: if the checks pass, the PR is merged; if they fail, it is rejected.

Registering a GPG key in FAS

This is a precondition for signing. The process:

  1. If you do not have a GPG key, generate one. See the Github docs for guidance on key generation appropriate for code-signing use.
  2. Export your public key: gpg --armor --export [your-key-id].
  3. Log in to FAS at https://accounts.fedoraproject.org/ and add the key to your account profile.
  4. Configure git to sign commits with that key: git config --global user.signingkey [your-key-id] and git config --global commit.gpgsign true.
  5. Verify by making a test commit and checking git log --show-signature.

If you already have a GPG key registered in FAS for other purposes (package signing, etc.), you may use the same key.

Why the legal name requirement

Fedora generally permits pseudonymous participation. This Agreement is one of the few places where it does not, and the reason is specific: the Agreement creates personal commitments that survive the volunteer's involvement (confidentiality continues indefinitely, §4.4). For obligations of that character to be meaningful, the controller — Red Hat, acting through the Council — needs to be able to identify the human on the other side, not just an account.

A few notes on how this is implemented:

  • The legal name is recorded in signatories.yaml, which is part of the public history of this repository. If you have a serious reason your legal name should not be in a public Fedora record (personal safety, professional separation, etc.), contact the Delegate before opening a PR. The Council has authorized the Delegate to record legal names in a non-public manner in such cases, with the public file showing FAS username only. This is an exception, not the default; the default is that the legal name is public.
  • The legal-name assertion is on your good faith. There is no notarization or external verification step. The point is that you have affirmed it, not that anyone has checked it.
  • The legal-name requirement applies for purposes of this Agreement only. It does not change your status under any other Fedora policy, the FPCA, or general Fedora participation norms.

Amendments to the Agreement

The Agreement may be amended only by Council resolution (see Council resolution §4). When an amendment is adopted:

  • The new version is added to this repository as agreement/v[NEW_VERSION].md. Old versions are retained, not deleted.
  • Current signatories are notified by the Delegate.
  • Each current signatory must execute the new version within the period specified in the amending resolution, by adding a new entry to signatories.yaml referencing the new version and hash.
  • Signatories who do not re-execute by the deadline are deemed to have terminated their Agreement under §11 and lose their Authorized Analytics Volunteer status.
  • Historical entries referencing prior versions are preserved unchanged. Each entry is a record of what was agreed to at the time it was made.

The hash-pinning in each entry is what makes this work: your past signature is permanently bound to the text of the version you actually read. Future versions are separate signatures requiring separate consent.

Termination

You may terminate your participation at any time. Two options:

  1. Pull request: Open a PR that adds a terminated_date field to your entry in signatories.yaml. The Delegate will merge it. Effective on merge.
  2. Direct notice: Email the Delegate at fedora@mwinters.net. The Delegate will record the termination in the repository.

The Council, through the Delegate, may also terminate any volunteer's Agreement on behalf of the controller. This is rare and would normally follow specific cause (incident, breach of obligations, etc.).

Note that the obligations in §4 (confidentiality) and §10 (incident reporting for incidents arising from data accessed during the term) survive termination.

What this repository is not

  • It is not a record of access. Being an Authorized Analytics Volunteer is a precondition for FDWG access, not the access itself. Access is granted through FDWG's own processes after admission.
  • It is not a place to ask questions about the Agreement. Use the FDWG Matrix Room data or contact the Delegate directly.
  • It is not the right place to contest or appeal a decision by the Delegate. Concerns should be raised with the Council through normal channels.

Repository integrity

This repository is hosted on Fedora-controlled infrastructure at https://forge.fedoraproject.org/commops/fdwg-agreements. Branch protection is enabled on main:

  • No force-pushes.
  • No history rewriting.
  • All merges via PR.
  • Required GPG-signed commits.
  • Merges only by the Delegate or other Council-authorized accounts.

The combination of Fedora-controlled hosting and branch protection is what makes this repository a durable record suitable for the controller's GDPR Art. 5(2) and Art. 24 accountability needs.

If you notice any apparent integrity issue with this repository (history rewriting, missing entries, anything that does not look right), please report it to the Delegate immediately under §10 of the Agreement (incident reporting).

Contacts