New nixpkgs committers requests #50105
Comments
|
Having discussed this on IRC a bit, this is an arbitrary set of requirements I came up with: To become a nixpkgs committer you need:
Of course, a manual check will be involved as well, but having such a set of requirements could set a baseline. |
infinisil
changed the title
|
In addition, a series of interview questions could be asked, such as:
|
|
|
Having discussed this on IRC a bit, this is an arbitrary set of requirements I came up with:
To become a nixpkgs committer you need:
- To have at least 50 merged PR's, 10 of which non-trivial
Do you want to add that of last 20 PRs _submitted_ there shouldn't be major concerns about code quality during review? Controversial changes being rejected are OK, though.
Maybe 50 is slightly too much, and also maybe we want to have some preference about recency (do we want a track record of at least two months? and do we want at least 20 accepted PRs to be less than one year old?)
- To have review at least 20 non-trivial PR's
I have some vague feeling that this is a risky guideline, maybe we just want to lower the number. Basically, we want non-committers to review things where they are already confident, and some part of a person's project participation time should have gone into getting that confidence. Maybe 20 is a large enough number that it looks like we expect people to be a bit more aggressive about what they review. Not sure (as I said, this is a vague feeling).
- To have added at least 2 new packages, to know how to write nix code and package stuff in nixpkgs
I would say explicitly that a notable refactoring of large packages also counts. If there is a place where we can say that we value cleanups, we should say it.
Refactorings are normally reviewed in a stricter way than additions anyway.
- To have written at least 1 NixOS module
Not sure I agree with that — I think having more Nix-on-non-NixOS committers is a good idea. I think just asking people not to touch NixOS modules until they have done some changes via PRs (merged by experienced people) should be OK.
Of course, a manual check will be involved as well, but having such a set of requirements could set a baseline.
I am not sure what would be in the manual check as a separate consideration. Obviously, there are a lot os subjective value calls in the guidelines — non-triviality, reasonableness of reviews, code quality problems in recent commits, etc.
Exceptions from the baseline guidelines are another story, of course.
|
|
Given how things work now, I am not sure what would be a reasonable way to conduct such an interview.
- "Describe the release process, what do you need to look out for during the release time?"
Do many correct answers start with «there is no fixed release process, but generally…»?
Actually, recognition that Nix* is very slow to achieve a consensus on long-term decisions could be a good thing to check…
|
|
A question I don't have a good answer for: should we somehow split up "people who are keeping things up-to-date" vs. "people who we trust to refactor/make sweeping changes"? I'm very much in the set of people that use NixOS, but don't have any strong feelings on how nixpkgs is laid out, what the future direction is, etc., but am happy to submit bugfixes (e.g #47255), closure size reductions (e.g #49315) and security updates (e.g #49859, #49860). I have no immediate interest in doing any refactoring of nixpkgs, but would happily use any additional permissions to continue "just fixing things", like above. |
|
A question I don't have a good answer for: should we somehow split up "people who are keeping things up-to-date" vs. "people who we trust to refactor/make sweeping changes"?
Do we have any project member who hasn't submitted PRs because the changes were indeed global enough to discuss? I doubt that.
I think making and following reasonable estimates of desired review levels for each change is what we target.
|
|
Right, sorry, maybe I’m not being clear here. To be super blunt: y’all
should (rightly) not trust me / people in my situation to submit arbitrary
PRs, but if you could somehow ensure that the only thing we were doing was
updating packages (or other non-controversial/scary changes), maybe it
would take some load off the trusted reviewers and let them review things
that mattered more?
Again: just thinking out loud here, so to speak 🙂
…On Sat, Nov 10, 2018 at 1:54 AM Michael Raskin ***@***.***> wrote:
>A question I don't have a good answer for: should we somehow split up
"people who are keeping things up-to-date" vs. "people who we trust to
refactor/make sweeping changes"?
Do we have any project member who hasn't submitted PRs because the changes
were indeed global enough to discuss? I doubt that.
I think making and following reasonable estimates of desired review levels
for each change is what we target.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#50105 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABB3hSemV6gEn2gSqOxzMkHc5iTli9Grks5utqJtgaJpZM4YXx1N>
.
|
|
|
People with commit access are covering many roles that are more or less evident: they reduce the queue of unmerged PRs but at the same time they ask for or make changes (thus contributing to the overall quality) and most of all they are shaping nixpkgs layout and functionality by boosting or closing some PRs. |
|
At this point we have some people with commit access and, knowing almost nothing of the project history, I can assume they earned it through trust and reputation so there is a process already but it's slow. So are these guidelines a way to measure contributions and speed up the process?
I think these guidelines don't differ much from when many people get commit access nowadays. Having a published set of guidelines would hopefully reduce uncertainty (and maybe even reduce selection for willingness to ask out of the blue — which sometimes holds some people out of the committer list without a good reason).
|
|
I don't know how easy it is to set up on github, but one way to allow less experienced people to help out with pull requests would be to create an intermediate tier of contributors who don't yet have full commit access, but have the ability to give a PR their approval. Once a PR has been approved by two or three of these 'semi-trusted contributors', it can be automatically committed by a bot. |
|
Once a PR has been approved by two or three of these 'semi-trusted contributors', it can be automatically committed by a bot.
I think once ofBorg — https://github.com/NixOS/ofBorg/ — gets some auto-merge support, it will be reasonably easy to add a few kinds of advanced access control logic. There are tickets about that…
|
|
@infinisil thank you for starting this process. I've been wondering for a while what are the requirements for me to gain push access and to be a part of the core team to help out with any refactoring or core decisions. Over the past couple of months, I've submitted a bit over 50 PRs, some are version updates but many are not trivial (such as #47407, #49884 and #49815 among others). I'd love to be the guinea pig of this process. @infinisil @domenkozar please let me know if I would qualify for the minimal requirements and I'd be happy to jump with you (and anyone else from the team) on a call or chat. |
|
Is the team taking names for consideration now? If there is still the desire to find help I wouldn't mind throwing my name into the pool of people interested. |
|
What I would like to know is what members intend to do, that is, what parts of Nixpkgs do they want to work on, and what do they want to be responsible for. The repository is large, and it's close to impossible for anyone to keep up to speed with everything that's happening inside it. While we can add more people to merge changes, and keep adding more packages, there are various bottlenecks that need to be addressed. An important part is also, what are our expectations of Nixpkgs? Aside from the stable releases, many users use Nixpkgs as a rolling release. A rolling release requires far more effort to keep a working package set. I'm hijacking the thread here a bit, but simply saying "we need more people to review and merge" is a bit short-sighted. While I would like to have more people involved, I think it's more important that we come up with a strategy for Nixpkgs, and how we deal with Nixpkgs members is going to depend on and be a part of that strategy. |
|
I think there are a few issues to tackle here, but they are not so much related.
That's a problem we have to solve. So far, to-be maintainers were nominated on IRC and we agreed upon which to give access. I think the process as such is not perfect, but fixing the stated problem is more about making the process of nomination more explicit, known and transparent. I wouldn't impose any kinds of limits how to gain access (I remember how terrible Gentoo process was with this quizz). I think it's better to leave the judgement to existing contributors rather than come up with some unified scheme of scoring that can be gamed.
It's not random, we so far delegated the judgement to existing commmiters and that worked pretty well. I think we need:
A completely different discussion is changing the structure of the current maintainer flat structure into something more organized. |
|
@domenkozar Re: gaming — well, there is also a value in something to help with the impostor syndrome and to suggest to people when it makes sense to self-nominate. Better documentation of expectations from committers is also nice, of course. |
The solution to this is to modularize (split) Nixpkgs. For example, most NixOS modules should be maintained in separate repositories (== "flakes"). Then we don't need to have hundreds of direct committers to a huge mono-repository. Of course this will also scale much better in terms of Nixpkgs download time, evaluation speed/memory use, etc. |
|
(read the bottom of the message first)
The solution to this is to modularize (split) Nixpkgs. For example, most NixOS modules should be maintained in separate repositories (== "flakes").
Of all the problems NixOS has, I don't think maintainership of modules is an issue. IMHO, the main issues are:
- general "unwillingness" to test NixOS changes by the community, some fairly simple changes sometimes take years to merge because nobody is willing merge them untested, but accumulating a critical mass of testing requires years without merging to master where most people will see them
(IMHO, this can only get worse with "flakes", as now you would have to follow and harmonize several distinct repositories to make some high-level feature work.)
- I think the "unwillingness" at least in part stems from poor discoverability of PRs on GitHub, i.e. "How do I find NixOS PRs in a mergeable state that might interest me?"
(IMHO, again, this can only get worse with "flakes".)
(IMHO, Nixpkgs is just too big for GitHub.)
- a particularly important case of discoverability is a mention bot or a similar system that should allow linking between related PRs. Clearly, the most likely parties to be interested in the change are those who made related changes before. It seems strange to me that nobody except me seems to be particularly frustrated by the lack of a mention bot. I got so frustrated that I actually made a similar/related thing myself and will start using it from the next PR I make, just wait :]
I do agree, however, that modularizing in the Linux sense, i.e. multiple repositories with a common tree, is a good idea. Like, for instance, having all package updates go into a separate GitHub repo would be nice. But GitHub, AFAIK, doesn't support that workflow well (like PR numbers would get all messed up between repos by default unless some conscious effort is given to clearly mark them with correct prefixes).
Also, currently it is very hard to subscribe to "common NixOS infrastructure, not any particular service" based just on options and paths, e.g. some services live in "config", some in "hardware", some in other random places. The option names they define are pretty much random. E.g., consider PulseAudio: it lives in "/nixos/config", defines "hardware.pulseaudio", while clearly implementing a service. Cleaning that up would be good.
An immediately applicable measures that, I think, would improve things for NixOS:
- make a "nixos-next" branch (like "staging-next" that should be called just "next") for "should be good, but needs testing" changes, merge it only when all nixos tests pass,
(I would build my laptop against it most of the time, I do that against "staging" and "staging-next" from time to time, `doCheckByDefault` helps with that.)
- cleanup nixos modules so that one could sanely use `configure.nix` options and (even more importantly) repository paths as filters (e.g. for CODEOWNERS) for nixos.
|
|
I don't think NixOS has any shortage of people with commit bits. NixOS organisation has 65 members, plus, the nixpkgs repository has some additional committers that are not members. Looking at the list of members, I don't recall ~half of the names to ever merge a PR I looked at. Out of the remaining "half", a ~half would be mostly working on infrastructure and/or mostly merge their own PR or commit directly (I don't say they are not doing an important job, but in this issue we talk about reviewing PR's). My point is that putting work into reviewing those piles of PR's is not a small endeavour. In my opinion, the people who are willing to do that for free should be valued at a price of gold in the community. It will not be easy to find more people to help with that kind of work. I believe that just increasing number of people with commit privilege is unlikely to help the situation - it was not so effective before and I don't see any indication that it will help in the future. A more effective solution might have to do with improving the nixpkgs infrastructure to improve efficiency and convenience for people who are willing to work on reviewing. I don't know what exactly needs to be done. It could be improving some CI capabilities of @GrahamcOfBorg or adding functionality similar to Rust community's @bors or perhaps even gamifying the process a little bit (e.g. @rust-highfive). |
|
@veprbl The thing is, people might get commit access at some point because they have a lot of time and motivation to contribute, and that is a great help at that time. But times change, people change, they might get inactive or change their field. Those are the inactive people with commit access, most of them contributed well at some point. We also discussed this a bit on IRC on how to fix this: People no longer active in the Nix community should be taken away commit rights after some amount of inactivity. Specifically, after 1 year of not participating in any nixpkgs issues/PRs this could happen, people seemed to agree on this. |
|
@infinisil The number of members doesn't bother me at all and I'm not calling for purges of any kind. That was not my point. I'm just skeptical about your proposed extensive solution to increase the number of maintainers to solve the problem of PR pileup. I think there are some unexplored intensive measures that we could take. |
|
@veprbl Well I'm certainly up for some purging though! I understand what you mean, but I disagree. Let's look at it like this:
I think these 2 questions have long been standing in the way of many people trying to think of becoming an active committer. People don't know what "active" means and whether they are eligible. And people don't know how to ask for commit rights. How did I get commit rights? After asking around a lot on IRC, I got the answer that I should ask @edolstra directly. So I asked him directly in IRC, and he was kind enough to give me these rights. Yes it worked, but it took me way too long to figure this out, and not everybody can figure this out, it's written down nowhere. And yes, as seen in this issue, there are people who want commit rights, I don't think we'll have trouble finding them. On top of my mind, I know that both @worldofpeace and @kalbasit are relatively new community members both helping out a lot (thanks!) and wishing to get commit rights to be able to help out even more, and I'm sure there's more people to come in the future, this project is growing a lot after all! I think this issue should stay a place to discuss how we can make the process of getting new committers easier and more standardized, not whether we should. We need to get new committers, there's no way around it, and this project wouldn't be this far if we didn't add new committers in the past. As a datapoint, @edolstra made me a committer 4 months ago and I merged 236 pull requests since then. I couldn't have helped out this much if I weren't a committer. |
|
Re: splitting the repository: I remember NixOS being in a separate repository. But then some changes needed to be applied to both repos in sync, which lead to eventual migration of NixOS into Nixpkgs repository. I would expect spinning out overlays out of Nixpkgs to cause similar problems. |
|
One of the things that has made Nix appealing to me (and easy to contribute to) so far for me has been that everything lives in one big repository. It means that there is one single directory I can grep through when I'm trying to figure out how something works, and one repository that I can bisect really easily when something has broken. Any time I've tried to figure out how something works on any other free operating system, I've become lost in a sea of repositories, where there's no way to reconcile which revisions match up, and to figure out what was used to build a system. For me, the monorepo has been one of NixOS's biggest strengths. On the topic of new contributors, from my perspective as somebody who hopes to (at some point) become a Nixpkgs committer, and who has previously been one for another large package manager (Homebrew):
I think there's a middle ground between hard rules and giving commit access to random people. In my mind, I see a flow where maybe 1 reviewer notices a person who has been doing a lot of good work, writes up a private post to the other committers about whether it would be a good idea to bring them on board, and then invites them in if there were no real objections after a certain amount of time would be a perfectly healthy way to grow the community that wouldn't be vulnerable to getting caught up in bureaucracy. |
|
One more thing: if commit rights were something that had to be requested, I think that might put people off. "What if I'm rejected?", "What if it's rude to ask, and I should wait until I'm invited?". People can be shy or nervous, and it's important to remember that there is a power imbalance here between the "applicant" and the existing committers that could make asking straight up feel daunting. I think it would be reasonable to assume that anybody with a sustained pattern of contributions would be at least interested in commit rights, and should be offered them when the team thinks it's appropriate. They can always decline. But that way, it's not up to one non-committer to work up the courage to ask. |
|
- "To have review at least 20 non-trivial PR's" – as a non-committer to a free software project, it's often not clear to me whether reviews from non-committers are welcome.
I think right now we don't make it clear enough they are. I think a public document that says we expect new committers to have already reviewed PRs would be a part of making it clear. I have also expressed my doubt about the balance of numbers.
- I would be wary of over-formalising. If you have an entirely numeric public set of benchmarks for when somebody can become (or be considered to become) a contributor, it would be very easy to end up with a situation where there's somebody that the team feels, for whatever reason, wouldn't be a good fit, but has met the benchmarks, and feels that they aren't getting something that they have earned and deserve. On the other hand, those same benchmarks might slow down the process of bringing somebody on board who would unquestionably be an asset.
I do hope that people who are much better than me in writing texts for humans will succeed in positioning guidelines in a proper way. These should eventually be «typical expected experience level around the time of receiving commit access» or something like that.
I do not expect any problems with positive exceptions, although these will probably still take more time than the streamlined main process.
Negative exceptions are harder, of course; in some sense, I expect them to be predictable early in advance (probably before 20 accepted PRs), but no idea what is the best way to handle this proactively.
- When people do get commit access, it would be nice for the community to know a little bit about them. I think it would help build the human connection between everybody working on this software, and would be a really nice welcome for the new person. Maybe a "welcome X to nixpkgs" post on Discourse with a little bit about what work they'd been doing and why the rest of the team decided to offer the commit access.
I feel «welcome X to Nixpkgs» has unfortunate implications about non-committers, more like «welcome X to Nixpkgs committers».
I have an expectation that «why the rest of team has decided» might encourage writing some paragraph in exact same words in almost every post like that.
I think regardless of human connection, knowing who is interested in what technical areas is very useful, and we seem to be beyond the point of being able to keep track of that without technical aids.
I think it would be reasonable to assume that anybody with a sustained pattern of contributions would be at least interested in commit rights, and should be offered them when the team thinks it's appropriate. They can always decline. But that way, it's not up to one non-committer to work up the courage to ask.
On the other hand, if we want the process not to be blocked on the community-focused people in the team having or not having enough time, we need to make sure that asking for commit access is a normal thing that people do (and succeed). I hope guidelines will help with impostor syndrome (if you meet the guidelines, yes you do have enough experience and no nobody can keep track of everything in Nixpkgs anyway). But quietly doing useful work in the neglected corners makes a person harder to notice — and at the same time, it makes the same person valuable in an irreplaceable way.
And people who apply might have an easier time to remember some examples of their less straitforward contributions. Trying to quickly review contributions of many people to find out who has been missed is tiring (I know, I have tried to do that systematically but gave up after doing it a few times and talking a few people into succesfully applying). Keeping notes between the attempts could be helpful, I guess, but then we might end up with a leaderboard for a race towards commit access… Maybe at least a non-public one.
Or maybe joining this with the «interested in …» list could lead to a wiki about community members with areas of current interest and links to recent examples of things people participated in; that could help with both finding people to ask for advice/review, and with looking for people missed by commit access offers.
Basically, every process that requires regular active involvement from existing committers has a risk of stalling, and if we make the default to be «offering the access», people who are missed might think they just need to wait.
|
ghost
mentioned this issue
|
I'm afraid this is not the form of governance I signed on to, folks -- so this is farewell. It has been a great joy and privilege working with all of you. You are elite without being elitist, which is a rare feat. What you've accomplished here is clearly the heir apparent to the Unix philosophy and tradition. The talent density I've encountered here rivals that of Soda Hall and the earliest years of bitcoin-dev. You truly are the best. I have to confess though: I really won't miss having a github account. In fact I'm looking forward to it with great excitement. Now, if you'll excuse me, I'm going to spend a few weeks attending to some very urgent matters. -- amjoseph |
|
welp, the intended effect of the commit removal was to generate a conversation, resolve some of the inter-personal issues and then restore access. clearly, that backfired. respect for making your own path. |
|
I'd like to nominate @corngood. |
|
I'd like to nominate @ambroisie. I haven't come across them before until today but immediately noticed that their review had the thoroughness and quality of someone who should have commit access. PRs (66): https://github.com/NixOS/nixpkgs/pulls?q=is%3Apr+author%3Aambroisie+is%3Aclosed+ |
|
I've participated since August 2023 moderating and answering questions in the unofficial Discord. I also focus on reviewing PRs from newer contributors, hoping to give them a good experience (giving them specific actionable feedback as soon as possible from when they file the PR, as well as showing appreciation for their contributions even when CI gives the big red X or they have unknowingly missed some step per the guidelines). I also make effort to be thorough when I review others' PRs, beyond just building and manually testing, but also keeping an eye out for recent PRs to see if any conventions/guidelines have changed in nixpkgs that I should account for in the reviews. I do of course make PRs myself, but more often I try to encourage others to contribute and make nixpkgs more sustainable and knowledgeable overall. Among the PRs I do make, many are fixing issues reported here or in the Discord (e.g. #282147, #262194, #260665, ...), particularly any issues that I know have affected multiple users, to improve the experience for the regular users as well. The remainder of my PRs are usually cleaning up packages to make it more friendly to automation (adding update scripts, simplifying package expressions, etc.) and/or correcting any issues I myself see (dependency and wrapper issues, build issues, etc.) again to increase the maintainability of the packages in nixpkgs. (I'm also maintainer for >200 packages in the Arch User Repository, which I mention as a lot of the packaging experience I gained there over 2 years was very helpful in quickly identifying and resolving some of the issues I encountered in nixpkgs.) I also contribute some PRs which are outside of the ordinary packaging efforts, in order to prevent some recurring issues/confusion, e.g.:
In the interest of continuing these tasks, as well as positioning myself to contribute to less-attended parts of nixpkgs, I'm nominating myself for merge access. 63 merged PRs and another 16 opened |
|
I want to nominate @katexochen PRs 116 most of them are merged. He has been quite active for the past ~6 Months, he co-organizes the nix learning group in Bochum and he also also dropped a few packages that were archived by upstream or have gone unmaintained which is sadly done too seldomly in nixpkgs. |
|
I'd like to re-apply for commit access. PRs 406 I help maintain k3s, fluxcd, and other related things. |
|
I nominate @leona-ya for the committer role. She has been using Nix/NixOS for multiple years now, started contributing to nixpkgs in 2021, is involved in the community itself and recently started doing some security related work too. Meaning she is familiar with how staging works, backports, is active in matrix, added and maintains packages, modules and tests. I believe she would be a great addition to the nixpkgs committer team :) Usual stats (at the time of writing):
|
|
I nominate @DanielSidhion from the @NixOS/documentation-team, who wants to take ownership of the Nixpkgs manual. He reviewed numerous documentation PRs and is currently working on a consistent style for interface documentation. Examples: |
Does this need a commit bit? Usually, commit bit is given to a contributor with experience in all areas of Nixpkgs, rather than just a single area, otherwise this creates this weird situation where you need to pinky-promise to touch only that particular area (and it's hard for other contributors to know about it). Is there any reason for why an existing committer in the documentation team cannot work with @DanielSidhion and unblock them on their PRs? Is the velocity of the documentation PRs this high and the availability of committers inside the documentation team that low comparatively? |
|
@RaitoBezarius incidentally, I myself live with a Nixpkgs commit bit under the pinky promise. And while @infinisil and me can merge PRs by the team, we direly need more people who can work autonomously and take more responsibility. I understand that there is a tension between lowering the barrier to contribution on the one hand and security considerations on the other hand. With documentation I deem the trade-off biased towards the benefits of lowering barriers. We won't solve all the technical and governance issues underlying that tension here. Ultimately, org owners decide. The only question I have is: What is the process is to resolve the concerns you raised into a timely decision, so we can carry on? |
That's possible, but it's not relevant to the current case here.
It's unclear to me if working autonomously means having people having commit bit in nixpkgs and being able to touch everything at the same time. If that's not the case, I would throw the following idea: a repo for documentation needs where doc team has commit bit and is admin and can assemble large modifications to the documentation and then can synchronize them to nixpkgs.
I'm still unable to understand why
is not sufficient, could you just elaborate about sort of velocity do you need and how many PRs are blocked because you cannot just go on a mergespree on them? Is there a visible backlog of unmerged documentation PRs because not enough committers can click on merge on them? |
This is a bit of polite fiction, there are many cases in this thread where the track record is heavily skewed towards a single, and this is often welcomed as «so we can improve the situation in this area». Of course «all areas» in literal sense is just completely fictional for approximately everyone here, we have too many of areas where specific knowledge of fine upstream details is needed. I would not count @infinisil (mention avoidance intentional) ever in the «merger load» calculations just because of the amount of diverse great work already being done and the implications of splitting attention and often needing to prioritise one area or another. Does @fricklerhandwerk — given the declaration of primary focus on documentation — feel it hard to keep up with all documentation stuff needing review is a relevant question, sure. |
|
Around the issue to trust someone with not enough extensive experience. This can also lead to people rising to the expectation of being a committer. Trusting people who have made contributions can end up making them committed for the long term. |
Those are two separate questions, though: where do we want to aim at vs. where do we actually land and how did we fare in the past. So I am not sure if I see the point you are making by conflating those two.
I agree, and I will clarify it that I didn't mean that in the literal sense.
I disagree, there's no granular permission bit before committer for now, if there was, I would totally agree with you. Because of that, we have to take into account that an extra commit bit is a powerful permission given to a new person and this is totally fine to trust new people, etc. Asking them to do a certain number of actions before becoming committer is not only about showing they excel in all areas (not defined in the literal sense again), but to interact with the community, to work in this social project and show how they fare in working with others. We have past cases of (sometimes ex) committers who had trouble to work with others, this is not a virtual concern. Becoming a committer and prioritizing an area is completely fine too, I don't think I wrote that a committer has to work in all areas, I said that a committer had to touch a bit of all areas, because they have the merge permissions for all areas. I don't see how we can say yes/no to commit bit requests if we have nothing on a person who come and ask for permissions, even if they are vouched. It's not about gatekeeping them, it's about them coming down to say hi to other people. If they cannot/don't want/don't have the time to do that, it is maybe sane to pause the commit bit request and wait until they are willing to do so. This is my personal view of what is advised/recommended/ideal to have nice collaborations with everyone, to share a mutual understanding of what is nixpkgs and not have to collide and bounce with people in PRs/issues all the time for no real reason. |
I want established practices criticised as «we are doing it wrong», not as «usually we don't do it». We are, in fact, doing some things wrong, we seem to have a rare level of agreement there in the project, we just cannot get consensus which ones.
I wonder which share of pairs of committers have crossed their ways (as in interact with the same issue or PR) in the last three months… So from the point of view of «all areas» maybe it doesn't matter as much. Now, I can agree on the object level but from another perspective. Most of the PR reviews were on PRs where the PR left reviewers nothing to say, and given the review count is more on the lower side, this does indeed make the question of track record harder. This is a thing to consider even for the work confined to the documentation. (In reality the track record is not purely within the documentation, by the way) |
I am stating what I am observing, I am not criticizing «we are doing it wrong» because there are many complicated aspects to it and I would feel this unfair and needlessly aggressive. The «we are doing it wrong» can come when we sit down on a table and do some governance and review past events and try to characterize things properly. I don't really like mixing up a single person case and a more global problem in the same discussion, if anything, I would like us to take in consideration the feelings of the people reading us.
Maybe, you could use GitHub API to get some data and write it directly in the answer, so we don't have to speculate or wonder. At least, I know that there's daily interactions between committers, but maybe we are living different experiences, thus I recommend acquiring data.
That seems a particular overfocus of a single thing I said, I don't disagree, but I would imagine this is one particular aspect of the question among so many. |
|
I've been abstaining from the discussion given my obvious bias, but I'd like to address some of what has been said here.
This is already the current state of the world. I'm doing two kinds of work in the documentation team:
The majority of recent PRs to the Nixpkgs manual (both in number and content) have been from me, so considering the current state, giving me commit power will only smooth a small part of the situation that I already described. Speaking about future state: I've volunteered to take ownership of the Nixpkgs manual, and given all the work we plan to do in it, having commit power would allow me to free the rest of the docs team to focus on other things, since I'll have enough power to act on any PRs related to the manual (to quote Valentin, "we direly need more people who can work autonomously and take more responsibility"). I believe that's why @fricklerhandwerk vouched for me.
There is a backlog of unmerged PRs to the Nixpkgs manual that are old enough that they have merge conflicts (unfortunately, some of them were first-time contributors). An aside: there is a non-zero amount of first-time contributors who choose to either fix something in the Nixpkgs manual or add some content to it. Part of my current work provides these contributors with timely feedback, and their PRs are merged somewhat quickly (within ~1 week), so I hope in the long term this helps improve some of the public opinion regarding contributing to the Nix project.
I may not be meeting your expectations of what it means to say hi to other people, but for what it's worth: I usually hang out in the discord server (spent a lot more time socialising there in the past months than in past weeks, but I'd say most of the regulars at least know me), I regularly join docs team meetings, and I keep up with the conversation in some of the matrix channels, voice my opinion and talk to people whenever I think it's appropriate. I'm not a complete stranger to some people, but I'm new enough to the Nix ecosystem that some folks won't know me (yet). Having said that... I am 100% a volunteer, and while I enjoy every bit of social interaction with the folks here, I have limited time I can give to the Nix ecosystem. I choose to spend at least 90% of this time doing work on docs and not socialising, because I think that's the best way I can give value to the ecosystem at the moment. I wish I could spend more time just talking to people too. To clarify: this doesn't mean I'll ignore you or be unfriendly if you come talking to me, but I'll rarely start social interactions with other folks purely for the social aspect of it. I used to do this a lot more often in the past in the discord server, but lately I've been busy with many other things. To address all the comments on inexperience and areas I've touched: I won't waste words trying to show my level of experience or technical knowledge because I think my docs PRs are a good proxy for it already (the majority of the Nix code I've written is for private work, so you won't see a lot of that in my public PRs). I invite you to to compare the documentation of
And if you think this can be done in a timely manner without either extensive technical knowledge, knowledge of Nix or of Nixpkgs, I'd hard disagree with you. During all the time I spent doing this, I also created a bunch of Nixpkgs issues that also show that my level of understanding of both Nix and Nixpkgs is higher than what you possibly think it is. Some examples:
But at the end of the day, I'll keep making PRs to improve the Nixpkgs manual and fix things whenever I can given my time constraints. As I told someone else on the discord server a while ago, I'm not aiming to get commit power, but it would be nice so I can free up some work that has to be done by other docs team members and so I can make the experience of contributing to and reading docs smoother. I think it's nice that @fricklerhandwerk has vouched for me already and I appreciate that, but if there is no current consensus that it's a good idea, I don't mind waiting. |
|
Thanks, Daniel, for writing an intro; it helps us situate you as we are a large community now. I am satisfied and happy to welcome you to the nixpkgs committers (which will happen in our next round of additions). As a general statement, let's provide more context to the people we nominate in the future. And if you see that context missing, avoid making claims based on uncertainty. It's enough to ask for said context. Otherwise, it creates a weird atmosphere, and I'd much rather we assume good intent from everybody. I assume the person nominating is putting their reputation at stake and is responsible for accompanying said nominee. So, the bar for entry can be lowered there (compared to self-nomination). Sometimes, it's nice to make room for new users if you see it could help with the momentum, which I assumed is what @fricklerhandwerk was doing. |
|
Thank you, Jonas. Just want to clarify that I absolutely understand the level of scrutiny given that there's already an established bar for self-nominations and all the implications of adding new committers to the repo. No weird atmosphere, resentments or anything like that on my side. Looking back at it, I should've followed up on the nomination with some more information about me/what I did/what I'm doing, so I agree with providing more context for people we're nominating in the future, even if it's coming from the person being nominated. |
|
Hey all 👋 I'd like to help out with the growing backlog of PRs by becoming a committer. I've been using nix/NixOS for around 18 months, and have had some steady contribution since. A full list of PRs can be seen here, but in summary:
I've been a part of the relatively new I'm not sure if it's relevant, but I maintain my own flake-based nixos-config repo for a few machines here. I've written a few blog articles about Nix on https://jnsgr.uk, including one about using KVM-accelerated VMs for testing my crafts-flake: https://jnsgr.uk/2024/02/nixos-vms-in-github-actions/. There are a few folks here I've both worked with on these things, and met in person including @RaitoBezarius, @JulienMalka, @lheckemann and @flexiondotorg. I'm not sure if this is enough of an "application", but I'm throwing my hat into the ring nonetheless! 🙂 Cheers! Edit by @emilylange:
|
|
Invited @corngood, @ambroisie, @katexochen, @eclairevoyant, @superherointj, @leona-ya, @DanielSidhion, @jnsgruk. This round took a bit longer, life and work is really busy these days. Thank you all for making Nix better and cultivating such a good vibe! PS: I usually wouldn't write this, but since it can provide good funding for the Nix community, I'll make an exception. There's a cryptocurrency providing 3500 USD of "free" money for anyone that contributed more than 3 commits to a repository with 5000 stars. We're collecting the funds, please email domen@cachix.org with instructions on how to help us collect it if you made 3 commits to nixpkgs. |
and others
This issue is used to nominate people for commit rights to Nixpkgs. Use reactions like 👍 or ❤️ to indicate your support of others nominations!
Generally the expectation is to have a well-established PR history already. To see your current stats, you can use @lorenzleutgeb's script to see your merged and reviewed PRs.
Original text
Nixpkgs has an ever growing number of PR's but not enough people to review and merge them. We need more nixpkgs committers! But we can't just select a random bunch of people and give them commit rights. It is a matter of trusting them to keep the codebase clean. People should go through a review process to be able to become a committer. This issue should serve as a place to discuss such a process.https://github.com/orgs/NixOS/teams/nixpkgs-committers/members
The text was updated successfully, but these errors were encountered: