[RFC] Minor change to governance document at http://www.xenproject.org/developers/governance.html

[RFC] Minor change to governance document at http://www.xenproject.org/developers/governance.html

[Lars Kurth]

Hi all,

following the recent process to elect new maintainers and committers, 
I would like to suggest the following minor change to our governance 
document. I believe the process we ran recently worked well, so we 
should change the governance accordingly. I don't think we need to 
change the governance to remind the community at least annually of 
the process, but we should use the appointments@ alias, such that 
community members can nominate new committers in private.

Here is the relevant snippet from 
http://www.xenproject.org/developers/governance.html
---
Committer Elections

Developers who have earned the trust of committers in their project 
(including the project lead) can through election be promoted to 
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
can 
[the (including the project lead) makes no sense]

Committer. A two stage mechanism is used

* Nomination: A committers should nominate a community member publicly 
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
              Community members should nominate candidates by posting 
              a proposal to appointments at xenproject dot org                                             

explaining the candidate's contributions to the project and thus why 
they should be elected 

as a maintainer on the project's public mailing list. 

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
to become a Committer of the project.
[Typo: this should have been Committer in the first place]

The nomination should include a project, cite evidence such as patches  
               ^^^^^^^^^^^^^^^^^^^^^^^^^
               should
[the "include a project" makes no sense]
 
and other contributions where the case is not obvious. 
                                                       ^^^^ 
                                                       Existing 
Committers will review all proposals, check whether the nominee 
would be willing to accept the nomination and publish suitable 
nominations on the project's public mailing list for wider 
community input.
                                                                            
---

In the nomination e-mail, we can then use what we used in 
https://www.mail-archive.com/xen-devel@lists.xen.org/msg63365.html
---
== Providing Feedback ==
We are inviting community members to provide comments regarding the 
nomination of <PERSON>. As feedback may be personal and may make 
nominees uncomfortable, we are asking you to provide feedback by 
sending a private mail to appointments at xenproject dot org *before* 
<DATE> (please do *not* CC xen-devel@). 

If you want to congratulate the nominee, it is of course OK to do 
this in public. Please use your judgement and common sense.
---

This is in line with what we have done earlier this month, and seems
to be a better approach than requiring discussions about nominations
to be public from the beginning. Public discussions about a 
candidates track record may necessarily become personal and thus may 
prevent good candidates from being nominated.

Any views?

Best Regards
Lars



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [RFC] Minor change to governance document at http://www.xenproject.org/developers/governance.html

[George Dunlap]

On 26/04/16 12:48, Lars Kurth wrote:
> Hi all,
> 
> following the recent process to elect new maintainers and committers, 
> I would like to suggest the following minor change to our governance 
> document. I believe the process we ran recently worked well, so we 
> should change the governance accordingly. I don't think we need to 
> change the governance to remind the community at least annually of 
> the process, but we should use the appointments@ alias, such that 
> community members can nominate new committers in private.
> 
> Here is the relevant snippet from 
> http://www.xenproject.org/developers/governance.html
> ---
> Committer Elections
> 
> Developers who have earned the trust of committers in their project 
> (including the project lead) can through election be promoted to 
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> can 
> [the (including the project lead) makes no sense]
> 
> Committer. A two stage mechanism is used
> 
> * Nomination: A committers should nominate a community member publicly 
>               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>               Community members should nominate candidates by posting 
>               a proposal to appointments at xenproject dot org                                             
> 
> explaining the candidate's contributions to the project and thus why 
> they should be elected 
> 
> as a maintainer on the project's public mailing list. 
> 
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> to become a Committer of the project.
> [Typo: this should have been Committer in the first place]
> 
> The nomination should include a project, cite evidence such as patches  
>                ^^^^^^^^^^^^^^^^^^^^^^^^^
>                should
> [the "include a project" makes no sense]
>  
> and other contributions where the case is not obvious. 
>                                                        ^^^^ 
>                                                        Existing 
> Committers will review all proposals, check whether the nominee 
> would be willing to accept the nomination and publish suitable 
> nominations on the project's public mailing list for wider 
> community input.
>                                                                             
> ---
> 
> In the nomination e-mail, we can then use what we used in 
> https://www.mail-archive.com/xen-devel@lists.xen.org/msg63365.html
> ---
> == Providing Feedback ==
> We are inviting community members to provide comments regarding the 
> nomination of <PERSON>. As feedback may be personal and may make 
> nominees uncomfortable, we are asking you to provide feedback by 
> sending a private mail to appointments at xenproject dot org *before* 
> <DATE> (please do *not* CC xen-devel@). 
> 
> If you want to congratulate the nominee, it is of course OK to do 
> this in public. Please use your judgement and common sense.
> ---
> 
> This is in line with what we have done earlier this month, and seems
> to be a better approach than requiring discussions about nominations
> to be public from the beginning. Public discussions about a 
> candidates track record may necessarily become personal and thus may 
> prevent good candidates from being nominated.
> 
> Any views?

This all seems reasonable:

Acked-by: George Dunlap <george.dunlap@citrix.com>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [RFC] Minor change to governance document at http://www.xenproject.org/developers/governance.html

[Wei Liu]

