That was an example idea from before the public discussion, which clearly indicates we should somehow pick up maintenance again. But really my intention was to reflect current reality, as @colemickens pointed out.
It should be both, in my opinion, as the idea is to signal to users and contributors what to expect in terms of code quality, support, and maintenance activity.
This was never brought up as far as I know, and I wouldn’t know why. If someone wrote code is maintaining it, and the proposed working group wants to elevate that project in status, the first step would be asking the code owner if they’re interested in that kind of attention. More visibility often translates to more support requests and contributions to handle.
I think that should simply amount to finding a place for it to live, and that would depend on whether someone is still maintaining it at all.
Benefits would make a lot of sense given that so far more official status only adds responsibilities, and compute time on community infrastructure seems a very reasonable one. I’d support some kind of material benefits as well, and while direct funding through the foundation is probably a long shot at this moment, we could take an example from how the NGI Zero consortium supports their projects with various services to raise overall product quality and success probability. We’ve already been experimenting with and discussed more direct support with grant applications, as a concrete example.
This is a subjective statement of course, but for me it’s things where there’s no evidence of someone involved objecting to the current course taken.
There’s potential for some shifts, and I’d appreciate if there was higher probability that active community members had a higher chance to be aware of all the things they would care about. But I don’t think advertisement would make a substantial difference, because the number of people we’d consider stakeholders will still be limited. The real problem is that for many issues we don’t have a clear definition of who should be asked, and no boundary who should be listened to, so there is always uncertainty, which I think sometimes leads to decisions not being taken although they could be.
Yes, the terminology needs a bit more clarification. Ownership and support are orthogonal concepts, and we need measurable definitions for both in order to set realistic expectations.
Right now there are the NixOS and nix-community GitHub organisations, which are already well-known and are already the best approximation we have to what’s really going on in terms of ownership and support. All I’d like to do is improve that approximation in order to reduce the time and effort required to make best use of the Nix ecosystem and participate in its development effectively.