Travel Fund approval and being careful about funds available

[hackygolucky]

It is written in the travel fund as documentation, but I wanted to reiterate this:

The @nodejs/tsc and the @nodejs/community-committee members are responsible for approving requests for the travel fund. Another responsibility as part of this approval is that we as an admin group have the responsibility of periodically checking in to make sure we aren't going anywhere near reaching the limit of the travel fund. If we go over the limit, that means we have approved someone's travel and they aren't going to get reimbursed because the Board hasn't approved that amount of money for us to use. It is at our discretion to monitor this as part of any single one of us +1ing a travel fund pull request :)

When we are getting close to the limit, we can request more funds from the Board, but that does not ensure it will be granted.

Scared? It's a big responsibility! But also a cool one that enables a lot of great, hard working contributors to work in-person.

Does it make sense for us to (A)have a meeting about this, (B)have some checks in place to make sure we aren't going over without being aware, or (C)make sure everyone approving requests understands the weight of responsibility they are carrying as part of this?

I think a little bit of A, B, and C is needed. Thoughts?

cc @mhdawson @MylesBorins @bnb Please please review this with existing members at next meetings to make sure the message is received.

[mhdawson]

Could we ask people to decrement the total available as part of the PR making the request. We can double check that and we'll see what's left more easily.

[mhdawson]

We should probably also break out the sheet so its per year to make it easier to track as well.

[mcollina]

@mhdawson I we truly need a spreadsheet for this, with the responsibility of whoever merge the PR to update the spreadsheet.

[Trott]

@mhdawson The problem with asking people to document the amount left is that there will likely be a dozen or more of these for Collab Summit events. Once one lands, the other 11 have to be updated. When the next one lands, the remaining 10 need to be updated.

If we want to have a keeping-track aspect to this, then it probably ought to be the responsibility of whoever closes/lands the PRs. Which brings up another question: Who does that and when? Like, I think my request has effectively been approved, but there's no official indication.

[mhdawson]

@Trott that's a good point. Ideally, we have a volunteer who managed the travel fund. @bnb do you think we might find a volunteer on the CommComm side?

[bnb]

@mhdawson I'm not sure, though that is a good question and definitely something that someone may be interested in.

Ping @nodejs/community-committee.

[MylesBorins]

I would like to suggest that perhaps this is something the foundation, specifically someone focused on community management, take responsibility for.

[mcollina]

To me all travel requests from any member that has been minimally active should be accepted, within reason (economy flights, etc).
I do not recall anything we have denied, and the biggest concern right now is asking for more money after this is spent.

I’m +1 to write down some criteria for this, and hand it off to a staff at the foundation.

[mhdawson]

There was some discussion in the community-committee meeting along with a volunteer to manage (possibly a "Treasurer"). The approach was still for TSC/comm-comm to approve but the volunteer to

• help make sure approved requests get landed
• keep an eye on the funds to make sure we don't go over
• prepare a report (maybe quarterly) to present to TSC/CommComm

[MylesBorins]

@mhdawson while I like the idea of making a volunteer position for the treasurer I still strongly think this is something that should be overseen by an employee or contractor of the foundation. Managing fiscal resources and being accountable for it is not something I'm very comfortable putting on the shoulders of a volunteer.

What happens if someone makes a substantial accounting error, if it is a volunteer that puts us in a very awkward position with less recourse.

[mhdawson]

@MylesBorins I think you'll need to outline your proposal in a bit more detail then. In the discussion there was still the belief that the TSC/CommComm should approve so detailing how the full process flow, who does approvals, etc would help clarify for the discussion.

[MylesBorins]

TLDR; you outlined a role for a treasurer

The role should not be a volunteer but an employee or contractor of the foundation

[Trott]

I'll point out that there's this in our documentation at https://github.com/nodejs/admin/blob/master/MEMBER_TRAVEL_FUND.md#reimbursement:

The community manager or a member of the Node.js Foundation team within the Linux Foundation will report back amounts consumed from the travel allocation on a monthly basis to the Chairs.

As far as I know, that has never been the case. (Or maybe it was when Tracy was a Foundation employee?)

[Trott]

While I'm at it, I'll also add that the instructions in MEMBER_TRAVEL_FUND.md doc for submitting for reimbursement do not align with what I've had to do in the past. There's some form I've been asked to fill out but there's no mention of it in that doc. Is the form still needed or should we just provide the info as in the doc? /cc @mrhinkle

[Trott]

