| 8 Dec 2024 |
 KFears (annoying) | But if we see Lix as a "community project", it sucks to get a somewhat silent treatment and be unable to participate in the project if you want to | 00:42:51 |
| KFears (annoying) | I'm a "community project"-minded person, and that must be why I feel rejected. I have a lot of ideas on a community part, but expressing any of them is useless at best and hurtful at worst if my vision about the project is fundamentally incorrect | 00:45:37 |
| KFears (annoying) | So at the risk of sounding bossy and insensitive, I'd like to urge Lix Core team to consider the question of which community they want to be a part in deeply. Thank you | 00:47:53 |
| KFears (annoying) | * So at the risk of sounding bossy and insensitive, I'd like to urge Lix Core team to consider the question of which community they want to be a part of deeply. Thank you | 00:49:10 |
| KFears (annoying) | (to be clear, I think the two approaches are compatible when an org structure is is made with that in mind, but this still plays to the "community project" side a decent part, and that by itself might be uncomfortable to members) | 00:50:56 |
| KFears (annoying) | (also, if I am spot-on on the problem, then this kind of uncomfortable discussion will happen again and again until resolved, so it's best to handle it sooner rather than later) | 01:00:51 |
 piegames | In reply to @raitobezarius:matrix.org
I am not so sure; there's obviously plenty to do and always not enough time but landing things takes time especially if we want them to be mature, etc. Given the current topics, I'd argue that the movement speed is satisfying (possibly maximum?).
Once we are out of the woods with respect to the immense technical debt that CppNix accrued, that's certainly another discussion
Of course, in the meantime, there's a bunch of org debt that we have (governance, infra, etc.) and it'd be great to have more hands on this I'm maybe less complaining about movement speed here, and more about sustainable energy consumption. I feel like the current refactorings would be better distributed onto more shoulders | 07:38:08 |
| piegames | So what I'd like to see is more active efforts to onboard and recruit new contributors, and at least for the few areas of libexpr I feel comfortable with I offer to do so myself | 07:39:50 |
| piegames | (So anybody hmu if you're good at touching software and want to work on the evaluator or nix-lang2 experiments) | 07:40:43 |
 Irenes | code is good. I can do code. I am good at language stuff, if you want to give me tasks. I had been under the impression the state of the CI tooling was still such that it's too dangerous to try that. | 08:35:45 |
 V. 🏳️⚧️ | I find the codebase makes it very difficult to reason about the impact of any changes I might want to make, however small, which is why I haven't contributed much despite wanting to | 09:11:32 |
| piegames | So one reasonable but non-trivial task in libexpr for example would be to track spans instead of positions for all expressions. That's mostly a mechanical refactoring. The second and harder step then is to figure out how to use that information to improve error messages | 09:16:54 |
| Irenes | oooh right, spans | 09:18:33 |
| piegames | The only issue I see is that we should have a reasonable idea about the second step, or else the position information will regress between the two (because for example we currently point at the operator within an expression and if we have a span that gets lost initially) | 09:20:39 |
| piegames | Other small refactoring tasks that need to be done is to remove the symbol structs from parser and evaluator and move them directly into the symbol table, or to split some expressions like ExprConcatStrings or the prelude of function application | 09:24:51 |
| Irenes | I see | 09:26:08 |
 raitobezarius | In reply to @piegames:flausch.social
I'm maybe less complaining about movement speed here, and more about sustainable energy consumption. I feel like the current refactorings would be better distributed onto more shoulders I understand your point but I wonder if taking the energy to onboard new contributors + review is not going to be higher than conducting those refactors, there's areas where this is possible and areas it's blocked on sufficient background and experience to produce the safe code
And I guess I am focusing my energy on trying to keep up with all the open CLs, triaging them, ensuring we don't miss easy ones, when it comes to active onboarding ; tutoring newcomers would be nice but I think my strategy is to wait for the codebase to leave its state of "you need a borrow checker in your mind to write a single line of code across libstore etc.", maybe for libexpr, the situation is different, I don't look at it much beyond enjoying your CL chains :p | 09:27:00 |
| raitobezarius | Either way I am open to how we can try to advertise onboardings on specific areas and we want help :) | 09:28:02 |
| piegames | Libstore is probably extremely bad, but in libexpr with the mentoring of horrors I got into a state where I can make refactorings on my own in under four months. Ask them if it was a net positive time investment I guess :) | 09:29:32 |
 delroth | to be completely honest, from the point of view of someone who tried contributing a few months ago and bounced: there are some glaring problems in terms of collaboration / communication within this project, and frankly I feel like it's difficult to provide any more meaningful feedback because it also feels to me like the state of the project is so fragile that having any discussion about this publicly has a 50-50 of causing a random prolific project member to burn out and quit (plus, is it really my place?) | 09:34:01 |
| raitobezarius | I agree and I do not see any good solutions until the overwork situation decreases and we can dilute enough responsibilities (release engineering, etc.) so that we stop putting prolific project members into risky situations for themselves | 09:40:16 |
| Irenes | against my better judgement I reiterate that the overwork situation is the result of the communication debacle and that waiting for overwork to be resolved before thinking about communication is a death spiral | 09:42:07 |
| Irenes | but I've said this many times before and I have no more reason to think it will get through than I ever have | 09:42:22 |
| Irenes | I'm trying hard to not care and step back, but like, the nixos bridges are pretty thoroughly burned, we all stand to lose a lot if this doesn't pan out | 09:43:06 |
| Irenes | to put it even more bluntly, trying to solve everything alone is self-defeating | 09:44:01 |
| piegames | That's why I'm thinking about onboarding and mentoring. Because I don't see how powering through an overwork situation can end well, and it's a better investment of time to get people onboard despite the difficulties | 09:46:45 |
| piegames | I'd be curious to hear about details on this, to better understaand which parts of the code base suffer more than others from this | 11:24:19 |
| piegames | Also one thing which can be done which is not cursed C++ for once is to look at the functional2 test runner. Probably the solution is to write our own test runner (Python or not) or to find another one which doesn't scare itself when run with more than 1 thread … | 11:52:24 |
| piegames | * In terms of intro-level tasks, one other thing which can be done which is not cursed C++ for once is to look at the functional2 test runner. Probably the solution is to write our own test runner (Python or not) or to find another one which doesn't scare itself when run with more than 1 thread … | 11:53:16 |
| piegames | I'm bad at keeping issue trackers up to date and tagging them well, but I can throw stuff to do in a channel for interested people to pick up | 11:53:41 |
