| 10 Dec 2023 |
 @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 |
| raitobezarius | What you are hinting at to me is something I have been meaning to do for a long time, that is, the maintainer RFC | 20:45:32 |
| raitobezarius | But I don't think current maintainers will appreciate it | 20:45:38 |
| @joepie91:pixie.town | In reply to @julienmalka:matrix.org
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. this is slightly moving the goalposts, though, and that is where much of the conflict comes from - "it is heavily dependent on github" and "you are required on github" are two different things. the former is generally agreed upon, but the latter is up in the air - yet the latter is what is being formalized by this policy | 20:45:38 |
| Julien | 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 But what are the other ways currently to maintain a package ? Unfortunately the PRs/issues workflow is not compatible with not having a github presence. | 20:45:40 |
| @joepie91:pixie.town | In reply to @julienmalka:matrix.org
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. * this is slightly moving the goalposts, though, and that is where much of the conflict comes from - "it is heavily dependent on github" and "you are required to be on github" are two different things. the former is generally agreed upon, but the latter is up in the air - yet the latter is what is being formalized by this policy | 20:45:43 |
| @joepie91:pixie.town | that difference is the source of the disagreement, AIUI | 20:45:56 |
| raitobezarius | In reply to @joepie91:pixie.town
this is slightly moving the goalposts, though, and that is where much of the conflict comes from - "it is heavily dependent on github" and "you are required to be on github" are two different things. the former is generally agreed upon, but the latter is up in the air - yet the latter is what is being formalized by this policy Well let me put it like this | 20:46:18 |
| raitobezarius | Currently, we have a maintainer list with no natural primary key | 20:46:26 |
| raitobezarius | Email, github, github ID, matrix are all optional and only one of them must be present | 20:46:41 |
| raitobezarius | Meaning you cannot order people according to one key (except the attributeset key) | 20:46:54 |
| raitobezarius | Right now, maintainers are not reconcilable, you cannot identify them at all and someone could duplicate themselves by adding an email, a matrix and a github all different in the maintainer list (absurd situation, I admit it) | 20:47:33 |
| raitobezarius | While it doesn't really matter for people consulting this list for doing things or ofborg which just ignores people with no github ID | 20:47:48 |
