[Nix-dev] Improving the Developer Experience in the Nix Community

[Michael Raskin]

>> It looks like the main project will be conservative enough to be simple
>> to pull...
>Are you basing this assessment only on the git situation over the last 6 days, or do you consider the project pre-git to be fairly conservative?

This is based on the recent (couple years) history of the actual project
development, ignoring infrastructure questions.

Git migration (in its full) doesn't make me think that Nix project has 
become radically less conservative. Last 6 days are actually more about
people always being overloaded - so there is an overreaction to 
migration glitches and there is an overreaction to the idea of forking.

>>>    a) Those who have concerns need to explicitly bring them up in a way aimed toward fixing the problem while taking into account the reasons it happened in the first place, rather than trying to place blame. Particularly important here is that people recognize that any change will have a cost and that different people in the project will have different opinions on the relative weighting of the costs and benefits.
>> Unfortunately, after the history with parallel builds I have no idea
>> what happens. I cannot comprehend what values/fears lead to promoting
>> what finally got committed.
>How long ago was that discussion? I don't remember it at all and I've been hanging around nix-dev for around two years now. Maybe things are different now? In any case, I'm not sure one unreasonable outcome should mean that the entire system is irredeemable.

July 2010. It doesn't look that any of the positions have been 
significantly changed, though. 

"No reply is no OK although it is OK to ignore" seems still to be 
acceptable to some and universally bad to others, for example. 

Also, it looks like we all value stability for incompatible definitions
of stability. 

>>>    b) Those who propose alternatives need to be willing to step up and do the work necessary to implement those alternatives themselves. For example, if you think too many emails to the list get dropped with no response, you need to be willing to respond to as many of the emails as possible.
>> 
>> I think it is a bad example - many emails going unreplied are a piece of
>> evidence that we need not to discuss every step. 
>> 
>> So people who say that many ignored email are bad are those very people
>> who say that we don't have to have to reply to everything. Maybe just 
>> try everything and simply keep all unproblematic changes. My personal 
>> pet grudge about gnutls upstream says that probably everything less
>> destructive than GNU TLS update is not too problematic unless someone 
>> explicitly complains.
>> 
>Well, it was just an example. My point was merely that it's not enough to point out a problem, whenever possible you should point out solutions and be willing to do the legwork necessary to implement them.

The real problem is that for many things it does look like the problem
is in value clash. There are people who want less lost patches and more
committing whatever is not too disruptive and there are people who want
more review, but they are objectively overloaded and so sometimes lose
patches and, seemingly, consider rate of loss unfortunate but 
acceptable.