Re: [PATCH] Write up the project governance process

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 02/03/2014 11:30 AM, Daniel P. Berrange wrote:
> The project has historically operated as a meritocratic
> consensus based community. Formally document what has
> always been an unwritten assumption amongst the community
> participants. Also include an explicit code of conduct
> to prempt any potential, but unlikely, future problems.

s/prempt/preempt/ (I've also seen pre-empt, but the - bothers me).

> 
> Signed-off-by: Daniel P. Berrange <berrange@xxxxxxxxxx>
> ---
>  docs/governance.html.in | 292 ++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 292 insertions(+)
>  create mode 100644 docs/governance.html.in

Very nice!

> +      code of conduct. At a high level the code can be summarized as
> +      <em>"be excellant to each other"</em>. Expanding on this 

trailing whitespace
s/excellant/excellent/

> +        on other community members and the project as a whole, so take potential
> +        consequences into account before persuing a course of action.</li>

s/persuing/pursuing/

> +        media postings, video blogs, user group / conference presentations
> +        and any other method of diseminating information</li>

s/diseminating/disseminating/

> +      <li>User help: join the IRC channel or mailing list to assist or advice
> +        other users in troubleshooting the problems they face.</li>

Here would be an ideal place to add <a href...> pointing to the contact
page, so someone can actually find the IRC channel or list :)

> +      <li>Code review: look at patches which are submitted and critique
> +        the code to identify bugs, potential design problems or other
> +        issues which should be addressed before the code is accepted</li>

Maybe even mention that merely testing a build with the proposed patch
applied, without actually understanding the code, is also a valid form
of review.

> +      they provide on other contributors' submissions and a demonstration that
> +      they understand day-to-day operation of the projet and its goals. There

s/projet/project/

> +      There are no special requirements to becoming a committer other than to
> +      have shown a willingness and ability to contribute to the project over
> +      an extended period of time. Proposals for elevating contributors to
> +      committers are typically made by existing comitters, though contributors

s/comitters/committers/

> +      software. The subset of project committers is chosen to be the
> +      minimal size neccessary to provide expertise spanning most of

s/neccessary/necessary/

ACK with fixes.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]