proposal: OpenJS Travel fund #268
Conversation
As far as I am aware, there is none, despite there being mention of one in the current document in the Node.js admin repo. That liaison might have been useful at some points. As far as I know, the money itself has been handled/overseen entirely by Linux Foundation staff. /cc @brianwarner TSC/CommComm approve individual requests, but don't pay a whole lot of attention to the fund beyond that. |
|
@jorydotcom asked:
That's something we'd have to decide. I propose we explicitly open it to regular or voting members. On the other hand, it appears that the role was never really even used much in the old fund. Maybe we can just eliminate the position entirely? |
|
To second what @Trott said, I'm not aware of a treasurer's role in the current flow. The Node TSC/CommComm members handle all of the decisions on who receives what, then document it in the repo. At that point, they effectively turn things over to me. Once travel is complete, I process the reimbursement requests up to the amount approved in the repo, and post periodic updates on the actual reimbursed amounts. Once that's done, it's back over to TSC/CommComm, who can look at the total of the actual reimbursements and use that to offer the next round of travel assistance. This happens iteratively until the budget is consumed or the year is over. This process seems to work well (particularly now that we have an alternative to spreadsheets and zipfiles), in large part because the responsibilities and interfaces are cleanly delimited. I'd suggest the role can be removed from the new proposal without negative consequences. |
|
Okay, I'll adjust the proposal to note removing the definition of the position. |
|
|
||
| ## What is necessary to complete this proposal | ||
|
|
||
| - Definition and wording of the travel fund mechanics, mostly moving files and updating references. |
There was a problem hiding this comment.
I would like approval and buy in from both node.js TSC and CommComm on this one before moving it to Stage 3.
There was a problem hiding this comment.
I was hoping for a couple suggested people I could @mention here, to get feedback from the get-go. Who would you suggest?
There was a problem hiding this comment.
It's unfortunate that @-mentioning nodejs teams doesn't cause notifications in this org. Otherwise, it would be a simple @nodejs/tsc @nodejs/community-committee
There was a problem hiding this comment.
Oh okay, that’s easy. I’ll create an issue in nodejs/admin and mention both those teams. Thanks.
There was a problem hiding this comment.
We decided in today’s meeting that an issue should be created in the admin repo, @mention the two teams, include a link to this proposal, and additionally include a link to the proposal staging process.
But we thought to merge this as a stage-0 proposal first, after the conversations here are resolved, so the conversation about promotion to stage-1 can start fresh with larger involvement.
|
|
||
| ## Why this proposal is important | ||
|
|
||
| Organizationally, the Node.js project is at the same level as the other impact projects in the Foundation, and so the travel fund should benefit all projects equally in opportunity. Plus, the sponsorships which pay for the fund sponsor the entire Foundation, not just the Node.js project. |
There was a problem hiding this comment.
One of the assumption here is that the Node.js project should not receive any less funding due to the merger. I think this should be clarified.
cc @Trott.
There was a problem hiding this comment.
I think that that depends more upon the board's discretion with the budget, but I can add language to suggest that the budget be raised to accommodate the increase in people asking for funding.
There was a problem hiding this comment.
One of the assumptions here is that the Node.js project should not receive any less funding due to the merger.
How could we ensure this if there is a common fund and approvals are done by CPC members?
Or is your clarification more around explaining what we'll do so that it will mostly likely be the case (since for example we've expanded the size of the fund so that we expect that all requests from members of the Node.js project in addition to the request from members of other projects can be accomodated)
There was a problem hiding this comment.
Or is your clarification more around explaining what we'll do so that it will mostly likely be the case (since for example we've expanded the size of the fund so that we expect that all requests from members of the Node.js project in addition to the request from members of other projects can be accomodated)
Yes, that is what I meant. I'd like to avoid codifying specific quotas and rules unless we actually need them. Since it doesn't even appear that there has ever been an issue of abuse of this fund, or lack of budget.
Should we count the number of new members being added to the fund due to the foundation merge, calculate the percentage increase, and get pre-approval of an expanded budget before continuing?
There was a problem hiding this comment.
Should we count the number of new members being added to the fund due to the foundation merge, calculate the percentage increase, and get pre-approval of an expanded budget before continuing?
I think so. The overall expectation was that Node.js would not suffer from the merger.
There was a problem hiding this comment.
Can we further discuss the wording you'd prefer to see here? I had a little trouble understanding your latest comment.
My reading of this is to remove the travel fund from Node.js in a way that will definitely not benefit the project.
The purpose of the CPC is to benefit all the projects.
My goal with this proposal is to keep things the same for the Node.js project, but extend the benefits to the other projects. Could you be satisfied by some future research where I provide numbers for current usage trends, and an increased budget to preserve the current benefits to the Node.js members, while extending the benefits to all projects?
This year, I am given to understand that some of the non-Node.js project members were awarded travel funds to attend the collaborator summit in Berlin. Do you feel that this caused a negative impact to the Node.js project?
Board approval is necessary to complete the proposal. I will add that to the text now.
There was a problem hiding this comment.
I suggest changing
Organizationally, the Node.js project is at the same level as the other impact projects in the Foundation, and so the travel fund should benefit all projects equally in opportunity. Plus, the sponsorships which pay for the fund sponsor the entire Foundation, not just the Node.js project.
with:
The Node.js project has demonstrated the value of providing a travel fund which allows project members to get together at collaborator summits and to represent/advocate for the project at other events. It is important to expand the travel fund (both resource and usage) so that other projects can benefit as well.
There was a problem hiding this comment.
@mcollina is that along the lines of what you were thinking?
There was a problem hiding this comment.
Sounds great! Made the change suggested.
| ## Difference from the current process | ||
|
|
||
| The existing process requires approval from two members of the [Node.js TSC](https://github.com/nodejs/TSC) and two members of the [Node.js Community Committee](https://github.com/nodejs/community-committee). | ||
| The new process will require approval from four members of the CPC. |
There was a problem hiding this comment.
What if the approvals all come from members who do not work on the project which the requester is affiliated with?
Will there be a limit for each project? If there isn't, is it possible that one project may end up using all of the funds, leaving very little for other projects? Or if there is, is it possible that one project may have their limit reached without having their members looking into their own allocations?
There was a problem hiding this comment.
Great questions. Here are my thoughts so far, but others should chime in:
What if the approvals all come from members who do not work on the project which the requester is affiliated with?
That should be fine. All requesters will be somehow affiliated with one of the projects, and the approvals come from members who collectively represent all the projects. Since the CPC is already balanced to not have too much representation from any one project, we shouldn't have to worry about one project having an unbalanced amount of control.
Also, the current wording for the fund outlines the potential for vetoes as well as approvals.
Will there be a limit for each project?
When it comes to allocations per project, I'd like to avoid such a system until it looks like we're going to need one. As of now, the travel fund is predominantly used for Node.js Interactive and Collaborator Summits. The considerations for request approval will not change, so preference will still be given to official OpenJS events such as the collaborator summit. With the fund shared by more people, I can see the budget may need to be raised to pay for more people to attend those events.
is it possible that one project may end up using all of the funds, leaving very little for other projects?
It looks like, among the impact project, only Appium and jQuery have independent events, while the rest of the projects typically host events at large javascript conferences. It is interesting to note that, had a member of Node.js asked for travel funds to attend these events, they would have qualified. If you think it necessary, we could add a clause to the Equity section of the considerations for approval, which could dictate preference given to projects which have not already had members who received funding recently.
Approvals to fund travel to events other than collaborator summits should not be allowed to drain the budget so that at the end of the year, it cannot fund travel to said summits. How is this currently prevented in the current organization of the fund?
There was a problem hiding this comment.
Approvals to fund travel to events other than collaborator summits should not be allowed to drain the budget so that at the end of the year, it cannot fund travel to said summits. How is this currently prevented in the current organization of the fund?
This is currently up to the members of the TSC/CommComm to manage. So far the requests have been limited in number so it has not been hard for the TSC/CommComm to manage that. For a fund serving more projects it might be more complicated...
There was a problem hiding this comment.
It sounds like performing a quick count of the number of members being added here would help in planning for the addition. Would you like me to do that and get some round numbers to help us prepare in an informed way?
There was a problem hiding this comment.
The word "preference" is used in this thread and in the current policy. How is that word defined in this context?
There was a problem hiding this comment.
@Jonahss That sounds great! I think we just need to at least have some numbers to keep the budget under control - they don't even need to be accurate e.g. if we got ~30 estimated trip funding request for the year from the survey, we would not go too far by allocating for 10 or 100.
At least as someone who used to approve these requests from time to time, it's really difficult to tell whether the request that I was reading was going to affect the whole budget or not, unless it was sent after the Interactive near the end of the year. We did a funding survey for the Interactive last year which helped us having an idea about the expected balance and being assured that we were unlikely to need to allocate more from the foundation before the event. It would be very useful if a survey like that can be done before allocating the budget from foundation.
There was a problem hiding this comment.
On a side note, it should be quite helpful if the survey includes questions about whether the requester are up for room-sharing (and any preference about their roommates), as that should cut down the lodging cost significantly compared to people booking the rooms separately. (it would also be nice if they could stay in the same or close hotels as it's safer and gives you more time to socialize with other attendees). But yeah this is just some idea from past experience, not a blocker for the proposal :)
There was a problem hiding this comment.
That's great context, thanks!
Yes I think for the next stage, I'll go out and survey all the projects for their anticipated use of travel funds.
There was a problem hiding this comment.
@joyeecheung good ideas. I think this is a good time to discuss new ideas/ways of doing things. Not that it should block this landing as stage-0, but good to have those ideas discussed as it gets broader discussion and moves to later stages.
There was a problem hiding this comment.
In the next PR, I'll include the documents in question, and then we can review and edit those in the review :)
|
@mcollina @bnb @mhdawson @joyeecheung @Jonahss was an issue ever created in the Admin repo for Node.js to discuss this amongst the TSC and CommComm? Something I'd like to reiterate here is that our reps on the CPC should be checking with their respective groups before arguing for/against these proposals at the CPC level or be very clear they are arguing from a personal perspective and not representing an entire committee. I'm not seeing the issue having been resolved in the Node.js repos, and I don't think it's appropriate for us in Node.js to be overwhelming conversations on the regular in CPC meetings and issues because we haven't consensused on something in the project first. Moving forward, I think @Jonahss did the right thing in requesting we discuss this first and then come back with a unified position. This is especially key when we may be creating more overhead(multiple travel funds administered) or continuing to commit a project to work when the individuals haven't gotten to check in to talk through if they think that's still the best solution. |
|
So far, we've decided to get this proposal to stage-0 in the CPC proposal process, and then create an issue in the Node.js admin repo to solicit more feedback. An issue has not been created there yet. I'm happy with Node.js members participating in this thread, because I don't want to take anybody by surprise or make it seem like we decided tons of stuff without them. Thank you for reminding us all that we're not just stating our opinions, but representing others. So far, there have been a couple comments which resulted in improved language of the proposal and answering questions. The major topics now under discussion seem to be mostly centered around the mechanics of managing the fund for an increased number of potential applicants, and making sure that the summits will still be funded. These discussions are good, but nobody seems to have much issue with the core proposal of moving the fund to the CPC. I propose moving this proposal to stage-0, and adding a section about information gathering on how many people are being added as potential recipients and projections for upcoming summit budgets. We can also get pre-approval for an increased budget from the board once we have the information. We could then use this information in discussions on how to amend the fund mechanics to address the issues stated here. What do people think? |
That's a great question. I don't know. My goal has been just to move the current fund so that it benefits the expanded foundation. People seem interested in updating and more strictly defining the fund since it may be harder to manage with more people using it. I aim to get some more information as to how much it is growing, but once this proposal is accepted as stage-0 and we begin on stage-1, would you be interested in helping with the wording to draft something clearer than the current language?
My reason is that this is the first stage of a 4 stage process. I figured we'd add the actual files to this PR once this initial proposal is discussed. I didn't want to go around rewriting files and whatnot until I knew that that's actually what we wanted. Also I wanted to focus the conversation on the core approach of the move, rather than wording specifics, which we can focus on in the next stage. |
|
@hackygolucky to add to what @Jonahss said in terms of context we discussed in the latest CPC meeting whether we should open those issues now, or land a stage-0 and then open the issues. We went back and forth a bit on it but in the end those in the call agreed to land as stage-0 and then open the issue and include a link to the staging process to help make it clear that at stage-0 it is just at the very early stages of discussion. |
|
+1 for stage-0, thank you @Jonahss ! |
|
Merging. Thanks to everyone involved! This is just the first step ;) I'll submit the PR for promotion to stage-1 today or tomorrow. I'll transfer over many of the conversations we started here but deferred for a later stage, and will @mention all involved. |
|
@mhdawson Yes! Is doing that on the PR for stage-1 all right? |
|
@Jonahss yes, that is what I had in mind. |
|
I would coordinate with @joesepi and open it in https://github.com/nodejs/admin |
Who is the current treasurer? I'd like to @mention them in this review.
Is there anybody else I should specifically solicit for feedback, who may not be subscribed to this repo?
Addresses #172