Re: Ovirt Community - Becoming a maintainer
(re-sending since I didn't get a reply for it) 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."
Thanks, I'll take a look in a bit once I've solved the current set of go live issues I'm working on Carl. On 09/19/2011 05:01 PM, Doron Fediuck wrote:
(re-sending since I didn't get a reply for it)
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
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."
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.
done.
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
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.
The way you become a maintainer is through contribution. So the document in my view needs to start with contribution to the project. I have added a bit more to that section to make the role it plays clearer. Take a look. The large project section is more like project governance and I agree with you should probably be moved. I'll work on that. Carl.
participants (2)
-
Carl Trieloff -
Doron Fediuck