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.

[christian-bromann]

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

This seems like something we can prevent by setting clear rules about who is eligible for the travel fund and who isn't.

[mhdawson]

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

In the past there have only been a few cases of this and I think they were handled in a manner to minimize that aspect.

I wonder if a survey in which we ask about concerns related to the fund being public would help. As you say its a tradeoff and before we reduce transparency and add more work for those managing the fund it would be good to understand if those who will use the fund see it as a concern or not.

[bnb]

This seems like something we can prevent by setting clear rules about who is eligible for the travel fund and who isn't.

In the Node.js project we outlined pretty direct rules and guidelines about who was eligible and for what, but there were absolutely occurrences where folks either did not understand or thought they found relevant exceptions. I think that no matter how much we document, there’ll still be outliers.

I wonder if a survey in which we ask about concerns related to the fund being public would help.

I am concerned that we’d only get a homogenous response and not one from the folks who would actually be impacted by this. If we do go this route, I’d ask that we ensure we’re sufficiently understanding if the responses are representative of the diverse audience who could be negatively impacted in the ways described in the OP.

[mcollina]

I'm not sure it would be such big of a problem. It worked extremely well for the last few years, and no one complained. Is this theoretical or have you got a real-life example?

Why would it be a disservice when negotiating?

---

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

I think the best course of action is to amend the docs so that it states "in doubt, open an issue or contact [email protected] before making any reservations". We really do not want people being rejected in public - on the other hand it's up to them to know if they are eligible or not.

[tobie]

I'm not sure it would be such big of a problem. It worked extremely well for the last few years, and no one complained. Is this theoretical or have you got a real-life example?

The first and only interaction I had with the travel fund was to reject the request of someone. :)

Unless there's a safe and private way for people to complain about this, we can't expect to find out whether people are complaining about this. And even if there were such a system, how do we know people would feel confident complaining to an org that's not respecting their privacy in the first place?

[tobie]

A privacy-respecting solution can be as simple as setting up a Google form or similar, and the transparency requirements can be fulfilled by releasing a few data points yearly.

[mcollina]

I think that will complicate approval of the request as right now it does not need any special permission and can be easily linked & forwarded. I'm -1 in changing the process for now.

I'm happy to add a private channel to provide feedback on the travel fund.

[tobie]

I think that will complicate approval of the request

I assumed the concern was one of transparency, not conveninence for the people having to handle it. I understand we're all busy, but I don't think this is a reason to disregard people's privacy.

Some underepresented minorities are actively persectued in some countries. Just asking them to be public about the fact that they identify as such might put them at risk.

I'm pretty sure we can find options that help address usability concerns for those having to make the decisions while being more respectful of people's privacy while making sure that a fund designed to improve inclusivity isn't excluding people because of how it's implemented.

[mcollina]

I strongly disagree in making the travel fund management private. Tracking the funds in public makes it easy to verify who is elegible, as somebody can send a link and verify the person membership in a specific project. It also makes it fair, as we can all see whoever used the funds in the past.
I think that publishing the fact that somebody used the funds to go to XYZ is important and part of the tradeoff when requesting the funds.

[timmywil]

What if only the approval process was private? For instance, the process could be

1. Send an email to some group email address for approval.
2. When approved, open a PR.
3. Continue as normal.

[ljharb]

Why is it particularly humiliating to be told you do not meet explicit eligibility requirements? I don’t think any of them are qualities of character, for example.

[christian-bromann]

In the Node.js project we outlined pretty direct rules and guidelines about who was eligible and for what, but there were absolutely occurrences where folks either did not understand or thought they found relevant exceptions. I think that no matter how much we document, there’ll still be outliers.

