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

[Lluís Batlle i Rossell]

On Wed, Jun 27, 2012 at 04:32:33PM +0200, Petr Rockai wrote:
> Shea Levy <shea at shealevy.com> writes:
> > That's why I opened this thread, because we have people with different
> > values but no one is really coming out and saying "this is what I
> > want, this is why what's here now is bad".
> 
> I am more or less a bystander and not really active, but this caught my
> attention (and the thread above). Above all, the main reason I am not
> active is that it seems that submitting patches is a hit-or-miss
> affair. They tend to get blackholed about as often as not. So I don't
> submit any: I just locally fork any package that I need to change, and
> in addition I keep a number of extra packages that way; basically, I
> maintain a private overlay in /etc/nixos.
> 
> Now if there was a simple and documented way to submit patches
> (*especially* new packages) that would actually work, it would probably
> make my life easier, even as a bystander, by reducing the size of the
> overlay significantly.

Well, I think that in SVN, it was easier for those who got commit access to
put any change into the common repository, than to keep it apart.

With the movement to git, I think it's easier than before to keep an independant
fork. Thus there should be more incentives to put the changes in common (easy
commit access, reply to patches submitted, thanking and encouraging
contributions by social dialog, ...), or more people will keep their work apart
just to lower the effort.

I think there should also be some some patch quality driven by example, too.
For example, a committer should not be required to submit with
'longDescription', if current committers don't add longDescription in their
commits (and other similar cases). The previous commits done by the usual
committers should be an indication of the quality expected by those in the
commiters round. I've the impression we have required to non-committers far more
than what usual comitters do, making them rework their patches. This makes usual
comitters look like people with some arbitrary advantage, not based on commit
quality.

And by commit quality I don't mean whether patches have a longDescription or
not; it's about the usefulness of the commits to the rest of the community. So,
a measure hard to describe by following guidelines alone.

Regards,
Lluís.