Ovirt Community - Becoming a maintainer

[Carl Trieloff]

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


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.