For me, the two biggest issues I see are:
a) Lack of clear documentation of policy. The closest thing we have is
the nixpkgs manual, but it's not enough. As a newcomer to a project (and even
sometimes as a veteran), I want to be able to easily find answers to questions
like "how should I format my code?", "should I submit a patch or a pull
request?", "how do I find out who is the person in charge of the bits I'm
touching?", "I have commit access and have made a big change in a branch, how
long should I wait after announcing to merge it?", etc. Of course,
documentation is frustrating to write, always incomplete, and time-consuming to
keep up-to-date, but I think in the long run that effort will be worth it. I'd
be more than happy to write up the docs if I could get some measure of
assurance that those with the authority to approve such documents will be
willing to answer questions I might have about what our policy actually is :)
b) Lack of a way to ensure that issues/contributions/etc. come to some
form of a resolution. Resolution could be "we'll never take this" or "it needs
improvement" or "merged" or "we see the problem but don't have time to fix it
ourselves" or any other number of things, I just want there to be some level of
assurance that if I put the ball in someone else's court it will come back to
me. "no reply is no OK" might work for this, but there have been some times
where it's taken weeks to get a reply so there's no clear sense of when the
final "no" has been delivered. I think one solution to this is to divide the
'responsibility of response' for the various aspects of the NixOS projects to
those who have proven their ability and interest in that area, somewhat akin to
Linux's maintainers. Those accepting such responsibility would be committing to
looking for and responding (or delegating that someone else respond) to
requests in their field in a timely manner (a few days I think),
and such responsibility would be reassigned after several lapses in response.
I think the more divided up this is the easier it will be for everyone
involved, but that requires trusting more and more people with the keys to
various parts of the kingdom. There are numerous reasonable hierarchies that
could be put into place here, and I imagine each individual with some level of
responsibility would be allowed to subdivide it himself how he wants. I'd be
happy to facilitate the dividing (looking through commit histories and
suggesting people to be in charge of various areas) and take on my share of the
response responsibility, again assuming some level of assurance that those with
the ability to actually enact this idea will be willing to take part in the
conversation.
Cheers,
Shea
On Jun 26, 2012, at 10:26 AM, Shea Levy <s...@shealevy.com> wrote:
> Hi all,
>
> It seems apparent to me that many in the community have some level of
> dissatisfaction with how contributions to the various nix projects are
> handled. Sometimes the only solution to problems like this is a fork (as
> Peter seems to believe), but I think there is a good chance that things can
> be improved without fracturing the already-small group. I think three things
> are necessary for this to happen (I apologize for the formatting, I don't
> have access to a well-featured mail app right now):
>
> 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.
>
> 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.
>
> c) Those with the authority to do so need to be willing to make a) and b)
> possible. This doesn't mean anyone who requests permission to make a change
> in how things are done should automatically be given such permission, but
> that any such request needs to at least get some form of consideration from
> someone who has the ability to grant it.
>
> Obviously only a few people have control over c), but the rest of us can and
> should freely do a) and b). So please, if you have concerns respond in this
> thread. Let's try to build the experience we want. I will reply myself with
> my own particular concerns.
>
> Cheers,
> Shea
> _______________________________________________
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
_______________________________________________
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