On Tue, Apr 26, 2016 at 12:48:41PM +0100, Lars Kurth wrote:
[...]
> Any views?
> 

The modification Looks reasonable to me.

Wei.

> Best Regards
> Lars
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [RFC] Minor change to governance document at http://www.xenproject.org/developers/governance.html

[Konrad Rzeszutek Wilk]

On Tue, Apr 26, 2016 at 12:48:41PM +0100, Lars Kurth wrote:
> Hi all,
> 
> following the recent process to elect new maintainers and committers, 
> I would like to suggest the following minor change to our governance 
> document. I believe the process we ran recently worked well, so we 
> should change the governance accordingly. I don't think we need to 
> change the governance to remind the community at least annually of 
> the process, but we should use the appointments@ alias, such that 
> community members can nominate new committers in private.
> 
> Here is the relevant snippet from 
> http://www.xenproject.org/developers/governance.html
> ---
> Committer Elections
> 
> Developers who have earned the trust of committers in their project 
> (including the project lead) can through election be promoted to 
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> can 
> [the (including the project lead) makes no sense]
> 
> Committer. A two stage mechanism is used
> 
> * Nomination: A committers should nominate a community member publicly 
>               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>               Community members should nominate candidates by posting 
>               a proposal to appointments at xenproject dot org                                             
> 
> explaining the candidate's contributions to the project and thus why 
> they should be elected 
> 
> as a maintainer on the project's public mailing list. 
> 
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> to become a Committer of the project.
> [Typo: this should have been Committer in the first place]
> 
> The nomination should include a project, cite evidence such as patches  
>                ^^^^^^^^^^^^^^^^^^^^^^^^^
>                should
> [the "include a project" makes no sense]
>  
> and other contributions where the case is not obvious. 
>                                                        ^^^^ 
>                                                        Existing 
> Committers will review all proposals, check whether the nominee 
> would be willing to accept the nomination and publish suitable 
> nominations on the project's public mailing list for wider 
> community input.
>                                                                             
> ---
> 
> In the nomination e-mail, we can then use what we used in 
> https://www.mail-archive.com/xen-devel@lists.xen.org/msg63365.html
> ---
> == Providing Feedback ==
> We are inviting community members to provide comments regarding the 
> nomination of <PERSON>. As feedback may be personal and may make 
> nominees uncomfortable, we are asking you to provide feedback by 
> sending a private mail to appointments at xenproject dot org *before* 
> <DATE> (please do *not* CC xen-devel@). 
> 
> If you want to congratulate the nominee, it is of course OK to do 
> this in public. Please use your judgement and common sense.
> ---
> 
> This is in line with what we have done earlier this month, and seems
> to be a better approach than requiring discussions about nominations
> to be public from the beginning. Public discussions about a 
> candidates track record may necessarily become personal and thus may 
> prevent good candidates from being nominated.
> 
> Any views?

Looks good!

> 
> Best Regards
> Lars
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [RFC] Minor change to governance document at http://www.xenproject.org/developers/governance.html

[Lars Kurth]

> On 28 Apr 2016, at 19:26, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> 
>> Any views?
> 
> Looks good!

Alright, I guess there seems to be enough consensus to set up a formal vote.

According to http://www.xenproject.org/governance.html#formal-votes ...

---
Sometimes it is necessary to conduct formal voting within the community (outside of elections). Formal votes are necessary when processes and procedures are introduced or changed, or as part of the Project Governance. Who is eligible to vote, depends on whether the scope of a process or procedure is local to a sub-project or team, or whether it affects all sub-projects (or in other words, is global).
---

... this change affects all mature projects and thus XAPI folks would need to be included. I am going to set this up, but because of the overhead of setting this up, I am wondering whether I should wrap this up with some other changes, which have been discussed before (but not fully in public). Obviously, I will send out separate RFCs (see "Housekeeping list" below).


= Housekeeping list =

On my house-keeping laundry list we have:
* I am also wondering whether we should make explicit our Review-Then-Commit policy, referring to the MAINTAINERS file (or the equivalent for other subprojects).
* Clarifying Lazy Consensus : when, who (taking into account meritocracy) and how plus an example - I recall that because this document was changed iteratively, the lazy consensus part is not clearly explained and it also got mixed up with voting (which was not intentional). This would support the recent changes in the MAINTAINERS file. 
* Changing the voting scale: aka add -2, +2 to the current scale of -1, 0, +1, so 
  +1 : a positive vote
   0 : abstain, have no opinion
  -1 : a negative vote
  would change to
  +2 : I am happy with this proposal, and I will argue for it
  +1 : I am happy with this proposal, but will not argue for it
   0 : I have no opinion
  -1 : I am not happy with this proposal, but will not argue against it
  -2 : I am not happy with this proposal, and I will argue against it
  Right now, we do have a veto model, by which any -1 kills a proposal. The implication of the above is that only a -2 kills a proposal.
  This would fix the issue, where someone wants to record an objection, without blocking a vote.
* Clarify the tallying of formal votes (both local and global), in line with what we have done in the past: 
  a simple majority, if there is no veto. With the introduction of -2, this may need a little bit of thought
  Partly this means moving some text from "Consensus Decision Making" to "Formal Votes"

Regards
Lars




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel