2025 Funding Process Iteration

[steiza]

We are just wrapping up the 2024 OpenSSF Technical Initiative funding process, but we already have many ideas on what we want to see changed for next year (or things we'll at least consider).

For now, this issue will be used to collect those ideas, and then when the 2025 TAC is seated we'll use this input to do an iteration on https://github.com/ossf/tac/blob/main/process/TI%20Funding%20Request%20Process.md and set the 2025 schedule.

[steiza]

Here are some of the suggestions I've heard:

• How can we make the application easier, especially for smaller amounts?

• Can we create a directory of who has provided services to the OpenSSF in the past? Technical writers, UI/UXperts, security audits, writing code, ...

• Can we provide an abstract "menu" listing out types of request (cloud credits, technical writing, security audits, writing code) and link to example applications, and maybe summarize typical amounts and TI lifecycle stage?

• And / or can we create an end of year report of all the things we funded, to help TIs make similar applications in the future?

• How often should the TAC review funding requests? Quarterly again? Every 2 months? Rolling basis?

• Should there be an easier process for a previously approved request to be renewed for another year? This came up with [Technical Initiative Funding Request]: RSTUF Cloud/k8s deployment costs for tests, demo and validations #315 and [Technical Initiative Funding Request]: 2025 RSTUF Cloud/k8s deployment costs for tests, demo and validations #417.

• (EDIT / added) Should we move the application process from issues to pull requests, to be consistent with TI lifecycle updates and TI quarterly updates?

[mlieberman85]

My recommendation would be rolling basis if possible. I think we do so few that having them come up as they need would be fine. If we start to get overwhelmed then I think we can switch to something like quarterly.

[lehors]

• Should there be an easier process for a previously approved request to be renewed for another year?

I don't think the current process is complicated and worth simplifying.

[steiza]

Another item for discussion: how long should the review period be?

I think the 1 week we had for 2024 was too short, especially if folks had business travel or vacation scheduled that week. I would suggest a 2 week review period.

[di]

Would be nice to have some examples of what is/isn't a valid funding request, and how they could be structured. Maybe some previously submitted proposals and the result? Or hypotheticals.

[gkunz]

Would be nice to have some examples of what is/isn't a valid funding request, and how they could be structured. Maybe some previously submitted proposals and the result? Or hypotheticals.

I agree. I believe the current process description doesn't prescribe how exactly the milestones of a funding request are being presented to and reviewed by the TAC, but I would propose to apply the same process as for TI updates to the TAC, i.e., through a summary (markdown) document. These summaries can then ask as guiding examples for new requests.

[steiza]

I believe the current process description doesn't prescribe how exactly the milestones of a funding request are being presented to and reviewed by the TAC, but I would propose to apply the same process as for TI updates to the TAC, i.e., through a summary (markdown) document.

Yes, so I touched on this above with:

• (EDIT / added) Should we move the application process from issues to pull requests, to be consistent with TI lifecycle updates and TI quarterly updates?

Like you mention, TI quarterly updates are done via PRs, which have a nice built-in way to track approvals, allow other people to suggest content or comment on specific content, and you can search for past examples.

Funding requests today are done via Issues. They don't have a built-in way to track approvals, which we work around with comments, emoji reactions, or gitvote. You can comment on an issue but not on a specific line, but like pull requests it's pretty easy to search for past examples.

Conceptually, I like to think of issues as work that's still be scoped out, having implementation discussions, and deciding who will work on it, like we're doing here, and then the result of that work is a pull request that resolves the issue. But I do like how user-friendly the issue template is, and it's easier to fill out in a browser than making a pull request. I don't currently have a strong preference for if funding requests continue to be done via issues or pull requests.

[bobcallaway]

I'm still strongly against moving to rolling proposals. Batching forces us to evaluate and judge comparatively, which is an important function for the TAC.

We have a demand (and potentially awareness) problem with a lack of requestors.

[marcelamelara]

How often should the TAC review funding requests? Quarterly again? Every 2 months? Rolling basis?

Like I've mentioned previously, I have a strong preference for having a fixed review schedule, rather than reviewing on a rolling basis. It allows me to set aside time for reviewing and I think makes TIs scope their requests a bit better as well.

Should we move the application process from issues to pull requests, to be consistent with TI lifecycle updates and TI quarterly updates?

I'm really in favor of moving the funding request process to PRs.

I agree with @bobcallaway that we likely have a lack of awareness about the funding opportunities within TIs. Last year, we posted the dates for all for 2024 in a blog post, but it's unclear how many TI participants were reached. I suggest we focus our advertising of the funding process on Slack and with the help of WG/TI leads.

[steiza]

With #435 we addressed most of the items brought up here that we had rough consensus on - with the exception of moving the funding process from issues to pull requests. It'll be a week or two before I have time to address that item, if someone wants to take that on in the meantime.