re-send VPN down On 09/09/2011 02:47 PM, Carl Trieloff wrote:

On 09/09/2011 03:43 PM, Anthony Liguori wrote: Go ahead and suggest edits, or make some edits/ comments in the doc and mark them - or e-mail some. My goal here is throw out a good starting point for the docs and have people weigh in. Carl.

On Sunday 11 September 2011 12:11:27 Itamar Heim wrote: 0. Title is missing. I'm guessing it's the same as document name? 1. There's a combined usage of 'project' and 'sub-project'. I suggest using 'project' to simplify it. If you take Apache for example, they host projects, and even real sub-projects (http://db.apache.org/derby/derby_proposal.html) they end up being listed as projects (http://projects.apache.org/indexes/alpha.html#D). 2. The following needs some re-phrasing: IT is expected however that if you have contributed doc, and are not an expect on code that you don’t ack patches for example. You can also be voted into one sub-project and not another based on your area of influence, or you could get into them all. * IT => It * doc => a document? * and are not an expect => and are not an expert? - Generally this paragraph begins with one thing, and ends with something completely different. I'd think of adding each sentence to a relevant paragraph carrying the same theme / subject. 3. There are terms that need clarification, or typos. For example: wsdm. Is it VDSM? Something else? 4. And probably the most important. This document is _also_ about being a maintainer. But it's _also_ about being a (sub-)project contributer (and maybe some more also's); - Contributing to a sub-project - Adding to the discussions and contributing code and there's more contents about giving to the community. This is all relevant to project / community membership. => This document should be spitted into community membership document and (sub-)project maintenance. Currently it's a mix of both. -- /d "Willyoupleasehelpmefixmykeyboard?Thespacebarisbroken!"

On Monday 12 September 2011 21:29:12 Carl Trieloff wrote: <SNIP> OK, looks much better now. Some final (I hope) remarks; 1. We now have 2 "Becoming a maintainer" headers. I'd change the 2nd one to something like "Applying for a project maintainer role" or anything alike. 2. WRT contribution and maintenance mixture, it takes the focus off the document's topic, for no visible reason. I'll try to explain with 2 examples; a. The car You just bought a new car, and you look into the owner manual, looking for a quick & simple way to adjust your radio pre-set stations. You get the information in one chapter which includes the complete wiring scheme, board design and explanation on connector types to use when connecting to amplifiers or phone car-kit. Will you think it's very helpful and easy to understand how you should set your radio buttons? Now think of the mechanic guy in the garage, getting the same manual, which he's supposed to use in order to verify what is short-circuiting the car embedded media controller. What will he think when he needs to read the connector description along with setting radio buttons? Is mixing all the information a good idea? Does it help both guys? Any of them? b. Git Book http://book.git-scm.com/ As you can see there are separate chapters for each type of user; Basic, Intermediate and Advanced. I'm sure someone who looks for a way to recover corrupted objects, won't find git clone syntax very helpful while he looks for the relevant information. 3. Now back to us... I think the following should be used in a different document; - Contributing to a project - Adding to the discussions and contributing code - Large projects These (and maybe some more) should be located in a document focused on general community contribution and oVirt project specific contribution rules / policy / code / coding-conventions, etc. Apache,for instance, asks every contributer to sign something making the code contribution owned by / used by the relevant project, so there are no license / rights issues. This could be a good place for explaining such a signature, should we require one. Current document should be lean and mean; Containing the relevant information on becoming a maintainer, responsibilities, ethics, policies, etc. The document should start by referring to the project contribution document. In this way you give more background if needed. -- /d "All computers wait at the same speed."