(I imagine the form is still required since that's where they get the name and address from....)

[hackygolucky]

@MylesBorins @Trott @mhdawson the treasurer, as outlined in our discussions, would help facilitate on the CommComm side to liason WITH the person on the Foundation side, because it takes both sides to coordinate. It can't just be the Foundation because they aren't the ones necessarily involved in each repo of the project work to have the context. The treasurers, in CommComm or TSC, would be the context providers.

[jemjam]

And on this front, I'm very happy to help provide context and support from CommComm side. The only hesitation I'd have is not having the data related to where we're at with the budget, though if the TRAVEL_FUND file is up to date then we should be good for a bit anyway.

Either way, I'm happy to liaison or support in whatever fashion.

[MylesBorins]

building on what @JemBijoux mentioned regarding keeping the TRAVEL_FUND up to date, something we could consider is introducing CI into the mix.

Brookly JS actually has a budget.js that has to exit 0 in ci for CI to be green.

We could introduce a similar type of ledger with some sort of CI + monitoring. This could be one of the things we measure in nodejs/build#1213. We want to know the "availability" of the budget and potential receive notifications when we reach certain amounts of quota.

[mhdawson]

CI job to help would be great if we can find a volunteer to implement it.

[WaleedAshraf]

@mhdawson @MylesBorins
If the plan is to use Travis, I can help with it.

Travis can send notifications to slack/emails/irc etc.
We can skip notif if expenses are under a limit, and notify only if it increases the limit.

• we'll need to follow some format in repo, like:
  admin/budget/2017.js
  admin/budget/2018.js
  .
  .

[mhdawson]

Breaking it out by year would be good anyway.

[jemjam]

Love the idea of using CI to help automate some of this.

As I dig into this further, it might be nice to outline which transactions have just been earmarked, vs those that have actually completed and been reimbursed? It's not totally clear to me whether the remaining budget as it stands includes all of the values in the travel doc yet. (However, this could also just be me becoming familiar with all the details...)

[codeekage]

Hello Everyone!

Where are we on the CI are we outsourcing it or having a WG or a team to carry the task?

[jemjam]

So far I've had a bit of communication with concerned parties about the status of the budget, and this PR landed recently: #123. That's looking fine, so (the essence of this thread) we can continue to follow the same procedure of approving requests in this repo.

There was some discussion about setting up a CI job, but I haven't heard anything on that front yet. I think the idea is that we set up a standard format (json files) to track the expenses and let a job verify that we haven't gone over budget yet. I'm not familiar with the CI set up used though, so am not sure what I could do to help move this forward? Either way, I think we're all in agreement that doing more than just the markdown table would benefit everyone.

[codeekage]

@bnb @hackygolucky @mhdawson what could we do to move this forward?

[mhdawson]

There was a discussion in the CommComm meeting today. I think @JemBijoux is going to submit a PR to capture what the role will be in the admin repo and we'll go from there.

[jemjam]

Yes! Here's a quick summary of what we talked about today:

• Next step for me: I'll submit a PR into this repo about “the how” the treasurer role will proceed. (I'm still coordinating a little bit with the foundation side here, will report back...)
• The reason for a treasurer is to have someone who can provide the context to the foundation, so having a treasurer also on the TSC side could be helpful. However, we get a lot of that context via the PR's already, so maybe a secondary treasurer isn't necessary. I'm open to handling treasurer duties for both CommComm / TSC if that's fine with y'all. Just want to make sure nobody feels left out on TSC side though (if you wanted to promote someone).
• This could be an interesting opportunity to invest in an “admin role” that could be more cross functional.
• Someone mentioned Myles has proposed some cross functional TSC / CommComm meetings, might be a good time to think about those again. (Good topics for those meetings: budget checkin, collab summit updates, etc)
• Maybe something like a quarterly meeting here would be good.

[jemjam]

Alright, been meaning to follow up on this sooner. (I've also had some amazing early summer where I live, so I've been outside a bit more.)

I had a little check-in with Mark and some foundation folks, and we've agreed for the time being to just keep a simple spreadsheet (which I will help keep up to date as pull requests land here). A CI job is a great idea, and while I'm not opposed to setting something up, I don't think it's necessary either. The table in the travel fund doc gets us most of the way there.

Initially, I think some of us (me for sure) had concerns about approving requests without truly knowing the status of the budget. However, as it turns out, we're definitely still sitting fine. And as Tracy noted in the initial post: if it will helps folks in getting together to collaborate, the board can make some things work. It's been made clear to me that we should feel comfortable making use of this if it will make the difference in getting folks together to collaborate.

All of this said, there were still some questions noted above.

• Should we ask people to decrement any totals?: I don't think this is necessary. The person in the treasurer role (which I've volunteered for now) can keep track of updating a spreadsheet against totals (remaining vs what's approved but pending), and have check-ins with someone from the foundation occasionally to review the balance. If there's ever a concern around totals, a separate issue will be raised and we can tighten things up.
• How do we know when a request has landed?: For the sake of individuals, assume that your request has been approved once you've gone through the pull request and everything has been merged. I think it's fine still for any one of us to merge requests that have had the proper approvals. However, I'll try to keep an eye on any that are open/approved and make sure they land sooner than later (and that records are up to date)
• Once your request has been approved, please keep in mind that it's important to submit your records for reimbursement in a timely fashion (as per the directions in the travel document). We should be fine so long as pending requests are always reimbursed and closed out in a timely fashion. Things only get tricky if we approve way ahead of what's been accounted for, so I think it's worth stressing that we don't put that off.

I put together a little pull request that updates the travel doc and hopefully addresses some of this. Let me know if there's more we should do here or there are questions / concerns?

[rachelnicole]

This is awesome. Great job @JemBijoux !!

[mhdawson]

I agree with all of your suggestions for the questions above :)