Informal voting proposal

Informal voting proposal

[Kelly Choi]

[-- Attachment #1: Type: text/plain, Size: 2368 bytes --]

Hi all,

As an open-source community, there will always be differences of opinion in
approaches and the way we think. It is imperative, however, that we view
this diversity as a source of strength rather than a hindrance.

Recent deliberations within our project have led to certain matters being
put on hold due to an inability to reach a consensus. While formal voting
procedures serve their purpose, they can be time-consuming and may not
always lead to meaningful progress.

Having received agreement from a few maintainers already, I would like to
propose the following:

*Informal voting method:*

   1. Each project should ideally have more than 2 maintainers to
   facilitate impartial discussions. Projects lacking this configuration will
   be addressed at a later stage.
   2. Anyone in the community is welcome to voice their opinions, ideas,
   and concerns about any patch or contribution.
   3. If members cannot agree, the majority informal vote of the
   maintainers will be the decision that stands. For instance, if, after
   careful consideration of all suggestions and concerns, 2 out of 3
   maintainers endorse a solution within the x86 subsystem, it shall be the
   decision we move forward with.
   4. Naturally, there may be exceptional circumstances, as such, a formal
   vote may be warranted but should happen only a few times a year for serious
   cases only.
   5. Informal votes can be as easy as 2 out of 3 maintainers providing
   their Acked-by/Reviewed-by tag. Alternatively, Maintainers can call an
   informal vote by simply emailing the thread with "informal vote proposed,
   option 1 and option 2."
   6. *All maintainers should reply with their vote within 5 working days.*

   7. Please note that with any new process, there will always be room for
   improvement and we will reiterate where needed.

Ultimately our goal here is to prevent the project coming to a standstill
while deliberating decisions that we all cannot agree on. This may mean
compromising in the short term but I am sure the long-term benefits will
stand for themselves.

*If you have any strong objections to the informal voting, please let me
know by 30th November 2023. *
*Should I receive no objections, the process will be implemented as of 1st
December 2023.*

Many thanks,
Kelly Choi

Open Source Community Manager
XenServer, Cloud Software Group

[-- Attachment #2: Type: text/html, Size: 2893 bytes --]

Re: Informal voting proposal

[Julien Grall]

Hi Kelly,

On 06/11/2023 16:40, Kelly Choi wrote:
> Hi all,
> 
> As an open-source community, there will always be differences of opinion in
> approaches and the way we think. It is imperative, however, that we view
> this diversity as a source of strength rather than a hindrance.
> 
> Recent deliberations within our project have led to certain matters being
> put on hold due to an inability to reach a consensus. While formal voting
> procedures serve their purpose, they can be time-consuming and may not
> always lead to meaningful progress.
> 
> Having received agreement from a few maintainers already, I would like to
> propose the following:

Thanks for the sending the proposal. While I like the idea of informal 
vote to move faster, I would like to ask some clarifications.

> 
> *Informal voting method:*
> 
>     1. Each project should ideally have more than 2 maintainers to
>     facilitate impartial discussions. Projects lacking this configuration will
>     be addressed at a later stage.
>     2. Anyone in the community is welcome to voice their opinions, ideas,
>     and concerns about any patch or contribution.
>     3. If members cannot agree, the majority informal vote of the
>     maintainers will be the decision that stands. For instance, if, after
>     careful consideration of all suggestions and concerns, 2 out of 3
>     maintainers endorse a solution within the x86 subsystem, it shall be the
>     decision we move forward with.

How do you know that all the options have been carefully considered?

>     4. Naturally, there may be exceptional circumstances, as such, a formal
>     vote may be warranted but should happen only a few times a year for serious
>     cases only.
Similarly here, you are suggesting that a formal vote can be called. But 
it is not super clear what would be the condition it could be used and 
how it can be called.

For instance, per the informal rule, if 2 out of 3 maintainers accept. 
Then it would be sensible for the patch to be merged as soon as the 5 
days windows is closed. Yet the 3rd maintainer technically object it. So 
could that maintainer request a formal vote? If so, how long do they have?

>     5. Informal votes can be as easy as 2 out of 3 maintainers providing
>     their Acked-by/Reviewed-by tag. Alternatively, Maintainers can call an
>     informal vote by simply emailing the thread with "informal vote proposed,
>     option 1 and option 2."
>     6. *All maintainers should reply with their vote within 5 working days.*

While I understand we want to move fast, this means that a maintainer 
that is away for PTO would not have the opportunity to answer.

Cheers,

-- 
Julien Grall

Re: Informal voting proposal

[Stefano Stabellini]

On Mon, 6 Nov 2023, Julien Grall wrote:
> Hi Kelly,
> 
> On 06/11/2023 16:40, Kelly Choi wrote:
> > Hi all,
> > 
> > As an open-source community, there will always be differences of opinion in
> > approaches and the way we think. It is imperative, however, that we view
> > this diversity as a source of strength rather than a hindrance.
> > 
> > Recent deliberations within our project have led to certain matters being
> > put on hold due to an inability to reach a consensus. While formal voting
> > procedures serve their purpose, they can be time-consuming and may not
> > always lead to meaningful progress.
> > 
> > Having received agreement from a few maintainers already, I would like to
> > propose the following:
> 
> Thanks for the sending the proposal. While I like the idea of informal vote to
> move faster, I would like to ask some clarifications.
>
> > *Informal voting method:*
> > 
> >     1. Each project should ideally have more than 2 maintainers to
> >     facilitate impartial discussions. Projects lacking this configuration
> > will
> >     be addressed at a later stage.
> >     2. Anyone in the community is welcome to voice their opinions, ideas,
> >     and concerns about any patch or contribution.
> >     3. If members cannot agree, the majority informal vote of the
> >     maintainers will be the decision that stands. For instance, if, after
> >     careful consideration of all suggestions and concerns, 2 out of 3
> >     maintainers endorse a solution within the x86 subsystem, it shall be the
> >     decision we move forward with.
> 
> How do you know that all the options have been carefully considered?

I don't think there is a hard rule on this. We follow the discussion on
the list the same way as we do today.

While I like the informal vote proposal and effectively we have already
been following it in many areas of the project, I don't think we should
change the current processes from that point of view.


> >     4. Naturally, there may be exceptional circumstances, as such, a formal
> >     vote may be warranted but should happen only a few times a year for
> > serious
> >     cases only.
> Similarly here, you are suggesting that a formal vote can be called. But it is
> not super clear what would be the condition it could be used and how it can be
> called.

The formal vote is basically the same we already have today. It would
follow the existing voting rules and guidelines already part of the
governance.


> For instance, per the informal rule, if 2 out of 3 maintainers accept. Then it
> would be sensible for the patch to be merged as soon as the 5 days windows is
> closed. Yet the 3rd maintainer technically object it. So could that maintainer
> request a formal vote? If so, how long do they have?

It is difficult to write down a process that works in all cases, and if
we did it would probably end up being slower rather than faster.

In my view if someone doesn't agree with his other co-maintainers and he
is outvoted (e.g. 2/3 of the maintainers prefer a different option), the
individual is entitled to raise a request for a vote with the
committers, which is the same as we already have today.

Ideally a formal vote would be rare, maybe once or twice a year, so I
hope we won't need to optimize the formal vote.


> >     5. Informal votes can be as easy as 2 out of 3 maintainers providing
> >     their Acked-by/Reviewed-by tag. Alternatively, Maintainers can call an
> >     informal vote by simply emailing the thread with "informal vote
> > proposed,
> >     option 1 and option 2."
> >     6. *All maintainers should reply with their vote within 5 working days.*
> 
> While I understand we want to move fast, this means that a maintainer that is
> away for PTO would not have the opportunity to answer.

PTO is a bit of a special case because we typically know when one of the
maintainers is on PTO. If it is a short PTO and if the vacationing
maintainer could have a strong opinion on the subject then it would make
sense to wait. If it is a long leave of absence (several weeks or
months) then I don't think we can wait.

So I think the 5 working days is OK as a rule of thumb, but of course it
shouldn't be used to work around objections of a maintainer by waiting
for him to go on holiday :-)

Re: Informal voting proposal

[Julien Grall]

Hi Stefano,

On 07/11/2023 04:18, Stefano Stabellini wrote:
> On Mon, 6 Nov 2023, Julien Grall wrote:
>> Hi Kelly,
>>
>> On 06/11/2023 16:40, Kelly Choi wrote:
>>> Hi all,
>>>
>>> As an open-source community, there will always be differences of opinion in
>>> approaches and the way we think. It is imperative, however, that we view
>>> this diversity as a source of strength rather than a hindrance.
>>>
>>> Recent deliberations within our project have led to certain matters being
>>> put on hold due to an inability to reach a consensus. While formal voting
>>> procedures serve their purpose, they can be time-consuming and may not
>>> always lead to meaningful progress.
>>>
>>> Having received agreement from a few maintainers already, I would like to
>>> propose the following:
>>
>> Thanks for the sending the proposal. While I like the idea of informal vote to
>> move faster, I would like to ask some clarifications.
>>
>>> *Informal voting method:*
>>>
>>>      1. Each project should ideally have more than 2 maintainers to
>>>      facilitate impartial discussions. Projects lacking this configuration
>>> will
>>>      be addressed at a later stage.
>>>      2. Anyone in the community is welcome to voice their opinions, ideas,
>>>      and concerns about any patch or contribution.
>>>      3. If members cannot agree, the majority informal vote of the
>>>      maintainers will be the decision that stands. For instance, if, after
>>>      careful consideration of all suggestions and concerns, 2 out of 3
>>>      maintainers endorse a solution within the x86 subsystem, it shall be the
>>>      decision we move forward with.
>>
>> How do you know that all the options have been carefully considered?
> 
> I don't think there is a hard rule on this. We follow the discussion on > the list the same way as we do today.

To me the fact we need to write down the informal rules means that 
something already gone wrong before. So I feel that rules should be 
unambiguous to avoid any problem afterwards.

> 
> While I like the informal vote proposal and effectively we have already
> been following it in many areas of the project, I don't think we should
> change the current processes from that point of view.

I am confused. Are you suggesting that we should not write down how 
informal votes works?

> 
> 
>>>      4. Naturally, there may be exceptional circumstances, as such, a formal
>>>      vote may be warranted but should happen only a few times a year for
>>> serious
>>>      cases only.
>> Similarly here, you are suggesting that a formal vote can be called. But it is
>> not super clear what would be the condition it could be used and how it can be
>> called.
> 
> The formal vote is basically the same we already have today. It would
> follow the existing voting rules and guidelines already part of the
> governance.

Reading through the governance, I couldn't find anywhere indicating in 
which condition the formal votes can be triggered. Hence my question here.

>> For instance, per the informal rule, if 2 out of 3 maintainers accept. Then it
>> would be sensible for the patch to be merged as soon as the 5 days windows is
>> closed. Yet the 3rd maintainer technically object it. So could that maintainer
>> request a formal vote? If so, how long do they have?
> 
> It is difficult to write down a process that works in all cases, and if
> we did it would probably end up being slower rather than faster.
> 
> In my view if someone doesn't agree with his other co-maintainers and he
> is outvoted (e.g. 2/3 of the maintainers prefer a different option), the
> individual is entitled to raise a request for a vote with the
> committers, which is the same as we already have today.
> 
> Ideally a formal vote would be rare, maybe once or twice a year, so I
> hope we won't need to optimize the formal vote.

Ok. So the expectation is that all the maintainers will accept the 
informal votes in the majority of the cases. If this is not the case, 
then we will revise the rules. Is that correct?

>>>      5. Informal votes can be as easy as 2 out of 3 maintainers providing
>>>      their Acked-by/Reviewed-by tag. Alternatively, Maintainers can call an
>>>      informal vote by simply emailing the thread with "informal vote
>>> proposed,
>>>      option 1 and option 2."
>>>      6. *All maintainers should reply with their vote within 5 working days.*
>>
>> While I understand we want to move fast, this means that a maintainer that is
>> away for PTO would not have the opportunity to answer.
> 
> PTO is a bit of a special case because we typically know when one of the
> maintainers is on PTO. If it is a short PTO and if the vacationing
> maintainer could have a strong opinion on the subject then it would make
> sense to wait. If it is a long leave of absence (several weeks or
> months) then I don't think we can wait.
> 
> So I think the 5 working days is OK as a rule of thumb, but of course it
> shouldn't be used to work around objections of a maintainer by waiting
> for him to go on holiday :-)

