fricklerhandwerk commented 2 months ago

Description

The NGI0 grant agreements provide the foundation with financial means to sustain its operation. Concretely this amounts to ca. 35 000 EUR just this year, and a total of ca. 120 000 EUR until end of 2026. This money could be invested in maintaining and developing critical code that helps keep the ecosystem afloat.

Judging from experience, the board does not have the time to make spending decisions at that granularity, which would also often involve technical decisions; not even speaking of seeing projects through to the end.

My proposal is to gather projects to be funded from that budget, including people to implement them, and present the board with a big-picture recommendation to sign off. This would happen in a similar manner as it did with the STF proposal in 2023, probably even more transparent because less rushed.

Technically the budget is already in scope of my current responsibilities under the NGI project manager contract, so in principle I could just go ahead and do it. But I'd like to have a clear stance from the board on that issue, since it's a strategic one, and ideally also feedback from the contributor community.

Budget amount

3 000 EUR (from the NGI0 grants)

Budget description

Paid time for me to do the work. We can specify a deadline, a format of the proposal, and other boundary conditions, if the general direction is agreeable.

PS: This effort could also involve planning or already doing some fundraising.

PPS: There is of course a short-cut where we simply divide the money across community teams as proposed in https://github.com/NixOS/teams-collaboration/issues/2

zimbatm commented 2 months ago

If we are starting to receive more grants, it would be good to have a central place where people can make propositions for projects and check which grants are available. Then, have the Nix community team members help pick the candidates. Until then, I think your proposal makes sense to me.

From the board's perspective, it keeps us away from making technical decisions when picking which project is worthwhile or not. On more practical terms, we have to be able to know which project maps to which funds when receiving the invoices.

fricklerhandwerk commented 2 months ago

If we are starting to receive more grants

This is, in my humble opinion, merely a matter of will. Someone has to put in the work, and funding will come. I probably don't have to convince anyone here that there's enough potential. It's only a question of whether we, collectively, want that enough to make it happen.

Janik-Haag commented 2 months ago

The NGI0 grant agreements provide the foundation with financial means to sustain its operation. Concretely this amounts to ca. 35 000 EUR just this year, and a total of ca. 120 000 EUR until end of 2026. This money could be invested in maintaining and developing critical code that helps keep the ecosystem afloat.

This sounds very reasonable to me, there are multiple areas in the project that are figuratively speaking on fire and reaching from just a small dumpster fire to forest fire. Aiding them with funding can be a good way to mitigate those issues.

Judging from experience, the board does not have the time to make spending decisions at that granularity, which would also often involve technical decisions; not even speaking of seeing projects through to the end.

Can you elaborate on the granularity? As far as I know the board just barely gets Project proposals so having an official process for submitting projects would be nice.

My proposal is to gather projects to be funded from that budget, including people to implement them, and present the board with a big-picture recommendation to sign off. This would happen in a similar manner as it did with the STF proposal in 2023, probably even more transparent because less rushed.

Do you have anything in particular in mind for your "big-picture"?

Why would you want to gather the projects and people to do so if we could work on a self-sustaining process that shift's the responsibility of collecting this information to the teams/people interested in getting funding. Another organization where this appears to work well would be the FreeBSD Foundation We can ask teams to rank their proposal by importance and then have the foundation make the call.

Technically the budget is already in scope of my current responsibilities under the NGI project manager contract, so in principle I could just go ahead and do it. But I'd like to have a clear stance from the board on that issue, since it's a strategic one, and ideally also feedback from the contributor community.

If you actually want feedback from the community you have to go and get it, just opening an issue in the foundation repo probably won't do anything. As I already told you with the proposal for #37 if you want involvement, just do a discourse post looking for interested people.

PS: This effort could also involve planning or already doing some fundraising.

On the topic of fundraising we should try to take some inspirations from other Projects like Debian.

CC @refroni since you already had some ideas for fundraising and have it on your priority list. CC @arianvp since you offered some help on that topic in the past

PPS: There is of course a short-cut where we simply divide the money across community teams as proposed in NixOS/teams-collaboration#2

No need for taking short-cut's here since we have enough time to take a cautions decision.

Thinking about this a bit a few Projects that would be interesting to fund:

Hydra frontend

The infra team expressed their interest to rewrite the hydra frontend in Django cleaning up old Perl code and making it easier to maintain. Some discussion on this can be found on matrix in #infra:nixos.org

