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 XXX@YYY.org 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 https://github.com/nodejs/admin/issues/445#issuecomment-567211536).

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

[tobie]

To be clear, I'm not suggesting that the CoC Team should have anything to do with this. What I'm saying is that we could create a dedicated group that would be responsible for approving travel fund requests in a privacy-preserving manner, much like we have a dedicated group that handles CoC violations in a privacy-preserving way.

[ovflowd]

Yeah, @tobie I got that. Sorry if I didn't make it clear enough that you were just giving an example 🙈

[tobie]

NP. I think I didn't understand your comment properly. Apologies. In particular your last suggestion:

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

This would essentially create two processes. Why not make everything private by default?

[ovflowd]

I'm fine either way with Google Form. Yet I personally prefer having stuff on GitHub not just for convenience but it creates immediate natural transparency.

But it also depends if we want to keep this open and accessible to then public.

On the GNOME project, Travel fund requests are 100% invisible/private (GitLab confidential issues) and only visible to the Travel Committee. We could follow a similar approach by having a private repository. I.e:

• Travel Committee repository
• Create a Travel Committee
• Travel fund requests get created/submitted through Google Forms and transformed into these private PRs through an automation.
• Once PR gets merged, author gets notified on their email address through an automation that their request got approved/and next steps
• Rejects (PR getting closed) triggers same workflow
• Authors can reach out travel committee through email if they have questions

With GitHub issues/PRs I feel we have a natural history/internal transparency and natural way of reviewing things.

[mcollina]

I don't think a google form would cut. We want to github to validate the username: that the request come from a specific org member.

I think we would need a custom app.

[ovflowd]

True, well the Google Form could be behind a GitHub OAuth but a custom App also works I'd say.

[tobie]

I don't think a google form would cut. We want to github to validate the username: that the request come from a specific org member.

When we disbursed the funds, we don't check that the request comes from the right GitHub handle. So I'm not sure that validating the GitHub handle during the initial process actually matters that much.

[ovflowd]

I think @mcollina point is more about avoiding people to impersonate others / ensure it's coming from the actual people.

[tobie]

I think @mcollina point is more about avoiding people to impersonate others / ensure it's coming from the actual people.

Yeah, that's a fair point. I see how assessing that the request comes from the right person is a different issue than making sure the funds are disbursed to the right person.

[tobie]

I don't think a google form would cut. We want to github to validate the username: that the request come from a specific org member.

I think we would need a custom app.

Alternatively, we can ask requesters to create a private gist with the date at which the request is made and provide a link to it in the form. Not as foolproof, but way easier to set up!

[timmywil]

I'm +1 on privacy, but -1 on google forms. I'd be fine with a private gist (maybe in the short term?). I think the best option would be a custom form that either sends an email to a group email that's specific to the travel fund or opens a PR on a private repo as @ovflowd suggested.

[tobie]

The gist was to link the request to a particular GitHub account, not to share the info itself.

[tobie]

Worth noting from Node TSC's meeting that one of the TSC's voting members has not been requesting travel funds because of the public nature of the process.

[tobie]

Not directly related to this issue, but it's worth mentioning https://github.com/openjs-foundation/community-fund/pull/26 here, as an issue that would have been better served by a more flexible process, private management, and more context.

[ovflowd]

This has been around for 4 years, and after chatting with @tobie on Slack, I want to emphasize that I also feel uncomfortable with sharing personal info publicly.

I want to say that regardless of the path we choose, as I'm sure we will work to get something great out there, I'd like to emphasize the urgency and immediacy of this issue to be worked on, as it's been around for a long time.

Also, on @tobie's previous comment, I agree that the current policies might need some rewording and updates to clarify better rules and their exclusion and maybe a better process for how the CPC evaluates and welcomes new PRs. Albeit, if we decide to make drastic changes to how the whole process is done from end-to-end (who reviews, where it is shared), I would also vote for a more inclusive approach that is more flexible and welcoming. Since, ultimately, the CPC votes for each submission, we need a way to land something that would be against the goals of the Foundation.

[ljharb]

In today's CPC meeting, we discussed some iterative approaches.

One suggestion was to have, on request, pre-travel requests kept private to the CPC (with an anonymized placeholder in the repo), and then post-travel, make everything public as it is now.

A stronger suggestion was to just take all the travel funding requests and make them internal to the CPC, period, even post-travel.

There seemed to be full support for doing one of these proposals, and I heard no objections to the stronger one, so my takeaway is that unless someone on the CPC has objections, we'll change to the stronger suggestion.

[mcollina]

We would need to maintain the documentation on how to ask for funds public for the stronger suggestion.

[ljharb]

Agreed; that would be part of the effort to make a change :-)

[ovflowd]

As I was not attending the meeting, just wanted to publicly state the +1 for both approaches from my side 🙃

Also, were there any mentions for a creation of the aforementioned "Travel Committee"?

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