On 09/09/2011 03:43 PM, Anthony Liguori wrote:

Same general feedback for this document as for the other document. Existing projects have existing procedures for appointing maintainers.

Making these rules optional for established projects or something like that would be necessary if the goal is to make oVirt more inclusive.

I would like to see more projects get brought under the oVirt banner to encourage more cooperation up and down the stack. If you force all projects to conform to one leadership view, that will preclude this from ever happening.

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:

Cc'ing some existing leads for comments

...

-----Original Message----- From: project-planning-bounces@ovirt.org [mailto:project-planning-bounces@ovirt.org] On Behalf Of Carl Trieloff Sent: Friday, September 09, 2011 21:47 PM To: project-planning@ovirt.org; Jim Jagielski Subject: Ovirt Community - Becoming a maintainer

(URL REDACTED - INFO: http://lists.ovirt.org/mailman/project-planning/2011-September/000283.html) _______________________________________________ Project-planning mailing list Project-planning@ovirt.org http://lists.ovirt.org/mailman/listinfo/project-planning

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:

On 09/11/2011 05:16 AM, Doron Fediuck wrote:

...

On Sunday 11 September 2011 12:11:27 Itamar Heim wrote:

...

Cc'ing some existing leads for comments

<SNIP>

...

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

done

...

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.

re-worked, see what you think. (go ahead and edit it directly if needed.)

...

3. There are terms that need clarification, or typos. For example: wsdm. Is it VDSM? Something else?

fixed

...

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.

Don't we want it mixed? why would we draw a line between the two roles? having people thinking of community and code together is healthy.

Carl.

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