cc @delroth since you initiated the discussion and are part of the infra team.

Nix source tree modification tool

In nixpkgs doing tree wide changes is a huge pain and doesn't get done as often as it should. I have recently learned about nixq but am unfamiliar how far the development process on it is and what might be potential pain points. It was already used for two nixpkgs prs. 1 2

cc @stuebinm since you are the author of nixq cc @teto since you expressed interest in writing such a tool a while ago in #dev:nixos.org

Ofborg improvements

Ofborg has sever testability issues and some other things. IIRC it was already discussed as a project for STF but since round two didn't happen the project didn't happen either. I assume there already is a fairly concrete proposal for this because of the STF history.

cc @lilyinstarlight

Mod team Code of Conduct (CoC) training

The moderation team has been struggling a lot with member retention and burnout. This is in part due to uncertainty of how to enforce our Code of Conduct and has become more apparent in the light of the sponsorship discussion. An example for such a training would be: https://otter.technology/code-of-conduct-training/ Note that this might also be an interesting coaching for the foundation board itself.

Hardware for releases.nixos.org and ceph hosting

In an effort to reduce the S3 AWS cost it was talked about self-hosting cache.nixos.org There already have been a bunch of discussion around self-hosting and releases.nixos.org would be a good testbed while reducing AWS bandwidth cost.

nixpkgs observability tools

In nixpkgs currently we have the issue of people often repeating work already done by others, e.g. packaging the same thing multiple times. Tools for finding issues and PRs and being able to query them directly would be very helpful here since GitHub's search already isn't the best. And the current search experience will only become worse once we have a merge bot and can't see who merged what which could also be mitigated using a tool like this.

fricklerhandwerk commented 2 months ago

Can you elaborate on the granularity? As far as I know the board just barely gets Project proposals so having an official process for submitting projects would be nice.

I imagine a 3000-5000 EUR granularity, which is larger than event funding, but requires coordination to avoid redundancy and optimise for impact.

Do you have anything in particular in mind for your "big-picture"?

There are multiple avenues, not necessarily mutually exclusive:

Directly fund teams and distribute the responsibility, as proposed in https://github.com/NixOS/teams-collaboration/issues/2
Drive the process of collecting, curating, and coordinating project proposals with stakeholders, and see implementation through to the end
Leverage the budget for fundraising, to enable much bigger projects
Support independent contributors to do their own fundraising
Run around and grease the gears, ensuring that are happening keep happening and stay on track, and help with money where needed

As far as I can tell, that's literally management. But all of that needs to be bootstrapped: to build trust, show that it works, and grow the budget. Because obviously you can't do all of that to an interesting extent, or any of that for prolonged time, with only 3 000 EUR (assuming NGI0 compensation levels in Europe). And we have to think in terms of half-years, considering how long non-trivial changes take to get established in practice.

Strategy-wise I'd focus on securing and driving down the (human) cost of continued maintenance for critical components, as well as improving separation of concerns, so it gets easier to get a handle on what's going on in the ecosystem.

Why would you want to gather the projects and people to do so if we could work on a self-sustaining process that shift's the responsibility of collecting this information to the teams/people interested in getting funding.

I'm all for distributing responsibility, but I don't believe in self-sustaining processes. In my experience, there has to be continuous baseline availability in order to preserve and share organisational knowledge. Otherwise things will peter out or have to be re-learned from scratch over and over. And a large part of organisational knowledge is inevitably tacit, as much as I'd like to make everything explicit and independent of any particular individual. That stuff just takes time and is unexciting work that doesn't look like it creates immediate value.

In any case, even if I'm too pessimistic, such self-sustaining processes have to be grown. My inquiry is about providing the means to do that.

We can ask teams to rank their proposal by importance and then have the foundation make the call.

That would be great. But to be honest, and that's been the premise of the broader discussion for more than a year, I don't see the foundation board having the capacity to make the number of calls that would be necessary to effectively support such activities.

If you actually want feedback from the community you have to go and get it, just opening an issue in the foundation repo probably won't do anything.

In this issue, I'm not asking for community feedback. I'm asking to allocate funding to put in the time to make something of that community feedback. I can't afford volunteering continuous availability over the course of months, and I don't believe all that many people can. Empirically, this work is currently not being done. I'd be glad if it was, then I could focus on other things, so this is why I'm asking in the first place.