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

[Shea Levy]

Hi Michael,

On Jun 26, 2012, at 12:16 PM, Michael Raskin <7c6f434c at mail.ru> wrote:

>> that things can be improved without fracturing the already-small group. 
> 
> 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?

> A small fork will probably only change things that bother 
> someone. Overall, this makes believable that the fork will be able to 
> pull all changes from the remaining project, and the old part will be
> able to pick any changes from the fork that it agrees with.
> 
> I think that all arguments that explain why this exchange will not be
> feasible should be mentioned - this can both uncover different values
> and help to motivate people on keeping the community less split.
> 
>>    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.

>>    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.