Balancing privacy vs. transparency for the travel fund

[tobie]

I'm stoked that the foundation has a travel fund. I think that's super important.

It's equally important that there's transparency in how those funds are attributed, used, etc.

But I'm uneasy for that transparency to come at the cost of the privacy of those that benefit from those funds.

I'm concerned that having this data public could do them a disservice, e.g. when negotiating a salary or client work.

Similarly, for those whose request is rejected in public, this can feel humiliating.

I'm sure there are solutions that would better balance the privacy of contributors requesting travel funds and transparency requirements.

Edit: There are of course security concerns which I should have made center stage from the get-go.

[mhdawson]

If we go this way I think we should " alert a mailing list" to which CPC members are subscribed as part of their ownboarding.

What I don't follow yet is which of the "problems" are addressed by moving to this. Is it that the requests will only be public after travel is complete?

[tobie]

When we discussed this during the work session we agreed that:

• transactions should be anonymized when made public
• we should ask for:
  • GitHub handle
  • Related OpenJSF project(s)
  • OpenJS projects contributed to
  • whether contributions are job related:
  • name of employer if any
  • whether the employer was asked to support the trip
  • Reason for refusal
  • this info can then be used to:
  • determine whether the person meets the active contributor requirements by reaching out to the relevant project’s maintainers
  • determine whether the person is eligible (their contributions aren’t job related or the CPC has agreed to an exemption)
  • the trip is relevant (as determined by project maintainers).

[mcollina]

I think the list of recipient should be made a private repository accessible to the CPC members. The goal here would be for it to not be google-indexable.

[tobie]

My suggestion here would be to agree on goals and requirements first and then only look at implementation aspects.

I think our overall goals and requirements with this fund should be along the lines of the following:

1. provide financial support for active independent contributors to participate in events that benefit OpenJSF projects, working groups, or collab spaces.
2. be publicly transparent about how those funds are used
   • be able to share anonymized data publicly, for example:
     • funds requested vs. fund accepted
     • how much funds are distributed by project/WG/collab space
     • how much funds are distributed by event
     • how much funds are distributed to independent contributors vs. employed contributors
     • how much funds are distributed to contributors who self-report as member of an underrepresented minority
   • have a private papertrail of what decisions were made, by whom, and their rationale
3. be mindful of contributor's privacy
   • make decisions in private
   • do not share names or location of funded individuals without their agreement
   • agreement for information to be shared publicly cannot have impact on eligibility
4. be responsive
   • acknowledge receipt of request immediately
   • approve or reject requests quickly (ideally within 2 business days)
   • if fund is rejected, inform requester as to why, with escalation path (CPC meeting?)
   • if request needs escalation, inform requester right away plus explain why
5. be efficient
   • delegate process and most decision-making to foundation staff with the ability to escalate back to the CPC or project maintainers when necessary
   • have clear guidelines for how to approve requests
   • request relevant information from requesters to identify
     • which projects they're contributing to,
     • if they're doing so in a personal capacity or as part of their job
     • escalation path to maintainers to approve active contribution when in doubt
       • have a list of project maintainers
       • have clear guidelines for maintainers on how to assess eligibility
     • escalation path to CPC for any contentious issue
     • use a solution that CPC members and project maintainers can be onboarded to quickly

[joesepi]

@bensternthal will make a PR to implement this. Yay!

[bensternthal]

Based on the work we have done so far I think this issue is no longer valid.

For anonymous reporting we have issue #1166

[tobie]

Based on the work we have done so far I think this issue is no longer valid.

I think it has been resolved, so should be closed as soon as the rest of the work has been landed.

[tobie]

Fixed in #1230.