Re: [Nix-dev] Nix Policy Documentation
On Fri, 27 Jul 2012 16:02:26 +0200, Florian Friesdorf wrote: > > Hi Shea, > > first of all: thank you very much for getting this started! > > On Tue, 3 Jul 2012 09:13:31 -0400, Shea Levy wrote: > > So now to my first two questions: > > > > 1. Does anyone have any suggestions for other policy documents that I > > could model this work after? > > 2. Which subjects would you like to see covered in the document? > > - How do we support sudo / what is the supported usage of sudo > (currently under discussion). > > - When to create a pull request / when not - common sense with examples. > When to merge a pull request / when to just apply it's patches. > > - Where to put new packages / how is all-packages sorted - How much magic is good / bad in a nix expression and when to generate the nix file using for example a template (see still open discussion) In order to put them somewhere, I would also add a section with items we so far could not achieve consens on, with distilled conflicting opinions. Let me know if I can help. I'd appreciate restructured text as format and a git repo somewhere, but am open for other things. I don't like weird markup syntaxes, most wikis are using. > If some of this is already documented somewhere, I think it should be > moved into a policy document. And thinking of it, the policy document > should be a section of the manual. > > regards > florian > -- > Florian Friesdorf > GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 > Jabber/XMPP: f...@chaoflow.net > IRC: chaoflow on freenode,ircnet,blafasel,OFTC -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgpsli6Avb6WA.pgp Description: PGP signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Nix Policy Documentation
Hi Shea, first of all: thank you very much for getting this started! On Tue, 3 Jul 2012 09:13:31 -0400, Shea Levy wrote: > So now to my first two questions: > > 1. Does anyone have any suggestions for other policy documents that I > could model this work after? > 2. Which subjects would you like to see covered in the document? - How do we support sudo / what is the supported usage of sudo (currently under discussion). - When to create a pull request / when not - common sense with examples. When to merge a pull request / when to just apply it's patches. - Where to put new packages / how is all-packages sorted If some of this is already documented somewhere, I think it should be moved into a policy document. And thinking of it, the policy document should be a section of the manual. regards florian -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgpJptRjGljiq.pgp Description: PGP signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Nix Policy Documentation
Hello, As discussed in the 'improving development experience' thread, I would like to create some documentation about the various policies and procedures relevant to contributing to the nix projects. A few notes: * My efforts are not in any way official. Though I do hope that eventually some descendant of what I'm working on will be adopted, until and unless that happens anything I write should be considered 'advice Shea gives' and not anything more. * The initial goal here is to be descriptive, not prescriptive. I am aiming to document what our policies actually are at this point, not what they could or ought to be. * Policy need not be strict or restrictive. For example, a policy on meta attributes could range from 'put whatever you want there' to 'you must have name, description, and license, and you may optionally have longDescription and maintainer, and here are the values that are allowed for those'. So my desire for clearly-communicated policy should not be construed as a desire to restrict existing freedoms of developers. A comment on methodology: I am fully prepared to do this work alone, yet on many decision points there will be people more qualified than myself to make the choice. In those cases, I will send off an email or chat on IRC, but then continue on anyway according to my best judgment. This allows me to continue without being blocked by others' schedules, and allows those who don't care about this effort to simply ignore it at their leisure. In general, my content decisions will be based on any responses I do get, my experience with discussions on this list, on IRC, etc. and the commit histories of the various nix projects. So now to my first two questions: 1. Does anyone have any suggestions for other policy documents that I could model this work after? 2. Which subjects would you like to see covered in the document? Cheers, Shea ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
