| 10 Dec 2023 |
 @joepie91:pixie.town | In reply to @artturin:matrix.org
Dunno why that change is so controversial as requiring a github account to contribute is already necessary to respond to this: another goal of the RFC process is to unearth concerns or objections that might not be known yet, from people who would otherwise not assertively speak up. gaining insight into why others might have a problem with something is very much part of it :) | 20:31:51 |
| @joepie91:pixie.town | cc infinisil re: the RFC stuff above | 20:32:15 |
| @joepie91:pixie.town | if you have a moment | 20:32:28 |
| @joepie91:pixie.town | (would like to clear this up so that it doesn't turn into more governance issues down the line) | 20:32:47 |
 Julien | Honestly, the part of the picture that is missing is that RFCs are a very energy draining process that burns out people and take a lot of time to get merged. | 20:33:40 |
| Julien | I understand why one would like to go around this process for changes that feel that they should not be controversial | 20:34:37 |
| @joepie91:pixie.town | to provide a bit of background about the RFC process: it is supposed to be a relatively low-friction / "lightweight" process for gaining community consensus on governance or technical changes that might be controversial or need to take into account diverse perspectives. for a variety of practical reasons it is currently not as low-energy as it should be, however | 20:34:46 |
| @joepie91:pixie.town | (some of these are related to moderation, some of them are simply because there's not much of a culture around it yet, some of it is historical baggage) | 20:35:08 |
| @joepie91:pixie.town | In reply to @julienmalka:matrix.org
I understand why one would like to go around this process for changes that feel that they should not be controversial I understand that as well, but at the same time it's important to acknowledge that top-down management of something is always easier in the short term than community governance; community governance is never the easy option, but that doesn't mean that it's not worth doing | 20:36:04 |
| Julien | We probably have some work to do to improve that process because I don’t think it is « lightweight » in nixpkgs. I don’t have much experience of the RFC process in other community to tell what could be improved in ours | 20:36:23 |
| @joepie91:pixie.town | in the long term it results in a much healthier project | 20:36:29 |
| @joepie91:pixie.town | oh yes, we have a lot to improve, that's for sure | 20:36:37 |
| @joepie91:pixie.town | the problem is that part of that improvement involves practicing with it more, getting more used to it as a community, including for the smaller things | 20:37:06 |
| @joepie91:pixie.town | having it become an integrated part of the process that people commonly understand and engage in, rather than a weird thing off the side that you invoke when you have no other options left | 20:37:35 |
| @joepie91:pixie.town | * having it become an integrated part of the process that people commonly understand and engage in, rather than a weird thing off to the side that you invoke when you have no other options left | 20:37:40 |
| @joepie91:pixie.town | and that also includes passing the 'easy' things through it (which should, in a correctly functioning process, pass without incident) | 20:38:30 |
| Julien | I am all for community governance to be honest, sometimes it’s difficult to draw the line between issues that require community discussion/consensus and issues that a purely short term and technical and that could go forward without an RFC. In that case I think zeuner has a lot of interesting points on how we could improve nixpkgs contributions to be more inclusive but is dealing in bad faith, creating the appearance of the absence of consensus on what should be a trivial decision. | 20:39:10 |
 raitobezarius | In reply to @joepie91:pixie.town
to provide a bit of background about the RFC process: it is supposed to be a relatively low-friction / "lightweight" process for gaining community consensus on governance or technical changes that might be controversial or need to take into account diverse perspectives. for a variety of practical reasons it is currently not as low-energy as it should be, however That was how I believed it was until I had the chance to go through it multiple times | 20:39:13 |
| @joepie91:pixie.town | In reply to @julienmalka:matrix.org
I am all for community governance to be honest, sometimes it’s difficult to draw the line between issues that require community discussion/consensus and issues that a purely short term and technical and that could go forward without an RFC. In that case I think zeuner has a lot of interesting points on how we could improve nixpkgs contributions to be more inclusive but is dealing in bad faith, creating the appearance of the absence of consensus on what should be a trivial decision. ignoring zeuner's tone of comments for a moment, the concerns raised are concerns that I have seen raised multiple times in different venues by people who were definitely acting in good faith | 20:40:00 |
| @joepie91:pixie.town | they are not exclusively zeuner's concerns | 20:40:07 |
| Julien | Are you talking about:
- having people link their github handle on the maintainer-list.nix file
or
- nixpkgs contribution process being heavily dependent of having a github account ?
| 20:41:13 |
| @joepie91:pixie.town | I do agree that it can be difficult to draw the line. but I would argue that it's usually better to err on the side of an RFC; if nothing else, it will provide community practice for RFCs on relatively uncontroversial topics, you might uncover some concerns that you had not previously considered, and as the process matures, the "best case" for such RFCs is nearly indistinguishable in effort/speed from a regular PR (but you will end up with better historical documentation) | 20:42:00 |
| @joepie91:pixie.town | In reply to @julienmalka:matrix.org
Are you talking about:
- having people link their github handle on the maintainer-list.nix file
or
- nixpkgs contribution process being heavily dependent of having a github account ?
the latter; the former is an extension of that | 20:42:17 |
| raitobezarius | joepie91 🏳️🌈: how do you draw the line between nixpkgs contribution process and nixpkgs maintenance process? | 20:42:41 |
| raitobezarius | and how do you see the relation between GitHub being the place where we discuss code changes and many things with the maintenance process? | 20:43:02 |
| @joepie91:pixie.town | raitobezarius: I do not have enough information about the underlying considerations to draw that line; that is where I see value in an RFC that more clearly defines the rationale of how we got to this proposal, and what the considered alternatives were (and why exactly they were not viable) | 20:43:42 |
| @joepie91:pixie.town | * raitobezarius: I do not currently have enough information about the underlying considerations to draw that line; that is where I see value in an RFC that more clearly defines the rationale of how we got to this proposal, and what the considered alternatives were (and why exactly they were not viable) | 20:43:49 |
| @joepie91:pixie.town | I actually just don't know yet whether it is reasonable to expect maintainers to maintain a github presence | 20:44:21 |
| Julien | Okay, sure, I don’t think that anyone is against having a discussion about the second point. The PR is merely saying: for that time that this situation is not changing and given that the metadata is here on the repo, let’s have it in a file that automation tools can parse. | 20:44:30 |
| raitobezarius | In reply to @joepie91:pixie.town
I actually just don't know yet whether it is reasonable to expect maintainers to maintain a github presence Right but not taking a stance on it will just let everyone working daily on nixpkgs take a stance for others | 20:44:57 |