Well... It has been done before ;). That's why I think it is important 
to write down because at least it is not left to interpretation.

Cheers,

-- 
Julien Grall

Re: Informal voting proposal

[Kelly Choi]

[-- Attachment #1: Type: text/plain, Size: 7758 bytes --]

Thanks for the feedback Julien, see my reply below.

Many thanks,
Kelly Choi

Open Source Community Manager
XenServer, Cloud Software Group


On Tue, Nov 7, 2023 at 8:23 AM Julien Grall <julien@xen.org> wrote:

> Hi Stefano,
>
> On 07/11/2023 04:18, Stefano Stabellini wrote:
> > On Mon, 6 Nov 2023, Julien Grall wrote:
> >> Hi Kelly,
> >>
> >> On 06/11/2023 16:40, Kelly Choi wrote:
> >>> Hi all,
> >>>
> >>> As an open-source community, there will always be differences of
> opinion in
> >>> approaches and the way we think. It is imperative, however, that we
> view
> >>> this diversity as a source of strength rather than a hindrance.
> >>>
> >>> Recent deliberations within our project have led to certain matters
> being
> >>> put on hold due to an inability to reach a consensus. While formal
> voting
> >>> procedures serve their purpose, they can be time-consuming and may not
> >>> always lead to meaningful progress.
> >>>
> >>> Having received agreement from a few maintainers already, I would like
> to
> >>> propose the following:
> >>
> >> Thanks for the sending the proposal. While I like the idea of informal
> vote to
> >> move faster, I would like to ask some clarifications.
> >>
> >>> *Informal voting method:*
> >>>
> >>>      1. Each project should ideally have more than 2 maintainers to
> >>>      facilitate impartial discussions. Projects lacking this
> configuration
> >>> will
> >>>      be addressed at a later stage.
> >>>      2. Anyone in the community is welcome to voice their opinions,
> ideas,
> >>>      and concerns about any patch or contribution.
> >>>      3. If members cannot agree, the majority informal vote of the
> >>>      maintainers will be the decision that stands. For instance, if,
> after
> >>>      careful consideration of all suggestions and concerns, 2 out of 3
> >>>      maintainers endorse a solution within the x86 subsystem, it shall
> be the
> >>>      decision we move forward with.
> >>
> >> How do you know that all the options have been carefully considered?
> >
> > I don't think there is a hard rule on this. We follow the discussion on
> > the list the same way as we do today.
>
> To me the fact we need to write down the informal rules means that
> something already gone wrong before. So I feel that rules should be
> unambiguous to avoid any problem afterwards.
>

In this case 'all options' would mean the different choices that
maintainers have discussed and considered, before calling an informal vote.
The reason for the informal vote is that 'all options' have been
considered, but a decision can not be made. Whilst there can be many
options, the informal voting method aims to reduce this by enabling
maintainers to call a vote and propose two options, so the project can move
forward. Again there will be times for that call for flexibility, but we
should always aim to have a vote for two of the best solutions to avoid the
project coming to another standstill.


>
> >
> > While I like the informal vote proposal and effectively we have already
> > been following it in many areas of the project, I don't think we should
> > change the current processes from that point of view.
>
> I am confused. Are you suggesting that we should not write down how
> informal votes works?
>

I cannot speak for Stefano, but the informal vote process should be written
down as an 'aspirational guideline' meaning it's a process we ought to
follow in the best interest of the project. The formal voting process will
still be in place.

>
> >
> >
> >>>      4. Naturally, there may be exceptional circumstances, as such, a
> formal
> >>>      vote may be warranted but should happen only a few times a year
> for
> >>> serious
> >>>      cases only.
> >> Similarly here, you are suggesting that a formal vote can be called.
> But it is
> >> not super clear what would be the condition it could be used and how it
> can be
> >> called.
> >
> > The formal vote is basically the same we already have today. It would
> > follow the existing voting rules and guidelines already part of the
> > governance.
>
> Reading through the governance, I couldn't find anywhere indicating in
> which condition the formal votes can be triggered. Hence my question here.
>

There's a difficulty here in the sense that there isn't a specific
guideline around what condition a formal vote can be triggered. Until that
guideline is implemented, reviewed, and updated, I would suggest that a
formal vote is called only in cases where serious damage would come to the
project and the community. Again, this would be down to reasonable
judgement so I would trust committers/maintainers on this, and should
happen less than a few times a year.

>
> >> For instance, per the informal rule, if 2 out of 3 maintainers accept.
> Then it
> >> would be sensible for the patch to be merged as soon as the 5 days
> windows is
> >> closed. Yet the 3rd maintainer technically object it. So could that
> maintainer
> >> request a formal vote? If so, how long do they have?
> >
> > It is difficult to write down a process that works in all cases, and if
> > we did it would probably end up being slower rather than faster.
> >
> > In my view if someone doesn't agree with his other co-maintainers and he
> > is outvoted (e.g. 2/3 of the maintainers prefer a different option), the
> > individual is entitled to raise a request for a vote with the
> > committers, which is the same as we already have today.
> >
> > Ideally a formal vote would be rare, maybe once or twice a year, so I
> > hope we won't need to optimize the formal vote.
>
> Ok. So the expectation is that all the maintainers will accept the
> informal votes in the majority of the cases. If this is not the case,
> then we will revise the rules. Is that correct?
>

Having spoken to a few maintainers already, this is the agreed view. There
will be times when we have to accept the best solution even if we don't
personally agree. The best interest of the community and project should
come first, hence why an informal vote is seen as the consensus.

>
> >>>      5. Informal votes can be as easy as 2 out of 3 maintainers
> providing
> >>>      their Acked-by/Reviewed-by tag. Alternatively, Maintainers can
> call an
> >>>      informal vote by simply emailing the thread with "informal vote
> >>> proposed,
> >>>      option 1 and option 2."
> >>>      6. *All maintainers should reply with their vote within 5 working
> days.*
> >>
> >> While I understand we want to move fast, this means that a maintainer
> that is
> >> away for PTO would not have the opportunity to answer.
> >
> > PTO is a bit of a special case because we typically know when one of the
> > maintainers is on PTO. If it is a short PTO and if the vacationing
> > maintainer could have a strong opinion on the subject then it would make
> > sense to wait. If it is a long leave of absence (several weeks or
> > months) then I don't think we can wait.
> >
> > So I think the 5 working days is OK as a rule of thumb, but of course it
> > shouldn't be used to work around objections of a maintainer by waiting
> > for him to go on holiday :-)
>
> Well... It has been done before ;). That's why I think it is important
> to write down because at least it is not left to interpretation.
>

