mwinters commented

Summary

Formally endorse the Authorized Analytics Volunteer Agreement

Background

The Fedora Data Working Group ("FDWG", #data) was formed in 2025 to enable Fedora to understand the health of our community, by building foundational data engineering and data science capabilities. This will allow us to answer fundamental questions such as, "How many contributors did we gain / lose in the past 3 months?" and "Which recruitment efforts have resulted in high retention of volunteers?" Insights such as these are, I believe, critical to objectively achieving Strategy 2028.

Fedora's Privacy Statement declares analysis activities such as these to be "legitimate interests" under GDPR, providing the lawful basis for "research activities, including the production of statistical reports".

Problem #1: Who is Fedora?

While the Fedora Privacy Statement declares the actions that Fedora may take on data, it does not say anything about who may carry out such actions on Fedora's behalf.

This leaves us in a legal grey area regarding volunteer contributions to our analytics efforts. Are contributors acting as agents of Fedora or as independent data processors? (Legally, is "Fedora" analyzing this data, or is "Michael Winters"?) At worst, a lack of this agreement could potentially expose our contributors to personal legal liability for helping us understand our community.

Problem #2: Instructions

Under GDPR Article 29, analysis may only take place according to the the instructions of the data controller ("Fedora", or possibly "Red Hat"). The controller must provide details about what constraints should be applied, and how those persons are bound.

This Solution

The volunteer agreement solves problem number 2 by providing Fedora's instructions to analysts. And by executing a signed agreement between Council and the contributor based on these instructions, we also solve problem number 1. The result is that as long as the analyst follows Council's instructions, it is Fedora who is performing the analysis, and thus it falls within the realm of Fedora's protected "Legitimate Interests".

Details

Request #1

I am asking the Council to review and formally endorse the attached Authorized Analytics Volunteer Agreement.

Note that I wasn't sure of the correct information for Section 14 of the agreement.

Request #2

If the agreement is endorsed, then we need to discuss implementation.

The agreement functions like a contract between Fedora and the contributor. "As long as you follow my instructions, you are acting on my behalf / within my GDPR scope, and the authorizations for analysis which GDPR provides to Fedora are now extended to you."

However, that would require a Council ticket for every new contributor. In order to minimize the operational burden, Council can designate persons as authorized to execute these agreements (collect these signatures from contributors) on Council's behalf.

This delegation would allows someone to act essentially as a Notary. A Delegate's job would be solely to validate that the person is who they say they are (as best as we can ascertain with current processes), and to validate that the signature on the agreement is theirs. The Delegate is not responsible for making any decisions regarding whether access should be granted to data, or to which data, or to what level of privilege, etc. A Delegate's authority and responsibility is exclusively to validate contributor signatures, and to accept those signatures (which is what embodies the act of "instructing" that analyst per GDPR.)

I humbly request that you authorize myself and Justin Wheeler as named delegates within this same "motion" from the Council.

Source / AI Disclosure

The agreement was drafted collaboratively with Claude Opus 4.7, drawing from my professional background in Infosec / Compliance and Claude's review of the Fedora Privacy Policy, our current scope of analytics work, and FDWG's planned implementations of "privacy-by-design".

Extensive notes are available which tie every clause of the Agreement back to GDPR language and EDPB guidelines. To avoid noise, I've left this available upon request. I think the agreement as it stands is in plain enough English for anyone to understand.

# Summary Formally endorse the **Authorized Analytics Volunteer Agreement** ## Background The Fedora Data Working Group ("FDWG", [`#data`](https://matrix.to/#/#data:fedoraproject.org)) was formed in 2025 to enable Fedora to understand the health of our community, by building foundational data engineering and data science capabilities. This will allow us to answer fundamental questions such as, "How many contributors did we gain / lose in the past 3 months?" and "Which recruitment efforts have resulted in high retention of volunteers?" Insights such as these are, I believe, critical to objectively achieving Strategy 2028. [Fedora's Privacy Statement](https://docs.fedoraproject.org/en-US/legal/privacy/) declares analysis activities such as these to be "legitimate interests" under GDPR, providing the lawful basis for "research activities, including the production of statistical reports". ### Problem #1: Who is Fedora? While the Fedora Privacy Statement declares the actions that Fedora may take on data, it does not say anything about *who* may carry out such actions on Fedora's behalf. This leaves us in a legal grey area regarding volunteer contributions to our analytics efforts. Are contributors acting as agents of Fedora or as independent data processors? (Legally, is "Fedora" analyzing this data, or is "Michael Winters"?) At worst, a lack of this agreement could potentially expose our contributors to personal legal liability for helping us understand our community. ### Problem #2: Instructions Under GDPR Article 29, analysis may only take place according to the the instructions of the data controller ("Fedora", or possibly "Red Hat"). The controller must provide details about what constraints should be applied, and how those persons are bound. ## This Solution The volunteer agreement solves problem number 2 by providing Fedora's instructions to analysts. And by executing a signed agreement between Council and the contributor based on these instructions, we also solve problem number 1. The result is that as long as the analyst follows Council's instructions, it is Fedora who is performing the analysis, and thus it falls within the realm of Fedora's protected "Legitimate Interests". # Details ## Request #1 I am asking the Council to review and formally endorse the attached **Authorized Analytics Volunteer Agreement**. Note that I wasn't sure of the correct information for Section 14 of the agreement. ## Request #2 If the agreement is endorsed, then we need to discuss implementation. The agreement functions like a contract between Fedora and the contributor. "As long as you follow my instructions, you are acting on my behalf / within my GDPR scope, and the authorizations for analysis which GDPR provides to Fedora are now extended to you." However, that would require a Council ticket for every new contributor. In order to minimize the operational burden, Council can designate persons as authorized to execute these agreements (collect these signatures from contributors) on Council's behalf. This delegation would allows someone to act essentially as a Notary. A Delegate's job would be solely to validate that the person is who they say they are (as best as we can ascertain with current processes), and to validate that the signature on the agreement is theirs. The Delegate is not responsible for making any decisions regarding whether access should be granted to data, or to which data, or to what level of privilege, etc. A Delegate's authority and responsibility is exclusively to validate contributor signatures, and to accept those signatures (which is what embodies the act of "instructing" that analyst per GDPR.) I humbly request that you authorize myself and Justin Wheeler as named delegates within this same "motion" from the Council. ## Source / AI Disclosure The agreement was drafted collaboratively with Claude Opus 4.7, drawing from my professional background in Infosec / Compliance and Claude's review of the Fedora Privacy Policy, our current scope of analytics work, and FDWG's planned implementations of "privacy-by-design". Extensive notes are available which tie every clause of the Agreement back to GDPR language and [EDPB](https://www.edpb.europa.eu/edpb_en) guidelines. To avoid noise, I've left this available upon request. I think the agreement as it stands is in plain enough English for anyone to understand.

fdwg_volunteer_access_agreement_v0_4_0_draft_broad.md

14 KiB

fdwg_volunteer_access_agreement_v0_4_0_draft_scoped.md

15 KiB

fdwg_volunteer_access_agreement_v0.3.1.md

14 KiB

mwinters added the

needs

triage

label

2026-05-05 20:57:11 +00:00

mwinters commented

2026-05-05 21:30:10 +00:00

Author

For convenience, I'm posting the contents of the agreement v0.3.1 here:

Click to expand

Fedora Data Working Group - Authorized Analytics Volunteer Agreement

Version: 0.3.1 (draft for Council review)

1. Purpose and scope

1.1 The Fedora Project publishes activity data about its contributors (account records, commit history, mailing list and forum posts, group membership changes, and similar records) through its public services. The Fedora Data Working Group ("FDWG") consolidates and correlates this data to produce statistical reports on community health — understanding which efforts successfully recruit and retain contributors, and which work areas need support.

1.2 This processing is conducted under the legitimate interests of the Fedora Project as declared in the Fedora Privacy Statement, specifically the basis stated for "research activities, including the production of statistical reports."

1.3 This agreement governs the relationship between the Fedora Project ("Fedora") and a volunteer ("you", "the Volunteer") who is granted access to FDWG analytics data. By signing this agreement, you become an Authorized Analytics Volunteer: a natural person acting under the authority of the controller within the meaning of Article 29 of the General Data Protection Regulation (Regulation (EU) 2016/679).

1.4 Where an obligation in this agreement refers to data, infrastructure, or actions you do not in fact have access to or perform, the obligation is satisfied trivially with respect to those things. The agreement is written to cover the full range of FDWG analytics work; not every clause will apply to every volunteer's day-to-day activities.

2. The FDWG data layering model

2.1 FDWG operates a privacy-by-design data layering model as a measure under GDPR Art. 25. Three categories of dataset are recognized:

(a) Raw data. Contributor activity data as ingested from Fedora's source systems. Contains direct identifiers (usernames, email addresses, etc.) and is treated as personal data under GDPR.

(b) Pseudonymized data. Data derived from the raw data in which direct identifiers have been replaced with opaque GUIDs through a key (the "pseudonymization mapping") held only on FDWG-designated infrastructure. Pseudonymized data remains personal data under GDPR (Art. 4(5)) but is materially less identifying.

(c) Aggregate outputs. Statistical outputs (counts, distributions, time series, reports) computed from pseudonymized data, presented at a level of aggregation that does not identify any individual contributor. Aggregate outputs are intended for publication and sharing outside FDWG.

2.2 Access to each tier is controlled by FDWG infrastructure separately. Your access at any given time is whatever you have been granted; this agreement does not itself grant access. Where this agreement imposes obligations relating to a particular tier, those obligations apply to you to the extent you have access to that tier.

3. Purpose limitation

3.1 You may process FDWG data only for the purposes set out in §1.1: the production of statistical aggregate outputs about Fedora community health, and the production and maintenance of the datasets and supporting infrastructure that enable such outputs.

3.2 You will not use access granted under this agreement for any of the following:

(a) Producing outputs that identify, profile, or single out individual contributors, except where the individual is the data subject themselves and they have requested information about their own data through a documented process.

(b) Marketing, recruiting, evaluating, ranking, or making decisions about individual contributors.

(c) Research published outside Fedora's analytics outputs (academic papers, third-party publications, personal blog posts containing non-aggregate data, etc.) without prior written authorization from the Council or its delegate.

(d) Any purpose unrelated to the statistical aggregate outputs described in §1.1.

3.3 You may choose your own methods, tools, and analytical questions within the purposes set out above. Method-level autonomy is expected; purpose-level discipline is required.

4. Confidentiality

4.1 You will treat FDWG data as confidential. The fact that the constituent source datasets are individually published by Fedora does not make the correlated form non-confidential: correlation across systems creates a more identifying data set than any individual public source, and that combined view is not itself public. Pseudonymized data, although it does not contain direct identifiers, remains personal data and is similarly confidential — combinations of fields within it may be identifying, particularly within small sub-communities.

4.2 The pseudonymization mapping (the key linking GUIDs to direct identifiers) is the single most sensitive artifact in FDWG. It resides only on FDWG-designated infrastructure and may not be exported, copied, transmitted, or made available to any person or system outside that infrastructure under any circumstances. The protective value of pseudonymization depends on this isolation.

4.3 You will not disclose, share, transmit, or make available FDWG data to any person who has not signed this agreement, except as required by law or with the prior written authorization of the Council or its delegate.

4.4 The confidentiality obligations in this section continue after your work with FDWG ends.

5. Prohibition on re-identification

5.1 You will not attempt to re-identify any individual contributor in pseudonymized data, whether by correlating GUIDs against external information, by inferring identity from combinations of fields, or by any other means.

5.2 Aggregate outputs published outside FDWG must not identify or enable identification of individual contributors. You will apply, at minimum, the following published-output rules:

(a) Cell suppression. Aggregates with fewer than five distinct contributors will be suppressed or grouped, unless an exception is documented and approved.

(b) Small-community awareness. For SIGs, working groups, or sub-projects with small membership, aggregates may identify individuals even above the §5.2(a) threshold. You will exercise additional judgment in these cases and prefer suppression where in doubt.

5.3 Where a contributor has opted out of public display of a particular FAS field (per the Fedora Privacy Statement, "Publicly Available Personal Data" section), no FDWG output — aggregate or otherwise — will re-expose that field, whether directly or by inference. Opt-out state must be reflected in pseudonymized datasets at the point they are produced.

6. No contact, no targeting

6.1 You will not use access granted under this agreement to contact any contributor, whether the contact is for analytics-related purposes or otherwise. The Fedora Privacy Statement is explicit that aggregated information from research activities "is not used to contact the subjects of the report"; this prohibition extends to all FDWG data.

6.2 You will not use access granted under this agreement to target, profile, or intervene with respect to any individual contributor — including for purposes that might otherwise be welcome (e.g., "reaching out to lapsing contributors"). Such interventions, if they are to occur at all, are decisions for Fedora's leadership through its own channels and on its own lawful basis, not consequences of analytics access.

7. No redistribution of FDWG data

7.1 You will not extract, copy, publish, or redistribute FDWG data outside FDWG infrastructure and authorized local copies under §9, except in the form of aggregate outputs satisfying §5.2.

7.2 Re-publication of individual public datasets in their original form, from their original sources, is not restricted by this agreement. The restriction is on FDWG-internal data products: correlated raw data, the pseudonymization mapping, and pseudonymized datasets.

8. Respect for opt-outs and erasure requests

8.1 You will respect FAS account opt-outs as reflected in the data made available to you. Where opt-out information is propagated through FDWG infrastructure, you will use the most current data available at the time of analysis.

8.2 Where you receive notice (through FDWG channels) that a data subject has exercised a right of erasure, restriction, or objection under the Fedora Privacy Statement:

(a) FDWG will update the pseudonymization mapping and pseudonymized datasets to reflect the request, within fourteen (14) days of notice. Depending on the nature of the request, this may include removal of the individual's records, severing of the GUID-to-identifier link, or restriction of further processing.

(b) On notice that a GUID has been withdrawn or restricted, you will cease processing records associated with that GUID in any new analyses, and delete or render inaccessible any local copies under §9 containing those records, within fourteen (14) days of notice.

(c) Where prior published aggregate outputs were derived in part from the affected individual's data, no recomputation or alteration is required — historical statistical aggregates do not constitute personal data of any single individual, and the Privacy Statement explicitly preserves the historical record of contributor activity.

9. Local copy handling

9.1 Where your analysis requires local copies of FDWG data on your own systems:

(a) Local copies must be stored on devices under your direct control, with reasonable access protections (full-disk encryption, account password, screen lock).

(b) Local copies must not be stored on shared or third-party systems (cloud notebooks, shared drives, AI/LLM service contexts, public code repositories) unless the service is explicitly approved by FDWG for this use.

(c) Local copies must be deleted when no longer needed for the analysis at hand, and at the latest when your participation in FDWG ends.

9.2 Raw data and the pseudonymization mapping carry additional restrictions:

(a) Raw data should be processed on FDWG infrastructure where possible. Local copies of raw data are permitted only where required for specific tasks (e.g., debugging an ingestion pipeline) and must be deleted promptly on completion.

(b) The pseudonymization mapping must not be held in local copies on personal systems under any circumstances. It resides only on FDWG-designated infrastructure.

9.3 You will not commit FDWG data to source control, public or private, even briefly. Code that processes such data is fine; the data itself is not.

10. Incident reporting

10.1 You will notify FDWG leadership without undue delay, and in any event within seventy-two (72) hours, on becoming aware of:

(a) Any unauthorized access to, or disclosure of, FDWG data in your possession or under your control;

(b) Any loss of a device containing local copies under §9;

(c) Any published aggregate output that, on reflection, you believe may identify or enable identification of individual contributors contrary to §5.2;

(d) Any apparent re-identification of an individual in pseudonymized data, whether achieved deliberately or noticed inadvertently;

(e) Any compromise, suspected compromise, or disclosure of the pseudonymization mapping;

(f) Any contact, attempted or actual, with you from a third party seeking access to FDWG data.

10.2 The seventy-two-hour figure is borrowed from GDPR Art. 33's controller-to-supervisory-authority timeline; it gives the controller enough margin to meet its own obligations if escalation is required. It is not itself a regulatory deadline binding on you, and good-faith promptness is what matters.

11. Term and termination

11.1 This agreement takes effect when both parties sign and continues until terminated.

11.2 Either party may terminate this agreement at any time, by notice to the other. On termination:

(a) Your access to FDWG infrastructure will be revoked;

(b) The local-copy obligations in §9.1(c) become immediate;

(c) The confidentiality obligations in §4 continue indefinitely;

(d) The incident-reporting obligation in §10 continues for any incidents arising from data accessed during the term.

12. No employment, no compensation, no warranty

12.1 Nothing in this agreement creates an employment, agency, or contractor relationship between you and Fedora or Red Hat. Your participation is voluntary and uncompensated.

12.2 Fedora makes no warranty as to the accuracy, completeness, or fitness for purpose of any data made available under this agreement.

12.3 You participate at your own risk and on your own responsibility, save that nothing in this agreement is intended to limit Fedora's responsibilities as controller under applicable data protection law.

13. Relationship to other agreements

13.1 This agreement is independent of and additional to the Fedora Project Contributor Agreement (FPCA). The FPCA addresses intellectual property in your contributions; this agreement addresses your access to and processing of personal data on Fedora's behalf.

13.2 In the event of conflict between this agreement and the Fedora Privacy Statement as it applies to the controller, the Privacy Statement governs the controller's obligations to data subjects. This agreement governs your obligations to the controller.

14. Governing law

14.1 [To be completed on adoption — likely the law of the State of North Carolina, USA, consistent with Red Hat's corporate seat, with the understanding that the substantive obligations herein are designed to satisfy EU/UK GDPR requirements applicable to the controller.]

15. Amendments

15.1 This agreement may be amended by the Council. Material amendments will be communicated to current Authorized Analytics Volunteers, who may either accept the amended terms or terminate under §11.

For convenience, I'm posting the contents of the agreement v0.3.1 here: <details> <summary>Click to expand</summary> # Fedora Data Working Group - Authorized Analytics Volunteer Agreement **Version:** 0.3.1 (draft for Council review) --- ## 1. Purpose and scope 1.1 The Fedora Project publishes activity data about its contributors (account records, commit history, mailing list and forum posts, group membership changes, and similar records) through its public services. The Fedora Data Working Group ("FDWG") consolidates and correlates this data to produce statistical reports on community health — understanding which efforts successfully recruit and retain contributors, and which work areas need support. 1.2 This processing is conducted under the legitimate interests of the Fedora Project as declared in the Fedora Privacy Statement, specifically the basis stated for "research activities, including the production of statistical reports." 1.3 This agreement governs the relationship between the Fedora Project ("Fedora") and a volunteer ("you", "the Volunteer") who is granted access to FDWG analytics data. By signing this agreement, you become an *Authorized Analytics Volunteer*: a natural person acting under the authority of the controller within the meaning of Article 29 of the General Data Protection Regulation (Regulation (EU) 2016/679). 1.4 Where an obligation in this agreement refers to data, infrastructure, or actions you do not in fact have access to or perform, the obligation is satisfied trivially with respect to those things. The agreement is written to cover the full range of FDWG analytics work; not every clause will apply to every volunteer's day-to-day activities. ## 2. The FDWG data layering model 2.1 FDWG operates a privacy-by-design data layering model as a measure under GDPR Art. 25. Three categories of dataset are recognized: (a) **Raw data.** Contributor activity data as ingested from Fedora's source systems. Contains direct identifiers (usernames, email addresses, etc.) and is treated as personal data under GDPR. (b) **Pseudonymized data.** Data derived from the raw data in which direct identifiers have been replaced with opaque GUIDs through a key (the "pseudonymization mapping") held only on FDWG-designated infrastructure. Pseudonymized data remains personal data under GDPR (Art. 4(5)) but is materially less identifying. (c) **Aggregate outputs.** Statistical outputs (counts, distributions, time series, reports) computed from pseudonymized data, presented at a level of aggregation that does not identify any individual contributor. Aggregate outputs are intended for publication and sharing outside FDWG. 2.2 Access to each tier is controlled by FDWG infrastructure separately. Your access at any given time is whatever you have been granted; this agreement does not itself grant access. Where this agreement imposes obligations relating to a particular tier, those obligations apply to you to the extent you have access to that tier. ## 3. Purpose limitation 3.1 You may process FDWG data only for the purposes set out in §1.1: the production of statistical aggregate outputs about Fedora community health, and the production and maintenance of the datasets and supporting infrastructure that enable such outputs. 3.2 You will not use access granted under this agreement for any of the following: (a) Producing outputs that identify, profile, or single out individual contributors, except where the individual is the data subject themselves and they have requested information about their own data through a documented process. (b) Marketing, recruiting, evaluating, ranking, or making decisions about individual contributors. (c) Research published outside Fedora's analytics outputs (academic papers, third-party publications, personal blog posts containing non-aggregate data, etc.) without prior written authorization from the Council or its delegate. (d) Any purpose unrelated to the statistical aggregate outputs described in §1.1. 3.3 You may choose your own methods, tools, and analytical questions within the purposes set out above. Method-level autonomy is expected; purpose-level discipline is required. ## 4. Confidentiality 4.1 You will treat FDWG data as confidential. The fact that the constituent source datasets are individually published by Fedora does not make the *correlated* form non-confidential: correlation across systems creates a more identifying data set than any individual public source, and that combined view is not itself public. Pseudonymized data, although it does not contain direct identifiers, remains personal data and is similarly confidential — combinations of fields within it may be identifying, particularly within small sub-communities. 4.2 The pseudonymization mapping (the key linking GUIDs to direct identifiers) is the single most sensitive artifact in FDWG. It resides only on FDWG-designated infrastructure and may not be exported, copied, transmitted, or made available to any person or system outside that infrastructure under any circumstances. The protective value of pseudonymization depends on this isolation. 4.3 You will not disclose, share, transmit, or make available FDWG data to any person who has not signed this agreement, except as required by law or with the prior written authorization of the Council or its delegate. 4.4 The confidentiality obligations in this section continue after your work with FDWG ends. ## 5. Prohibition on re-identification 5.1 You will not attempt to re-identify any individual contributor in pseudonymized data, whether by correlating GUIDs against external information, by inferring identity from combinations of fields, or by any other means. 5.2 Aggregate outputs published outside FDWG must not identify or enable identification of individual contributors. You will apply, at minimum, the following published-output rules: (a) **Cell suppression.** Aggregates with fewer than five distinct contributors will be suppressed or grouped, unless an exception is documented and approved. (b) **Small-community awareness.** For SIGs, working groups, or sub-projects with small membership, aggregates may identify individuals even above the §5.2(a) threshold. You will exercise additional judgment in these cases and prefer suppression where in doubt. 5.3 Where a contributor has opted out of public display of a particular FAS field (per the Fedora Privacy Statement, "Publicly Available Personal Data" section), no FDWG output — aggregate or otherwise — will re-expose that field, whether directly or by inference. Opt-out state must be reflected in pseudonymized datasets at the point they are produced. ## 6. No contact, no targeting 6.1 You will not use access granted under this agreement to contact any contributor, whether the contact is for analytics-related purposes or otherwise. The Fedora Privacy Statement is explicit that aggregated information from research activities "is not used to contact the subjects of the report"; this prohibition extends to all FDWG data. 6.2 You will not use access granted under this agreement to target, profile, or intervene with respect to any individual contributor — including for purposes that might otherwise be welcome (e.g., "reaching out to lapsing contributors"). Such interventions, if they are to occur at all, are decisions for Fedora's leadership through its own channels and on its own lawful basis, not consequences of analytics access. ## 7. No redistribution of FDWG data 7.1 You will not extract, copy, publish, or redistribute FDWG data outside FDWG infrastructure and authorized local copies under §9, except in the form of aggregate outputs satisfying §5.2. 7.2 Re-publication of individual public datasets in their original form, from their original sources, is not restricted by this agreement. The restriction is on FDWG-internal data products: correlated raw data, the pseudonymization mapping, and pseudonymized datasets. ## 8. Respect for opt-outs and erasure requests 8.1 You will respect FAS account opt-outs as reflected in the data made available to you. Where opt-out information is propagated through FDWG infrastructure, you will use the most current data available at the time of analysis. 8.2 Where you receive notice (through FDWG channels) that a data subject has exercised a right of erasure, restriction, or objection under the Fedora Privacy Statement: (a) FDWG will update the pseudonymization mapping and pseudonymized datasets to reflect the request, within fourteen (14) days of notice. Depending on the nature of the request, this may include removal of the individual's records, severing of the GUID-to-identifier link, or restriction of further processing. (b) On notice that a GUID has been withdrawn or restricted, you will cease processing records associated with that GUID in any new analyses, and delete or render inaccessible any local copies under §9 containing those records, within fourteen (14) days of notice. (c) Where prior published aggregate outputs were derived in part from the affected individual's data, no recomputation or alteration is required — historical statistical aggregates do not constitute personal data of any single individual, and the Privacy Statement explicitly preserves the historical record of contributor activity. ## 9. Local copy handling 9.1 Where your analysis requires local copies of FDWG data on your own systems: (a) Local copies must be stored on devices under your direct control, with reasonable access protections (full-disk encryption, account password, screen lock). (b) Local copies must not be stored on shared or third-party systems (cloud notebooks, shared drives, AI/LLM service contexts, public code repositories) unless the service is explicitly approved by FDWG for this use. (c) Local copies must be deleted when no longer needed for the analysis at hand, and at the latest when your participation in FDWG ends. 9.2 Raw data and the pseudonymization mapping carry additional restrictions: (a) Raw data should be processed on FDWG infrastructure where possible. Local copies of raw data are permitted only where required for specific tasks (e.g., debugging an ingestion pipeline) and must be deleted promptly on completion. (b) The pseudonymization mapping must not be held in local copies on personal systems under any circumstances. It resides only on FDWG-designated infrastructure. 9.3 You will not commit FDWG data to source control, public or private, even briefly. Code that processes such data is fine; the data itself is not. ## 10. Incident reporting 10.1 You will notify FDWG leadership without undue delay, and in any event within seventy-two (72) hours, on becoming aware of: (a) Any unauthorized access to, or disclosure of, FDWG data in your possession or under your control; (b) Any loss of a device containing local copies under §9; (c) Any published aggregate output that, on reflection, you believe may identify or enable identification of individual contributors contrary to §5.2; (d) Any apparent re-identification of an individual in pseudonymized data, whether achieved deliberately or noticed inadvertently; (e) Any compromise, suspected compromise, or disclosure of the pseudonymization mapping; (f) Any contact, attempted or actual, with you from a third party seeking access to FDWG data. 10.2 The seventy-two-hour figure is borrowed from GDPR Art. 33's controller-to-supervisory-authority timeline; it gives the controller enough margin to meet its own obligations if escalation is required. It is not itself a regulatory deadline binding on you, and good-faith promptness is what matters. ## 11. Term and termination 11.1 This agreement takes effect when both parties sign and continues until terminated. 11.2 Either party may terminate this agreement at any time, by notice to the other. On termination: (a) Your access to FDWG infrastructure will be revoked; (b) The local-copy obligations in §9.1(c) become immediate; (c) The confidentiality obligations in §4 continue indefinitely; (d) The incident-reporting obligation in §10 continues for any incidents arising from data accessed during the term. ## 12. No employment, no compensation, no warranty 12.1 Nothing in this agreement creates an employment, agency, or contractor relationship between you and Fedora or Red Hat. Your participation is voluntary and uncompensated. 12.2 Fedora makes no warranty as to the accuracy, completeness, or fitness for purpose of any data made available under this agreement. 12.3 You participate at your own risk and on your own responsibility, save that nothing in this agreement is intended to limit Fedora's responsibilities as controller under applicable data protection law. ## 13. Relationship to other agreements 13.1 This agreement is independent of and additional to the Fedora Project Contributor Agreement (FPCA). The FPCA addresses intellectual property in your contributions; this agreement addresses your access to and processing of personal data on Fedora's behalf. 13.2 In the event of conflict between this agreement and the Fedora Privacy Statement as it applies to the controller, the Privacy Statement governs the controller's obligations to data subjects. This agreement governs your obligations to the controller. ## 14. Governing law 14.1 [To be completed on adoption — likely the law of the State of North Carolina, USA, consistent with Red Hat's corporate seat, with the understanding that the substantive obligations herein are designed to satisfy EU/UK GDPR requirements applicable to the controller.] ## 15. Amendments 15.1 This agreement may be amended by the Council. Material amendments will be communicated to current Authorized Analytics Volunteers, who may either accept the amended terms or terminate under §11. </details>

pbokoc added this to the Council Meeting Planner project

2026-05-06 11:07:34 +00:00

jflory7 added

Fedora Data Working Group - Authorized Analytics Volunteer Agreement

Version: 0.4.0-draft-scoped

1. Purpose and scope

1.1 The Fedora Project publishes activity data about its contributors (account records, commit history, mailing list and forum posts, group membership changes, and similar records) through its public services, and operates technical infrastructure (web servers, build systems, content distribution, communication platforms, and similar services) which generates operational data about how those services are used. The Fedora Data Working Group ("FDWG") consolidates and correlates this data to produce statistical reports for two related purposes:

(a) Community health analysis. Understanding which efforts successfully recruit and retain contributors, and which work areas need support.

(b) Technical infrastructure analysis. Understanding the performance, reliability, capacity, and usage patterns of Fedora's services, and identifying opportunities to optimize them.

1.2 This processing is conducted under the legitimate interests of the Fedora Project as declared in the Fedora Privacy Statement, specifically the bases stated for "research activities, including the production of statistical reports," for the maintenance and improvement of Fedora's services, and for maximizing the efficiency and effectiveness of those services for all users.

1.3 This agreement governs the relationship between the Fedora Project ("Fedora") and a volunteer ("you", "the Volunteer") who is granted access to FDWG analytics data. By signing this agreement, you become an Authorized Analytics Volunteer: a natural person acting under the authority of the controller within the meaning of Article 29 of the General Data Protection Regulation (Regulation (EU) 2016/679).

1.4 Where an obligation in this agreement refers to data, infrastructure, or actions you do not in fact have access to or perform, the obligation is satisfied trivially with respect to those things. The agreement is written to cover the full range of FDWG analytics work; not every clause will apply to every volunteer's day-to-day activities.

2. The FDWG data layering model

2.1 FDWG operates a privacy-by-design data layering model as a measure under GDPR Art. 25. Three categories of dataset are recognized:

(a) Raw data. Contributor activity data and service operational data as ingested from Fedora's source systems. May contain direct identifiers (usernames, email addresses, IP addresses, etc.) and is treated as personal data under GDPR.

(b) Pseudonymized data. Data derived from the raw data in which direct identifiers have been replaced with opaque GUIDs through a key (the "pseudonymization mapping") held only on FDWG-designated infrastructure. Pseudonymized data remains personal data under GDPR (Art. 4(5)) but is materially less identifying.

(c) Aggregate outputs. Statistical outputs (counts, distributions, time series, reports) computed from pseudonymized data, presented at a level of aggregation that does not identify any individual. Aggregate outputs are intended for publication and sharing outside FDWG.

2.2 Access to each tier is controlled by FDWG infrastructure separately. Your access at any given time is whatever you have been granted; this agreement does not itself grant access. Where this agreement imposes obligations relating to a particular tier, those obligations apply to you to the extent you have access to that tier.

3. Purpose limitation

3.1 You may process FDWG data only for the purposes set out in §1.1: the production of statistical aggregate outputs about Fedora community health and about Fedora's technical infrastructure, and the production and maintenance of the datasets and supporting infrastructure that enable such outputs.

3.2 You will not use access granted under this agreement for any of the following:

(a) Producing outputs that identify, profile, or single out individual contributors or other identifiable individuals, except where the individual is the data subject themselves and they have requested information about their own data through a documented process.

(b) Marketing, recruiting, evaluating, ranking, or making decisions about individual contributors or other identifiable individuals.

(c) Research published outside Fedora's analytics outputs (academic papers, third-party publications, personal blog posts containing non-aggregate data, etc.) without prior written authorization from the Council or its delegate.

(d) Any purpose unrelated to the statistical aggregate outputs described in §1.1.

3.3 You may choose your own methods, tools, and analytical questions within the purposes set out above. Method-level autonomy is expected; purpose-level discipline is required.

4. Confidentiality

4.1 You will treat FDWG data as confidential. The fact that the constituent source datasets are individually published or operationally generated by Fedora does not make the correlated form non-confidential: correlation across systems creates a more identifying data set than any individual source, and that combined view is not itself public. Pseudonymized data, although it does not contain direct identifiers, remains personal data and is similarly confidential — combinations of fields within it may be identifying, particularly within small sub-communities or for distinctive traffic patterns.

4.2 The pseudonymization mapping (the key linking GUIDs to direct identifiers) is the single most sensitive artifact in FDWG. It resides only on FDWG-designated infrastructure and may not be exported, copied, transmitted, or made available to any person or system outside that infrastructure under any circumstances. The protective value of pseudonymization depends on this isolation.

4.3 You will not disclose, share, transmit, or make available FDWG data to any person who has not signed this agreement, except as required by law or with the prior written authorization of the Council or its delegate.

4.4 The confidentiality obligations in this section continue after your work with FDWG ends.

5. Prohibition on re-identification

5.1 The protections in this section apply to any individual who is or could be identified, directly or indirectly, in FDWG data — including Fedora contributors, registered service users, and unregistered visitors to Fedora's public services. Where this section refers to "individuals," it should be read in that broad sense.

5.2 You will not attempt to re-identify any individual in pseudonymized data, whether by correlating GUIDs against external information, by inferring identity from combinations of fields, or by any other means.

5.3 Aggregate outputs published outside FDWG must not identify or enable identification of individuals. You will apply, at minimum, the following published-output rules:

(a) Cell suppression. Aggregates with fewer than five distinct individuals will be suppressed or grouped, unless an exception is documented and approved.

(b) Small-community awareness. For SIGs, working groups, sub-projects, or low-traffic services with small populations, aggregates may identify individuals even above the §5.3(a) threshold. You will exercise additional judgment in these cases and prefer suppression where in doubt.

5.4 Where a contributor has opted out of public display of a particular FAS field (per the Fedora Privacy Statement, "Publicly Available Personal Data" section), no FDWG output — aggregate or otherwise — will re-expose that field, whether directly or by inference. Opt-out state must be reflected in pseudonymized datasets at the point they are produced.

6. No contact, no targeting

6.1 You will not use access granted under this agreement to contact any individual identifiable in FDWG data, whether the contact is for analytics-related purposes or otherwise. The Fedora Privacy Statement is explicit that aggregated information from research activities "is not used to contact the subjects of the report"; this prohibition extends to all FDWG data.

6.2 You will not use access granted under this agreement to target, profile, or intervene with respect to any individual identifiable in FDWG data — including for purposes that might otherwise be welcome (e.g., "reaching out to lapsing contributors"). Such interventions, if they are to occur at all, are decisions for Fedora's leadership through its own channels and on its own lawful basis, not consequences of analytics access.

7. No redistribution of FDWG data

7.1 You will not extract, copy, publish, or redistribute FDWG data outside FDWG infrastructure and authorized local copies under §9, except in the form of aggregate outputs satisfying §5.3.