@bnb can you point me to these guidelines? I am asking because I wonder if it makes sense to somehow connect this to the governance of each project. There are a lot of projects that define different types of contributors to which the governance can say: if you are this person (e.g. a Node.js collaborator or higher) you will be automatically eligible to access travel funding. For all other cases (e.g. someone has made a lot of contributions but hasn't been elected to a higher status yet) every project could nominate a contact person that people can contact privately to ask if funding request would be accepted or not. This way every project defines a clear barrier while at the same time allows to privacy when acceptance is in doubt.

[WaleedAshraf]

I think it would be good to have a way (contact person) for new people to privately ask if they are eligible for travel funds or not before opening a PR in public.

[mhdawson]

I'm not sure it's as clear as it once was for Node.js. At one, you point need to be an individual member of the Node.js Foundation to use the travel fund. Individual membership was free for those who were members of the Node.js org. With the merger, I'm not sure individual membership (or at least the ability to sign up) is still working (see nodejs/admin#445 (comment)).

This is something we need to improve. I agree that each project likely needs to set the qualifications and how they are validated and that needs to be documented somewhere relatively easy to find.

[brianwarner]

It's working but it's limited to Node, and it requires people to request a discount code from me, and that system is in the process of being sunset. It's the CPC's call of course, but if I were designing a travel request system today, it... probably isn't something I'd recommend including.

If it were me, I'd recommend streamlining the application process by creating a straightforward, crisp PR template that collects the requestors' applications, and then leave it at that. It encourages consistency and will make requests easier to review in light of all other approvals. And finally, these written responses are likely going to be more informative than whether the requestor has registered as a member in an arbitrary system somewhere.

Also, not related to this thread but related to the topic of streamlining processes, would the CPC consider simplifying the approval file (e.g., 2020.md)? That's a pretty gnarly table to manage in markdown, the columns tend to get misaligned easily... :-)

[jasnell]

I'd definitely be -1 on making any part of the request and approval process private. Rejections may feel crappy to the person doing the rejection but they're nothing personal and should only ever be done when eligibility guidelines aren't met -- and they should be communicated as such with clear explanation about why. Transparency in this kind of process is essential and we shouldn't step back from it.

[tobie]

I see a strong -1 sentiment to my proposal from the community of people actually doing the work, so I'll rescind it.

I do want to point out that we haven't really heard from the community of people you're trying to help with this, and in particular from those who are deciding not to get involved precisely because of the privacy problem I outline. Please do keep an eye out and an open mind for contributors expressing such concerns and revisit if you do. Thanks.

[mhdawson]

@tobie will keep an eye out and if you talk to people who have concerns or who are applying because its public please ask them to talk to me or Joe.

[tobie]

Hi folks, I'm reopening this because in a private conversation, someone who would be entitled to getting travel funds expressed genuine safety concerns about having to share location and travel dates publicly.

I also believe that there are GDPR concerns with storing this information in public and not being able to delete it should we receive a request to do so.

[mcollina]

I have somewhat changed my mind in this regard. I think the individual has a right to keep this private and it might be better to hide it completely.

[ovflowd]

GitHub could have a confidential issue functionality where only members of the repository and the author can see the issue...

I believe the author has the right to keep certain information private, but honestly the information should still be public to the CPC. (We need to be able to know the full extend of a travel request if we want to vote on it, right?)

Definitely +1 to find ways that we can explore to make people's private information safer and make them feel more comfortable 🙏

[ljharb]

I'd love to understand more about @tobie's contact - what is the actual concern? That someone will know they're going to a very public event? The travel fund stuff doesn't require lodging details or even dates, only amounts.

[tobie]

@ljharb wrote:

I'd love to understand more about @tobie's contact - what is the actual concern? That someone will know they're going to a very public event?

Not all events are public. I personally go to a lot of events which aren't public or in which it is fairly possible to participate effectively (including presenting, leading sessions, etc.) without this information being publicly available beforehand (or even at all). I checked, and that is the majority of events I travelled to since the beginning of Covid and the majority of upcoming events I'm going to. Public advocacy isn't the only way to be impactful.

The travel fund stuff doesn't require lodging details or even dates, only amounts.

The process doc says:

Include as many fields as possible:

• The name of the event you plan to attend.
• The location, dates of the event and where you will be traveling from.

@ovflowd wrote:

I believe the author has the right to keep certain information private, but honestly the information should still be public to the CPC. (We need to be able to know the full extend of a travel request if we want to vote on it, right?)

"Public to the CPC" isn't public. It's fairly easy to restrict this information to whoever needs to access it to be able to make a decision about it. Furthermore, the CPC could totally delegate decision-making to dedicated group (like for the CoC) or foundation staff it they so wished.

---

Overall, from a transparency perspective, there is no benefit to having the names of people requesting funds be made public. We could have an anonymized report each year that would be just as useful. Having folks request funds on GitHub just makes our lives easier by allowing us to do all of our work from GitHub. But it does so at the expense of people's privacy and sometimes even their safety.

It also has a DEI component to it, see for example this comment in the Literature review section of this 2017 paper:

Numerous studies conducted on online privacy and self-disclosure on the Web found sex as an influential factor. It was found that women are generally more concerned about their privacy on the Web than men (Graeff and Harmon, 2002; Milne, Rohm and Bahl, 2004; O'Neill, 2001; Sheehan, 1999; Taddicken, 2014; Wills and Zeljkovic, 2011), particularly on social networks (Fogel and Nehmad, 2009; Hoy and Milne, 2010). The main concern that discourages women from engaging in electronic commerce is the possible disclosure of personal information; however, men are willing to accept that risk for the earned profit (Michota, 2013).

---

A very basic setup with a Google form and 3 minute review in the private part of each CPC session wouldn't make our lives more complicated and would solve this privacy issue.

[ovflowd]

"Public to the CPC" isn't public.

That's pretty much what I said.

to dedicated group (like for the CoC) or foundation staff it they so wished.

Not sure delegating travel requests to the CoC makes sense (I know you only gave an example)

That someone will know they're going to a very public event? The travel fund stuff doesn't require lodging details or even dates, only amounts.

Indeed we don't require specifics, but I can imagine some of the data being sensitive to some, possibly?

But it does so at the expense of people's privacy and sometimes even their safety.

Requests could be submitted then to the CoC e-mail and we create an Anonymized PR. (Still same process, but all sensitive information including names removed).

[ljharb]

It didn't come up; we all seemed to assume that the CPC would continue to field these requests.

[ovflowd]

Gotcha, let me rephrase then, do we (or at least you) believe we need a dedicated Travel Committee, which could hold these private issues on a proper matter?

I say this as the bigger the CPC is, the harder it is to fill everybody in on every single travel request, for example, lack of context or understanding of the request, who the requester is, and etc.

Having a dedicated team/WG feels like something that could be beneficial. Something like "Community Fund WG" or "Travel Committee"

[ljharb]

That seems like another iterative approach we could consider if indeed it becomes untenable for the CPC to handle it, but it's been fine so far. The privacy concerns seem to be more about internet randos than about project participants.

[mcollina]

@ovflowd I don't think a travel committee would be helpful. The key reason this falls on the CPC is its equal representation of projects. A travel committee would have a similar composition. Also, I think we should reduce the meetings, not add more.

[ovflowd]

That makes sense, thanks @mcollina! I also agree that having the CPC as a whole here is inclusive, what I was "suggesting" was indeed about maybe reducing the noise to the whole CPC or something, but the current model indeed works well :)

[tobie]

+1 on the stronger suggestion too. IMHO, the tricky bit is getting the operations bit right, if we want to avoid spending too much time on it plus being able to reply in a timely manner.

[bensternthal]

Folks, I have done some noodling on this, and here is what I am thinking.

First, using Github's Security Vulnerability reporting (IMHO) isn't the best solution. There are a lot of fields that are not relevant, nor can we manage those fields, I think this will result in confusion.

I would propose the following:

1. We create a google form to privately intake CPC travel fund requests
2. Those request go into a spreadsheet, folks can subscribe to changes or we can alert a mailing list
3. At some regular cadence the CPC or the travel committee approves or does not approve a request
4. Approved requests are logged publicly here (same spot).

[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.