Adding to this rule, if a maintainer is on holiday for 2 weeks or less, we
should wait. If the time is 2 weeks+ and is not deemed as causing major
issues then we should proceed. This hopefully gives you a rough
guideline/time frame. We can reiterate if needed here.

>
> Cheers,
>
> --
> Julien Grall
>

[-- Attachment #2: Type: text/html, Size: 10112 bytes --]

Re: Informal voting proposal

[Jan Beulich]

On 06.11.2023 17:40, Kelly Choi wrote:
> Hi all,
> 
> As an open-source community, there will always be differences of opinion in
> approaches and the way we think. It is imperative, however, that we view
> this diversity as a source of strength rather than a hindrance.
> 
> Recent deliberations within our project have led to certain matters being
> put on hold due to an inability to reach a consensus. While formal voting
> procedures serve their purpose, they can be time-consuming and may not
> always lead to meaningful progress.
> 
> Having received agreement from a few maintainers already, I would like to
> propose the following:
> 
> *Informal voting method:*
> 
>    1. Each project should ideally have more than 2 maintainers to
>    facilitate impartial discussions. Projects lacking this configuration will
>    be addressed at a later stage.

Terminology question: What is "project" here? Considering how ./MAINTAINERS
is structured, is it perhaps more "component"?

>    2. Anyone in the community is welcome to voice their opinions, ideas,
>    and concerns about any patch or contribution.
>    3. If members cannot agree, the majority informal vote of the
>    maintainers will be the decision that stands. For instance, if, after
>    careful consideration of all suggestions and concerns, 2 out of 3
>    maintainers endorse a solution within the x86 subsystem, it shall be the
>    decision we move forward with.

In a later reply you make explicit what can only be guessed here: There
you suggest that out of a range of possible options, up front two are
picked to then choose between. However, when there is a range options
available, and when those can be viewed as points on a scale (rather
than, to take Stefano's earlier example of SAF-* naming, cases where
it's hard to view choices as being on a linear scale), picking two
"points" up front may already pose a problem. (See also another reply
mentioning how to ensure that the various possible options were even
taken into consideration.)

Not only in such situations, but in general, to me a prereq to even
coming to the point of needing an informal vote is the willingness of
everyone involved to find a compromise. When there's a range of views,
and when "knowing" what's going to be best for the project would require
a crystal ball, experience suggests to me that chances for an optimal
choice are better when picking a "point" not at the far ends of the scale.
(Such a result then would also much better reflect your named goal of
seeing diversity as a strength.)

With such willingness I think even informal votes could be avoided most
of the time, at which point it becomes questionable whether for the few
remaining cases informal and formal votes really need specifying
separately.

>    4. Naturally, there may be exceptional circumstances, as such, a formal
>    vote may be warranted but should happen only a few times a year for serious
>    cases only.
>    5. Informal votes can be as easy as 2 out of 3 maintainers providing
>    their Acked-by/Reviewed-by tag. Alternatively, Maintainers can call an
>    informal vote by simply emailing the thread with "informal vote proposed,
>    option 1 and option 2."

I find this difficult. Both A-b and R-b assert that the person offering
the tag endorses the presented solution to the indicated degree. It does
not say anything on possible alternative solutions. As a result taking
such tags as votes is (once again, and once again in my personal view)
reasonable only when there's a black-and-white decision to be taken.

>    6. *All maintainers should reply with their vote within 5 working days.*
> 
>    7. Please note that with any new process, there will always be room for
>    improvement and we will reiterate where needed.
> 
> Ultimately our goal here is to prevent the project coming to a standstill
> while deliberating decisions that we all cannot agree on. This may mean
> compromising in the short term but I am sure the long-term benefits will
> stand for themselves.
> 
> *If you have any strong objections to the informal voting, please let me
> know by 30th November 2023. *

Just FTAOD none of the above is meant to be a "strong objection". Despite
being unconvinced of the proposal (including the need for one, not the
least also considering what has triggered this sudden effort, when there
are - imo - worse problems of "standstill"), I'll try to be a good citizen
and play by what's going to be put in place.

Jan

PS: I can't help the impression that our differing views here are somewhat
rooted in different election systems in the countries we live in. They're
imo different enough that I consider it troublesome to see how all of them
can at the same time be considered democratic.

Re: Informal voting proposal

[Stefano Stabellini]

On Mon, 13 Nov 2023, Jan Beulich wrote:
> On 06.11.2023 17:40, Kelly Choi wrote:
> > Hi all,
> > 
> > As an open-source community, there will always be differences of opinion in
> > approaches and the way we think. It is imperative, however, that we view
> > this diversity as a source of strength rather than a hindrance.
> > 
> > Recent deliberations within our project have led to certain matters being
> > put on hold due to an inability to reach a consensus. While formal voting
> > procedures serve their purpose, they can be time-consuming and may not
> > always lead to meaningful progress.
> > 
> > Having received agreement from a few maintainers already, I would like to
> > propose the following:
> > 
> > *Informal voting method:*
> > 
> >    1. Each project should ideally have more than 2 maintainers to
> >    facilitate impartial discussions. Projects lacking this configuration will
> >    be addressed at a later stage.
> 
> Terminology question: What is "project" here? Considering how ./MAINTAINERS
> is structured, is it perhaps more "component"?

Yes, I think "component" is the right word


> >    2. Anyone in the community is welcome to voice their opinions, ideas,
> >    and concerns about any patch or contribution.
> >    3. If members cannot agree, the majority informal vote of the
> >    maintainers will be the decision that stands. For instance, if, after
> >    careful consideration of all suggestions and concerns, 2 out of 3
> >    maintainers endorse a solution within the x86 subsystem, it shall be the
> >    decision we move forward with.
> 
> In a later reply you make explicit what can only be guessed here: There
> you suggest that out of a range of possible options, up front two are
> picked to then choose between. However, when there is a range options
> available, and when those can be viewed as points on a scale (rather
> than, to take Stefano's earlier example of SAF-* naming, cases where
> it's hard to view choices as being on a linear scale), picking two
> "points" up front may already pose a problem. (See also another reply
> mentioning how to ensure that the various possible options were even
> taken into consideration.)
> 
> Not only in such situations, but in general, to me a prereq to even
> coming to the point of needing an informal vote is the willingness of
> everyone involved to find a compromise. When there's a range of views,
> and when "knowing" what's going to be best for the project would require
> a crystal ball, experience suggests to me that chances for an optimal
> choice are better when picking a "point" not at the far ends of the scale.
> (Such a result then would also much better reflect your named goal of
> seeing diversity as a strength.)
> 
> With such willingness I think even informal votes could be avoided most
> of the time, at which point it becomes questionable whether for the few
> remaining cases informal and formal votes really need specifying
> separately.

The key difference in point of views is that you see as very common to
have options on a linear scale, where finding a middle ground makes
sense, and you see as an exception cases like SAF-* naming that are not
on a scale. In my view cases like SAF-* naming are the common case,
while it would be an exception to have options on a linear scale. If
it turns out there are indeed many cases where multiple options are on a
linear scale, we might be able to come up with another idea on how to
get a quick informal consensus for those issues.


> >    4. Naturally, there may be exceptional circumstances, as such, a formal
> >    vote may be warranted but should happen only a few times a year for serious
> >    cases only.
> >    5. Informal votes can be as easy as 2 out of 3 maintainers providing
> >    their Acked-by/Reviewed-by tag. Alternatively, Maintainers can call an
> >    informal vote by simply emailing the thread with "informal vote proposed,
> >    option 1 and option 2."
> 
> I find this difficult. Both A-b and R-b assert that the person offering
> the tag endorses the presented solution to the indicated degree. It does
> not say anything on possible alternative solutions. As a result taking
> such tags as votes is (once again, and once again in my personal view)
> reasonable only when there's a black-and-white decision to be taken.

From a practical perspective, A-b and R-b are a quick and easy way to
gauge informal consensus on an issue. Also, exploring alternative
solutions take time. Time for the reviewer, time for the contributor,
time for everyone else involved in the email thread. A-b and R-b have a
very important role: they say "this is good enough". When you have a
majority of people saying "this is good enough", I think we would be
better off spending our timing fixing other deficiencies, reviewing
other patches, rather than trying to further optimize that particular
patch.


> >    6. *All maintainers should reply with their vote within 5 working days.*
> > 
> >    7. Please note that with any new process, there will always be room for
> >    improvement and we will reiterate where needed.
> > 
> > Ultimately our goal here is to prevent the project coming to a standstill
> > while deliberating decisions that we all cannot agree on. This may mean
> > compromising in the short term but I am sure the long-term benefits will
> > stand for themselves.
> > 
> > *If you have any strong objections to the informal voting, please let me
> > know by 30th November 2023. *
> 
> Just FTAOD none of the above is meant to be a "strong objection". Despite
> being unconvinced of the proposal (including the need for one, not the
> least also considering what has triggered this sudden effort, when there
> are - imo - worse problems of "standstill"), I'll try to be a good citizen
> and play by what's going to be put in place.

Thank you. Let's give it a try and see how it goes. As for every change,
we are trying to make improvements. If they don't work, or better ideas
come along, we can change again.

Re: Informal voting proposal

[Kelly Choi]

[-- Attachment #1: Type: text/plain, Size: 6900 bytes --]

Thanks for your feedback @Jan Beulich <jbeulich@suse.com> and @Stefano
Stabellini <sstabellini@kernel.org>.
Let's go ahead with your suggestion of using "component".

I am sure this is a step in the right direction, and the time saved here
will benefit from fixing other areas in the project.

Many thanks,
Kelly Choi

Open Source Community Manager
XenServer, Cloud Software Group


On Mon, Nov 13, 2023 at 10:23 PM Stefano Stabellini <sstabellini@kernel.org>
wrote:

> On Mon, 13 Nov 2023, Jan Beulich wrote:
> > On 06.11.2023 17:40, Kelly Choi wrote:
> > > Hi all,
> > >
> > > As an open-source community, there will always be differences of
> opinion in
> > > approaches and the way we think. It is imperative, however, that we
> view
> > > this diversity as a source of strength rather than a hindrance.
> > >
> > > Recent deliberations within our project have led to certain matters
> being
> > > put on hold due to an inability to reach a consensus. While formal
> voting
> > > procedures serve their purpose, they can be time-consuming and may not
> > > always lead to meaningful progress.
> > >
> > > Having received agreement from a few maintainers already, I would like
> to
> > > propose the following:
> > >
> > > *Informal voting method:*
> > >
> > >    1. Each project should ideally have more than 2 maintainers to
> > >    facilitate impartial discussions. Projects lacking this
> configuration will
> > >    be addressed at a later stage.
> >
> > Terminology question: What is "project" here? Considering how
> ./MAINTAINERS
> > is structured, is it perhaps more "component"?
>
> Yes, I think "component" is the right word
>
>
> > >    2. Anyone in the community is welcome to voice their opinions,
> ideas,
> > >    and concerns about any patch or contribution.
> > >    3. If members cannot agree, the majority informal vote of the
> > >    maintainers will be the decision that stands. For instance, if,
> after
> > >    careful consideration of all suggestions and concerns, 2 out of 3
> > >    maintainers endorse a solution within the x86 subsystem, it shall
> be the
> > >    decision we move forward with.
> >
> > In a later reply you make explicit what can only be guessed here: There
> > you suggest that out of a range of possible options, up front two are
> > picked to then choose between. However, when there is a range options
> > available, and when those can be viewed as points on a scale (rather
> > than, to take Stefano's earlier example of SAF-* naming, cases where
> > it's hard to view choices as being on a linear scale), picking two
> > "points" up front may already pose a problem. (See also another reply
> > mentioning how to ensure that the various possible options were even
> > taken into consideration.)
> >
> > Not only in such situations, but in general, to me a prereq to even
> > coming to the point of needing an informal vote is the willingness of
> > everyone involved to find a compromise. When there's a range of views,
> > and when "knowing" what's going to be best for the project would require
> > a crystal ball, experience suggests to me that chances for an optimal
> > choice are better when picking a "point" not at the far ends of the
> scale.
> > (Such a result then would also much better reflect your named goal of
> > seeing diversity as a strength.)
> >
> > With such willingness I think even informal votes could be avoided most
> > of the time, at which point it becomes questionable whether for the few
> > remaining cases informal and formal votes really need specifying
> > separately.
>
> The key difference in point of views is that you see as very common to
> have options on a linear scale, where finding a middle ground makes
> sense, and you see as an exception cases like SAF-* naming that are not
> on a scale. In my view cases like SAF-* naming are the common case,
> while it would be an exception to have options on a linear scale. If
> it turns out there are indeed many cases where multiple options are on a
> linear scale, we might be able to come up with another idea on how to
> get a quick informal consensus for those issues.
>
>
> > >    4. Naturally, there may be exceptional circumstances, as such, a
> formal
> > >    vote may be warranted but should happen only a few times a year for
> serious
> > >    cases only.
> > >    5. Informal votes can be as easy as 2 out of 3 maintainers providing
> > >    their Acked-by/Reviewed-by tag. Alternatively, Maintainers can call
> an
> > >    informal vote by simply emailing the thread with "informal vote
> proposed,
> > >    option 1 and option 2."
> >
> > I find this difficult. Both A-b and R-b assert that the person offering
> > the tag endorses the presented solution to the indicated degree. It does
> > not say anything on possible alternative solutions. As a result taking
> > such tags as votes is (once again, and once again in my personal view)
> > reasonable only when there's a black-and-white decision to be taken.
>
> From a practical perspective, A-b and R-b are a quick and easy way to
> gauge informal consensus on an issue. Also, exploring alternative
> solutions take time. Time for the reviewer, time for the contributor,
> time for everyone else involved in the email thread. A-b and R-b have a
> very important role: they say "this is good enough". When you have a
> majority of people saying "this is good enough", I think we would be
> better off spending our timing fixing other deficiencies, reviewing
> other patches, rather than trying to further optimize that particular
> patch.
>
>
> > >    6. *All maintainers should reply with their vote within 5 working
> days.*
> > >
> > >    7. Please note that with any new process, there will always be room
> for
> > >    improvement and we will reiterate where needed.
> > >
> > > Ultimately our goal here is to prevent the project coming to a
> standstill
> > > while deliberating decisions that we all cannot agree on. This may mean
> > > compromising in the short term but I am sure the long-term benefits
> will
> > > stand for themselves.
> > >
> > > *If you have any strong objections to the informal voting, please let
> me
> > > know by 30th November 2023. *
> >
> > Just FTAOD none of the above is meant to be a "strong objection". Despite
> > being unconvinced of the proposal (including the need for one, not the
> > least also considering what has triggered this sudden effort, when there
> > are - imo - worse problems of "standstill"), I'll try to be a good
> citizen
> > and play by what's going to be put in place.
>
> Thank you. Let's give it a try and see how it goes. As for every change,
> we are trying to make improvements. If they don't work, or better ideas
> come along, we can change again.
>
>

[-- Attachment #2: Type: text/html, Size: 8414 bytes --]

Re: Informal voting proposal

[Kelly Choi]

[-- Attachment #1: Type: text/plain, Size: 7368 bytes --]

Hi all,

Given that there are no further comments, I will add informal voting to our
governance policies.

Many thanks,
Kelly Choi

Xen Project Community Manager
XenServer, Cloud Software Group


On Tue, Nov 14, 2023 at 11:16 AM Kelly Choi <kelly.choi@cloud.com> wrote:

> Thanks for your feedback @Jan Beulich <jbeulich@suse.com> and @Stefano
> Stabellini <sstabellini@kernel.org>.
> Let's go ahead with your suggestion of using "component".
>
> I am sure this is a step in the right direction, and the time saved here
> will benefit from fixing other areas in the project.
>
> Many thanks,
> Kelly Choi
>
> Open Source Community Manager
> XenServer, Cloud Software Group
>
>
> On Mon, Nov 13, 2023 at 10:23 PM Stefano Stabellini <
> sstabellini@kernel.org> wrote:
>
>> On Mon, 13 Nov 2023, Jan Beulich wrote:
>> > On 06.11.2023 17:40, Kelly Choi wrote:
>> > > Hi all,
>> > >
>> > > As an open-source community, there will always be differences of
>> opinion in
>> > > approaches and the way we think. It is imperative, however, that we
>> view
>> > > this diversity as a source of strength rather than a hindrance.
>> > >
>> > > Recent deliberations within our project have led to certain matters
>> being
>> > > put on hold due to an inability to reach a consensus. While formal
>> voting
>> > > procedures serve their purpose, they can be time-consuming and may not
>> > > always lead to meaningful progress.
>> > >
>> > > Having received agreement from a few maintainers already, I would
>> like to
>> > > propose the following:
>> > >
>> > > *Informal voting method:*
>> > >
>> > >    1. Each project should ideally have more than 2 maintainers to
>> > >    facilitate impartial discussions. Projects lacking this
>> configuration will
>> > >    be addressed at a later stage.
>> >
>> > Terminology question: What is "project" here? Considering how
>> ./MAINTAINERS
>> > is structured, is it perhaps more "component"?
>>
>> Yes, I think "component" is the right word
>>
>>
>> > >    2. Anyone in the community is welcome to voice their opinions,
>> ideas,
>> > >    and concerns about any patch or contribution.
>> > >    3. If members cannot agree, the majority informal vote of the
>> > >    maintainers will be the decision that stands. For instance, if,
>> after
>> > >    careful consideration of all suggestions and concerns, 2 out of 3
>> > >    maintainers endorse a solution within the x86 subsystem, it shall
>> be the
>> > >    decision we move forward with.
>> >
>> > In a later reply you make explicit what can only be guessed here: There
>> > you suggest that out of a range of possible options, up front two are
>> > picked to then choose between. However, when there is a range options
>> > available, and when those can be viewed as points on a scale (rather
>> > than, to take Stefano's earlier example of SAF-* naming, cases where
>> > it's hard to view choices as being on a linear scale), picking two
>> > "points" up front may already pose a problem. (See also another reply
>> > mentioning how to ensure that the various possible options were even
>> > taken into consideration.)
>> >
>> > Not only in such situations, but in general, to me a prereq to even
>> > coming to the point of needing an informal vote is the willingness of
>> > everyone involved to find a compromise. When there's a range of views,
>> > and when "knowing" what's going to be best for the project would require
>> > a crystal ball, experience suggests to me that chances for an optimal
>> > choice are better when picking a "point" not at the far ends of the
>> scale.
>> > (Such a result then would also much better reflect your named goal of
>> > seeing diversity as a strength.)
>> >
>> > With such willingness I think even informal votes could be avoided most
>> > of the time, at which point it becomes questionable whether for the few
>> > remaining cases informal and formal votes really need specifying
>> > separately.
>>
>> The key difference in point of views is that you see as very common to
>> have options on a linear scale, where finding a middle ground makes
>> sense, and you see as an exception cases like SAF-* naming that are not
>> on a scale. In my view cases like SAF-* naming are the common case,
>> while it would be an exception to have options on a linear scale. If
>> it turns out there are indeed many cases where multiple options are on a
>> linear scale, we might be able to come up with another idea on how to
>> get a quick informal consensus for those issues.
>>
>>
>> > >    4. Naturally, there may be exceptional circumstances, as such, a
>> formal
>> > >    vote may be warranted but should happen only a few times a year
>> for serious
>> > >    cases only.
>> > >    5. Informal votes can be as easy as 2 out of 3 maintainers
>> providing
>> > >    their Acked-by/Reviewed-by tag. Alternatively, Maintainers can
>> call an
>> > >    informal vote by simply emailing the thread with "informal vote
>> proposed,
>> > >    option 1 and option 2."
>> >
>> > I find this difficult. Both A-b and R-b assert that the person offering
>> > the tag endorses the presented solution to the indicated degree. It does
>> > not say anything on possible alternative solutions. As a result taking
>> > such tags as votes is (once again, and once again in my personal view)
>> > reasonable only when there's a black-and-white decision to be taken.
>>
>> From a practical perspective, A-b and R-b are a quick and easy way to
>> gauge informal consensus on an issue. Also, exploring alternative
>> solutions take time. Time for the reviewer, time for the contributor,
>> time for everyone else involved in the email thread. A-b and R-b have a
>> very important role: they say "this is good enough". When you have a
>> majority of people saying "this is good enough", I think we would be
>> better off spending our timing fixing other deficiencies, reviewing
>> other patches, rather than trying to further optimize that particular
>> patch.
>>
>>
>> > >    6. *All maintainers should reply with their vote within 5 working
>> days.*
>> > >
>> > >    7. Please note that with any new process, there will always be
>> room for
>> > >    improvement and we will reiterate where needed.
>> > >
>> > > Ultimately our goal here is to prevent the project coming to a
>> standstill
>> > > while deliberating decisions that we all cannot agree on. This may
>> mean
>> > > compromising in the short term but I am sure the long-term benefits
>> will
>> > > stand for themselves.
>> > >
>> > > *If you have any strong objections to the informal voting, please let
>> me
>> > > know by 30th November 2023. *
>> >
>> > Just FTAOD none of the above is meant to be a "strong objection".
>> Despite
>> > being unconvinced of the proposal (including the need for one, not the
>> > least also considering what has triggered this sudden effort, when there
>> > are - imo - worse problems of "standstill"), I'll try to be a good
>> citizen
>> > and play by what's going to be put in place.
>>
>> Thank you. Let's give it a try and see how it goes. As for every change,
>> we are trying to make improvements. If they don't work, or better ideas
>> come along, we can change again.
>>
>>

[-- Attachment #2: Type: text/html, Size: 9278 bytes --]

Re: Informal voting proposal

[Kelly Choi]

[-- Attachment #1: Type: text/plain, Size: 6183 bytes --]

Hi Rich,

I am away on business travel, so did not see your reply before sending my
last email.

The problem we have noted is that there are frequent disagreements within
the project, mainly due to a difference in opinion among other factors. As
a bid to help us move quicker and progress within the community, the
informal voting method was suggested. There probably are many cases where
this can be applicable, but historically a formal vote is a long process
that many want to avoid.

A solution orientated approach is the reason for suggesting a method such
as informal voting. Rather than approaching each problem with a unique
process, this approach encourages the community to work together to achieve
a consensus. Only when this is not possible, then informal voting should be
called.

The informal voting aims to consider multiple solutions, before deciding
between the best two. So I'd disagree with your point that it is either one
solution or no solution.
Instead, the informal voting process aims to empower individuals to present
the best solutions after discussions. I would suggest that historical test
cases be used here as part of the argument whilst presenting the solution.
Again, if we considered every single solution and still disagreed then this
would defeat the point of a vote. It would also be time consuming for
members involved to consistently argue the benefits of each point when it
is clear there are disagreements.

For specific test cases, I agree this would be helpful to have. This would
fit better in aspirational guidelines within governance documents as to
what has happened previously, the solution in that instance, and how it was
resolved.

Our goal here is to progress whilst achieving a majority consensus. It
doesn't mean that the informal voted decision cannot be reviewed when
things change, but this solution will help break up disagreements and avoid
stagnation. Processes such as these will always be reviewed to ensure
consistent improvements in our ways of working.

On a more positive note, it's great to hear your opinion. It simply means
that you and others within the community care and want the best out of the
project.




On Fri, 1 Dec 2023 at 18:08, Rich Persaud <persaur@gmail.com> wrote:

> On Nov 6, 2023, at 13:53, Kelly Choi <kelly.choi@cloud.com> wrote:
>
>
> 
> Hi all,
>
> As an open-source community, there will always be differences of opinion
> in approaches and the way we think. It is imperative, however, that we view
> this diversity as a source of strength rather than a hindrance.
>
> Recent deliberations within our project have led to certain matters being
> put on hold due to an inability to reach a consensus. While formal voting
> procedures serve their purpose, they can be time-consuming and may not
> always lead to meaningful progress.
>
> Having received agreement from a few maintainers already, I would like to
> propose the following:
>
> *Informal voting method:*
>
>    1. Each project should ideally have more than 2 maintainers to
>    facilitate impartial discussions. Projects lacking this configuration will
>    be addressed at a later stage.
>    2. Anyone in the community is welcome to voice their opinions, ideas,
>    and concerns about any patch or contribution.
>    3. If members cannot agree, the majority informal vote of the
>    maintainers will be the decision that stands. For instance, if, after
>    careful consideration of all suggestions and concerns, 2 out of 3
>    maintainers endorse a solution within the x86 subsystem, it shall be the
>    decision we move forward with.
>    4. Naturally, there may be exceptional circumstances, as such, a
>    formal vote may be warranted but should happen only a few times a year for
>    serious cases only.
>    5. Informal votes can be as easy as 2 out of 3 maintainers providing
>    their Acked-by/Reviewed-by tag. Alternatively, Maintainers can call an
>    informal vote by simply emailing the thread with "informal vote proposed,
>    option 1 and option 2."
>    6. *All maintainers should reply with their vote within 5 working
>    days.*
>    7. Please note that with any new process, there will always be room
>    for improvement and we will reiterate where needed.
>
> Ultimately our goal here is to prevent the project coming to a standstill
> while deliberating decisions that we all cannot agree on. This may mean
> compromising in the short term but I am sure the long-term benefits will
> stand for themselves.
>
> *If you have any strong objections to the informal voting, please let me
> know by 30th November 2023. *
> *Should I receive no objections, the process will be implemented as of 1st
> December 2023.*
>
>
> Apologies for the late response, I was recently asked to look at this
> thread, and it's now the end of my Nov 30th USA day.
>
> In order to evaluate new governance proposals, historical test cases are
> needed.  Then the existing process, proposed process (and other candidate
> processes!) can be applied to each test case in turn, so we can evaluate
> the benefits and costs of each candidate.
>
> If the problem is not defined, how can candidate solutions be evaluated?
> Perhaps those who have responded to the thread have already discussed the
> problem(s) elsewhere, but we need to include them in the public, on-list
> discussion record.
>
>
> Again there will be times for that call for flexibility, but we should
> always aim to have a vote for two of the best solutions to avoid the
> project coming to another standstill.
>
>
> Unless I am mistaken, only *one* solution has been proposed for a problem
> that has zero on-list examples or test cases.  The community is being given
> a choice between one solution and no solution?
>
> If we can define the problem, with more than one historical example, then
> we can consider multiple solutions, pick *two* of the best solutions, and
> approve one of the solutions for implementation.
>
> Regards,
> Rich
>
> p.s. This is a strong objection to the absence of a problem definition.
>

[-- Attachment #2: Type: text/html, Size: 7500 bytes --]

Re: Informal voting proposal

[Rich Persaud]

[-- Attachment #1: Type: text/plain, Size: 3645 bytes --]

On Nov 6, 2023, at 13:53, Kelly Choi <kelly.choi@cloud.com> wrote:
> 
> Hi all,
> 
> As an open-source community, there will always be differences of opinion in approaches and the way we think. It is imperative, however, that we view this diversity as a source of strength rather than a hindrance.
> 
> Recent deliberations within our project have led to certain matters being put on hold due to an inability to reach a consensus. While formal voting procedures serve their purpose, they can be time-consuming and may not always lead to meaningful progress.
> 
> Having received agreement from a few maintainers already, I would like to propose the following:
> 
> Informal voting method:
> Each project should ideally have more than 2 maintainers to facilitate impartial discussions. Projects lacking this configuration will be addressed at a later stage.
> Anyone in the community is welcome to voice their opinions, ideas, and concerns about any patch or contribution.
> If members cannot agree, the majority informal vote of the maintainers will be the decision that stands. For instance, if, after careful consideration of all suggestions and concerns, 2 out of 3 maintainers endorse a solution within the x86 subsystem, it shall be the decision we move forward with.
> Naturally, there may be exceptional circumstances, as such, a formal vote may be warranted but should happen only a few times a year for serious cases only.
> Informal votes can be as easy as 2 out of 3 maintainers providing their Acked-by/Reviewed-by tag. Alternatively, Maintainers can call an informal vote by simply emailing the thread with "informal vote proposed, option 1 and option 2." 
> All maintainers should reply with their vote within 5 working days.  
> Please note that with any new process, there will always be room for improvement and we will reiterate where needed.
> Ultimately our goal here is to prevent the project coming to a standstill while deliberating decisions that we all cannot agree on. This may mean compromising in the short term but I am sure the long-term benefits will stand for themselves.  
> 
> If you have any strong objections to the informal voting, please let me know by 30th November 2023. 
> Should I receive no objections, the process will be implemented as of 1st December 2023.
> 

Apologies for the late response, I was recently asked to look at this thread, and it's now the end of my Nov 30th USA day.

In order to evaluate new governance proposals, historical test cases are needed.  Then the existing process, proposed process (and other candidate processes!) can be applied to each test case in turn, so we can evaluate the benefits and costs of each candidate.  

If the problem is not defined, how can candidate solutions be evaluated?  Perhaps those who have responded to the thread have already discussed the problem(s) elsewhere, but we need to include them in the public, on-list discussion record.


> Again there will be times for that call for flexibility, but we should always aim to have a vote for two of the best solutions to avoid the project coming to another standstill. 


Unless I am mistaken, only one solution has been proposed for a problem that has zero on-list examples or test cases.  The community is being given a choice between one solution and no solution?  

If we can define the problem, with more than one historical example, then we can consider multiple solutions, pick two of the best solutions, and approve one of the solutions for implementation.

Regards,
Rich

p.s. This is a strong objection to the absence of a problem definition.

[-- Attachment #2: Type: text/html, Size: 4671 bytes --]