On 09/11/2011 05:16 AM, Doron Fediuck 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
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).
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.