[RFC] Process to request a vote for an issue

[RFC] Process to request a vote for an issue

[Cornelia Huck]

[first of all: there are still issues with our usage of the platform...]

[Also, first discussing this on virtio-comment, as this is (a) where
people who want to submit changes usually are subscribed, and (b) an
actually working list, unlike the list for the TC...]

The current process to include an update in the spec is something like
the following:
- open a github issue
- post a patch on the list, link it from the issue
  - iterate through some review cycles
- ask for a vote, so that the Chairs will open a ballot

The last step currently mostly happens in the thread for the latest
revision; such an email is easily missed if you're not actively
following the discussion. IMHO it isn't a very reasonable expectation
for the chairs to follow each and every discussion in detail; at some
point, it is much more reasonable to expect trusted reviewers and SMEs
to reach a consensus.

Therefore, I propose that
- request for votes be posted in a new, separate thread, referring to
  the version proposed for inclusion and ideally containing a note on
  who deems this proposal ready for inclusion,
- and those requests be clearly marked in the subject, for example with
  a "[Request for vote]" prefix that can be easily filtered for.

Thoughts, comments?

RE: [RFC] Process to request a vote for an issue

[Parav Pandit]

> From: Cornelia Huck <cohuck@redhat.com>
> Sent: Tuesday, May 28, 2024 6:21 PM
> 
> [first of all: there are still issues with our usage of the platform...]
> 
> [Also, first discussing this on virtio-comment, as this is (a) where people who
> want to submit changes usually are subscribed, and (b) an actually working
> list, unlike the list for the TC...]
> 
> The current process to include an update in the spec is something like the
> following:
> - open a github issue
> - post a patch on the list, link it from the issue
>   - iterate through some review cycles
> - ask for a vote, so that the Chairs will open a ballot
> 
> The last step currently mostly happens in the thread for the latest revision;
> such an email is easily missed if you're not actively following the discussion.
> IMHO it isn't a very reasonable expectation for the chairs to follow each and
> every discussion in detail; at some point, it is much more reasonable to expect
> trusted reviewers and SMEs to reach a consensus.
> 
> Therefore, I propose that
> - request for votes be posted in a new, separate thread, referring to
>   the version proposed for inclusion and 
This looks good.

> ideally containing a note on
>   who deems this proposal ready for inclusion,
This additional overhead does not seem necessary because when you pull the patches using b4 tool.
It automatically captures who has reviewed, acked those patches like any other email based flow.

> - and those requests be clearly marked in the subject, for example with
>   a "[Request for vote]" prefix that can be easily filtered for.
> 
This flow described here got to be present on the README.md and if possible at [1] too.

With reworking the section [2] and [3] to write above text.

[1] https://groups.oasis-open.org/communities/tc-community-home2?CommunityKey=b3f5efa5-0e12-4320-873b-018dc7d3f25c#feedback
[2] https://github.com/oasis-tcs/virtio-spec/blob/master/README.md#use-of-github-issues
[3] https://github.com/oasis-tcs/virtio-spec/blob/master/README.md#implementation-discussion

> Thoughts, comments?
> 

RE: [RFC] Process to request a vote for an issue

[Cornelia Huck]

On Tue, May 28 2024, Parav Pandit <parav@nvidia.com> wrote:

>> From: Cornelia Huck <cohuck@redhat.com>
>> Sent: Tuesday, May 28, 2024 6:21 PM
>> 
>> [first of all: there are still issues with our usage of the platform...]
>> 
>> [Also, first discussing this on virtio-comment, as this is (a) where people who
>> want to submit changes usually are subscribed, and (b) an actually working
>> list, unlike the list for the TC...]
>> 
>> The current process to include an update in the spec is something like the
>> following:
>> - open a github issue
>> - post a patch on the list, link it from the issue
>>   - iterate through some review cycles
>> - ask for a vote, so that the Chairs will open a ballot
>> 
>> The last step currently mostly happens in the thread for the latest revision;
>> such an email is easily missed if you're not actively following the discussion.
>> IMHO it isn't a very reasonable expectation for the chairs to follow each and
>> every discussion in detail; at some point, it is much more reasonable to expect
>> trusted reviewers and SMEs to reach a consensus.
>> 
>> Therefore, I propose that
>> - request for votes be posted in a new, separate thread, referring to
>>   the version proposed for inclusion and 
> This looks good.
>
>> ideally containing a note on
>>   who deems this proposal ready for inclusion,
> This additional overhead does not seem necessary because when you pull the patches using b4 tool.
> It automatically captures who has reviewed, acked those patches like any other email based flow.

I disagree: This only captures people giving their R-b or A-b; not
e.g. a SME saying "the hardware modeling looks good to me". A R-b from a
trusted virtio reviewer is obviously a good indication that this is fine
from a virtio perspective, but there's no way for Chairs to know each
and every SME and judging how valuable the R-b or A-b of a person they
do not know is. Just spell it out; "SME xyz says it looks good" is a
reasonable statement to indicate readiness for a vote.

>
>> - and those requests be clearly marked in the subject, for example with
>>   a "[Request for vote]" prefix that can be easily filtered for.
>> 
> This flow described here got to be present on the README.md and if possible at [1] too.
>
> With reworking the section [2] and [3] to write above text.

Well, after we have agreed on something.

RE: [RFC] Process to request a vote for an issue

[Parav Pandit]

> From: Cornelia Huck <cohuck@redhat.com>
> Sent: Tuesday, May 28, 2024 7:00 PM
> 
> On Tue, May 28 2024, Parav Pandit <parav@nvidia.com> wrote:
> 
> >> From: Cornelia Huck <cohuck@redhat.com>
> >> Sent: Tuesday, May 28, 2024 6:21 PM
> >>
> >> [first of all: there are still issues with our usage of the
> >> platform...]
> >>
> >> [Also, first discussing this on virtio-comment, as this is (a) where
> >> people who want to submit changes usually are subscribed, and (b) an
> >> actually working list, unlike the list for the TC...]
> >>
> >> The current process to include an update in the spec is something
> >> like the
> >> following:
> >> - open a github issue
> >> - post a patch on the list, link it from the issue
> >>   - iterate through some review cycles
> >> - ask for a vote, so that the Chairs will open a ballot
> >>
> >> The last step currently mostly happens in the thread for the latest
> >> revision; such an email is easily missed if you're not actively following the
> discussion.
> >> IMHO it isn't a very reasonable expectation for the chairs to follow
> >> each and every discussion in detail; at some point, it is much more
> >> reasonable to expect trusted reviewers and SMEs to reach a consensus.
> >>
> >> Therefore, I propose that
> >> - request for votes be posted in a new, separate thread, referring to
> >>   the version proposed for inclusion and
> > This looks good.
> >
> >> ideally containing a note on
> >>   who deems this proposal ready for inclusion,
> > This additional overhead does not seem necessary because when you pull
> the patches using b4 tool.
> > It automatically captures who has reviewed, acked those patches like any
> other email based flow.
> 
> I disagree: This only captures people giving their R-b or A-b; not e.g. a SME
> saying "the hardware modeling looks good to me". A R-b from a trusted virtio
> reviewer is obviously a good indication that this is fine from a virtio
> perspective, but there's no way for Chairs to know each and every SME and
> judging how valuable the R-b or A-b of a person they do not know is. Just spell
> it out; "SME xyz says it looks good" is a reasonable statement to indicate
> readiness for a vote.
>
You are trying to define two things in this one process.
a. define process
b. defining SMEs

doing #b in this process does not look right to me.
I wouldn't call it SMEs given that what you wrote above that "no way for chairs to know each and every SME"..
It is hard for non_chair to judge a person as SME or not. Seems broken there.
Rather to keep things neutral and simple, why not just say, reviewed by or acked by person xyz?

> >
> >> - and those requests be clearly marked in the subject, for example with
> >>   a "[Request for vote]" prefix that can be easily filtered for.
> >>
> > This flow described here got to be present on the README.md and if
> possible at [1] too.
> >
> > With reworking the section [2] and [3] to write above text.
> 
> Well, after we have agreed on something.

RE: [RFC] Process to request a vote for an issue

[Cornelia Huck]

On Tue, May 28 2024, Parav Pandit <parav@nvidia.com> wrote:

>> From: Cornelia Huck <cohuck@redhat.com>
>> Sent: Tuesday, May 28, 2024 7:00 PM
>> 
>> On Tue, May 28 2024, Parav Pandit <parav@nvidia.com> wrote:
>> 
>> >> From: Cornelia Huck <cohuck@redhat.com>
>> >> Sent: Tuesday, May 28, 2024 6:21 PM

>> >> The last step currently mostly happens in the thread for the latest
>> >> revision; such an email is easily missed if you're not actively following the
>> discussion.
>> >> IMHO it isn't a very reasonable expectation for the chairs to follow
>> >> each and every discussion in detail; at some point, it is much more
>> >> reasonable to expect trusted reviewers and SMEs to reach a consensus.

Let's go back to the rationale here: Chairs should be able to find out
easily which issues they should open a vote on. This involves trusting
that things have been found reasonable by people familiar with the topic.

>> >>
>> >> Therefore, I propose that
>> >> - request for votes be posted in a new, separate thread, referring to
>> >>   the version proposed for inclusion and
>> > This looks good.
>> >
>> >> ideally containing a note on
>> >>   who deems this proposal ready for inclusion,
>> > This additional overhead does not seem necessary because when you pull
>> the patches using b4 tool.
>> > It automatically captures who has reviewed, acked those patches like any
>> other email based flow.
>> 
>> I disagree: This only captures people giving their R-b or A-b; not e.g. a SME
>> saying "the hardware modeling looks good to me". A R-b from a trusted virtio
>> reviewer is obviously a good indication that this is fine from a virtio
>> perspective, but there's no way for Chairs to know each and every SME and
>> judging how valuable the R-b or A-b of a person they do not know is. Just spell
>> it out; "SME xyz says it looks good" is a reasonable statement to indicate
>> readiness for a vote.
>>
> You are trying to define two things in this one process.
> a. define process
> b. defining SMEs
>
> doing #b in this process does not look right to me.
> I wouldn't call it SMEs given that what you wrote above that "no way for chairs to know each and every SME"..
> It is hard for non_chair to judge a person as SME or not. Seems broken there.
> Rather to keep things neutral and simple, why not just say, reviewed by or acked by person xyz?

Again, it's not about "defining SME", I have no idea where you got this
from. I just want the submitter to say "please open a vote for this,
$PERSON_WORKING_ON_VIRTIO and $PERSON who knows the backend are happy
with it." Nothing complicated, just an indication that it is reasonable
to open a ballot, trusting the submitter that they did any needed
reviewing cycles, and trusting that the people who said that it looks
good did their due diligence, and know what they are talking
about. (Obviously, that's primarily for more complex changes that touch
areas that not everyone is familiar with, a simple patch with an R-b
does not need elaborate justifications; just use some judgement.)

RE: [RFC] Process to request a vote for an issue

[Parav Pandit]

> From: Cornelia Huck <cohuck@redhat.com>
> Sent: Tuesday, May 28, 2024 7:39 PM
> 
> On Tue, May 28 2024, Parav Pandit <parav@nvidia.com> wrote:
> 
> >> From: Cornelia Huck <cohuck@redhat.com>
> >> Sent: Tuesday, May 28, 2024 7:00 PM
> >>
> >> On Tue, May 28 2024, Parav Pandit <parav@nvidia.com> wrote:
> >>
> >> >> From: Cornelia Huck <cohuck@redhat.com>
> >> >> Sent: Tuesday, May 28, 2024 6:21 PM
> 
> >> >> The last step currently mostly happens in the thread for the
> >> >> latest revision; such an email is easily missed if you're not
> >> >> actively following the
> >> discussion.
> >> >> IMHO it isn't a very reasonable expectation for the chairs to
> >> >> follow each and every discussion in detail; at some point, it is
> >> >> much more reasonable to expect trusted reviewers and SMEs to reach a
> consensus.
> 
> Let's go back to the rationale here: Chairs should be able to find out easily
> which issues they should open a vote on. This involves trusting that things
> have been found reasonable by people familiar with the topic.
> 
Sure, however this solely is the request of the submitter to decide to ask for the vote.
If things are not acceptable, anyway vote wont progress.

> >> >>
> >> >> Therefore, I propose that
> >> >> - request for votes be posted in a new, separate thread, referring to
> >> >>   the version proposed for inclusion and
> >> > This looks good.
> >> >
> >> >> ideally containing a note on
> >> >>   who deems this proposal ready for inclusion,
> >> > This additional overhead does not seem necessary because when you
> >> > pull
> >> the patches using b4 tool.
> >> > It automatically captures who has reviewed, acked those patches
> >> > like any
> >> other email based flow.
> >>
> >> I disagree: This only captures people giving their R-b or A-b; not
> >> e.g. a SME saying "the hardware modeling looks good to me". A R-b
> >> from a trusted virtio reviewer is obviously a good indication that
> >> this is fine from a virtio perspective, but there's no way for Chairs
> >> to know each and every SME and judging how valuable the R-b or A-b of
> >> a person they do not know is. Just spell it out; "SME xyz says it
> >> looks good" is a reasonable statement to indicate readiness for a vote.
> >>
> > You are trying to define two things in this one process.
> > a. define process
> > b. defining SMEs
> >
> > doing #b in this process does not look right to me.
> > I wouldn't call it SMEs given that what you wrote above that "no way for
> chairs to know each and every SME"..
> > It is hard for non_chair to judge a person as SME or not. Seems broken there.
> > Rather to keep things neutral and simple, why not just say, reviewed by or
> acked by person xyz?
> 
> Again, it's not about "defining SME", I have no idea where you got this from. 
Because you wrote the SMEs to write R-B or acked by.

> I
> just want the submitter to say "please open a vote for this,
> $PERSON_WORKING_ON_VIRTIO and $PERSON who knows the backend are
> happy with it." Nothing complicated, just an indication that it is reasonable to
> open a ballot, trusting the submitter that they did any needed reviewing
> cycles, and trusting that the people who said that it looks good did their due
> diligence, and know what they are talking about. (Obviously, that's primarily
> for more complex changes that touch areas that not everyone is familiar with,
> a simple patch with an R-b does not need elaborate justifications; just use
> some judgement.)

Right. No need to attribute a person as SME or anything else.
Person abc signed-off and person xyx reviewed/acked.
Each information is present in last patch_N.
Submitter to just copy paste that again in the new request vote email.

TC already has voting committee to decide what to approve or not.
Virtio TC has consciously not added any formal or informal sub-committees from last year of any intermediate SMEs.
So, let's not complicate it now either.

To your point, "Chairs should be able to find out easily which issues they should open a vote on"

For any issue for which a diligent person has iterated the patches should have the right to ask for vote like today.
Virtio TC has the ability to evaluate it and vote.

If we need to discuss this more, than,

Defining "process to request a vote" seems like a committee work to happen on the OASIS-virtio@ConnectedCommunity.org mailing list.
Is virtio OASIS list still broken for you, hence discussion on this list?

While defining the new things is good, a humble request is, lot of patches are currently in waiting stage for several weeks to months now.
Starting with Heng's v5... and many of my patches.
To be clear, we don't want to wait for the new process to slow down the snail further.

The new steps you mentioned are good to start as long as it is not blocking patches already in the pipe.

RE: [RFC] Process to request a vote for an issue

[Cornelia Huck]

On Tue, May 28 2024, Parav Pandit <parav@nvidia.com> wrote:

>> From: Cornelia Huck <cohuck@redhat.com>
>> Sent: Tuesday, May 28, 2024 7:39 PM
>> 
>> On Tue, May 28 2024, Parav Pandit <parav@nvidia.com> wrote:
>> 
>> >> From: Cornelia Huck <cohuck@redhat.com>
>> >> Sent: Tuesday, May 28, 2024 7:00 PM
>> >>
>> >> On Tue, May 28 2024, Parav Pandit <parav@nvidia.com> wrote:
>> >>
>> >> >> From: Cornelia Huck <cohuck@redhat.com>
>> >> >> Sent: Tuesday, May 28, 2024 6:21 PM
>> 
>> >> >> The last step currently mostly happens in the thread for the
>> >> >> latest revision; such an email is easily missed if you're not
>> >> >> actively following the
>> >> discussion.
>> >> >> IMHO it isn't a very reasonable expectation for the chairs to
>> >> >> follow each and every discussion in detail; at some point, it is
>> >> >> much more reasonable to expect trusted reviewers and SMEs to reach a
>> consensus.
>> 
>> Let's go back to the rationale here: Chairs should be able to find out easily
>> which issues they should open a vote on. This involves trusting that things
>> have been found reasonable by people familiar with the topic.
>> 
> Sure, however this solely is the request of the submitter to decide to ask for the vote.
> If things are not acceptable, anyway vote wont progress.
>
>> >> >>
>> >> >> Therefore, I propose that
>> >> >> - request for votes be posted in a new, separate thread, referring to
>> >> >>   the version proposed for inclusion and
>> >> > This looks good.
>> >> >
>> >> >> ideally containing a note on
>> >> >>   who deems this proposal ready for inclusion,
>> >> > This additional overhead does not seem necessary because when you
>> >> > pull
>> >> the patches using b4 tool.
>> >> > It automatically captures who has reviewed, acked those patches
>> >> > like any
>> >> other email based flow.
>> >>
>> >> I disagree: This only captures people giving their R-b or A-b; not
>> >> e.g. a SME saying "the hardware modeling looks good to me". A R-b
>> >> from a trusted virtio reviewer is obviously a good indication that
>> >> this is fine from a virtio perspective, but there's no way for Chairs
>> >> to know each and every SME and judging how valuable the R-b or A-b of
>> >> a person they do not know is. Just spell it out; "SME xyz says it
>> >> looks good" is a reasonable statement to indicate readiness for a vote.
>> >>
>> > You are trying to define two things in this one process.
>> > a. define process
>> > b. defining SMEs
>> >
>> > doing #b in this process does not look right to me.
>> > I wouldn't call it SMEs given that what you wrote above that "no way for
>> chairs to know each and every SME"..
>> > It is hard for non_chair to judge a person as SME or not. Seems broken there.
>> > Rather to keep things neutral and simple, why not just say, reviewed by or
>> acked by person xyz?
>> 
>> Again, it's not about "defining SME", I have no idea where you got this from. 
> Because you wrote the SMEs to write R-B or acked by.
>
>> I
>> just want the submitter to say "please open a vote for this,
>> $PERSON_WORKING_ON_VIRTIO and $PERSON who knows the backend are
>> happy with it." Nothing complicated, just an indication that it is reasonable to
>> open a ballot, trusting the submitter that they did any needed reviewing
>> cycles, and trusting that the people who said that it looks good did their due
>> diligence, and know what they are talking about. (Obviously, that's primarily
>> for more complex changes that touch areas that not everyone is familiar with,
>> a simple patch with an R-b does not need elaborate justifications; just use
>> some judgement.)
>
> Right. No need to attribute a person as SME or anything else.
> Person abc signed-off and person xyx reviewed/acked.
> Each information is present in last patch_N.
> Submitter to just copy paste that again in the new request vote email.
>
> TC already has voting committee to decide what to approve or not.
> Virtio TC has consciously not added any formal or informal sub-committees from last year of any intermediate SMEs.
> So, let's not complicate it now either.
>
> To your point, "Chairs should be able to find out easily which issues they should open a vote on"
>
> For any issue for which a diligent person has iterated the patches should have the right to ask for vote like today.
> Virtio TC has the ability to evaluate it and vote.
>
> If we need to discuss this more, than,
>
> Defining "process to request a vote" seems like a committee work to happen on the OASIS-virtio@ConnectedCommunity.org mailing list.
> Is virtio OASIS list still broken for you, hence discussion on this list?

Well, see my lead-in on the initial mail -- yes, it is broken (and not
just for me.)

>
> While defining the new things is good, a humble request is, lot of patches are currently in waiting stage for several weeks to months now.
> Starting with Heng's v5... and many of my patches.
> To be clear, we don't want to wait for the new process to slow down the snail further.
>
> The new steps you mentioned are good to start as long as it is not blocking patches already in the pipe.

Again, see my lead-in on the initial mail. (If things don't move once
we're good again, it's not intentional; just ping in that case.)

I'm waiting for feedback from others as well.

Re: [RFC] Process to request a vote for an issue

[Alexander Gordeev]

Hi Cornelia,

On 28.05.24 14:51, Cornelia Huck wrote:
> [first of all: there are still issues with our usage of the platform...]
> 
> [Also, first discussing this on virtio-comment, as this is (a) where
> people who want to submit changes usually are subscribed, and (b) an
> actually working list, unlike the list for the TC...]
> 
> The current process to include an update in the spec is something like
> the following:
> - open a github issue
> - post a patch on the list, link it from the issue
>    - iterate through some review cycles
> - ask for a vote, so that the Chairs will open a ballot
> 
> The last step currently mostly happens in the thread for the latest
> revision; such an email is easily missed if you're not actively
> following the discussion. IMHO it isn't a very reasonable expectation
> for the chairs to follow each and every discussion in detail; at some
> point, it is much more reasonable to expect trusted reviewers and SMEs
> to reach a consensus.
> 
> Therefore, I propose that
> - request for votes be posted in a new, separate thread, referring to
>    the version proposed for inclusion and ideally containing a note on
>    who deems this proposal ready for inclusion,
> - and those requests be clearly marked in the subject, for example with
>    a "[Request for vote]" prefix that can be easily filtered for.
> 
> Thoughts, comments?

Could you please specify who an SME is? Does this stand for the Society 
of Manufacturing Engineers (sme.org)?
I tried to search the virtio-comment and virtio-dev archives, but 
couldn't find anything relevant:
https://lore.kernel.org/virtio-comment/?q=SME
https://lore.kernel.org/virtio-dev/?q=SME
Also not in the spec repository.

-- 
Alexander Gordeev
Senior Software Engineer

OpenSynergy GmbH
Rotherstr. 20, 10245 Berlin
www.opensynergy.com

Re: [RFC] Process to request a vote for an issue

[Cornelia Huck]

On Fri, May 31 2024, Alexander Gordeev <alexander.gordeev@opensynergy.com> wrote:

> Hi Cornelia,
>
> On 28.05.24 14:51, Cornelia Huck wrote:
>> [first of all: there are still issues with our usage of the platform...]
>> 
>> [Also, first discussing this on virtio-comment, as this is (a) where
>> people who want to submit changes usually are subscribed, and (b) an
>> actually working list, unlike the list for the TC...]
>> 
>> The current process to include an update in the spec is something like
>> the following:
>> - open a github issue
>> - post a patch on the list, link it from the issue
>>    - iterate through some review cycles
>> - ask for a vote, so that the Chairs will open a ballot
>> 
>> The last step currently mostly happens in the thread for the latest
>> revision; such an email is easily missed if you're not actively
>> following the discussion. IMHO it isn't a very reasonable expectation
>> for the chairs to follow each and every discussion in detail; at some
>> point, it is much more reasonable to expect trusted reviewers and SMEs
>> to reach a consensus.
>> 
>> Therefore, I propose that
>> - request for votes be posted in a new, separate thread, referring to
>>    the version proposed for inclusion and ideally containing a note on
>>    who deems this proposal ready for inclusion,
>> - and those requests be clearly marked in the subject, for example with
>>    a "[Request for vote]" prefix that can be easily filtered for.
>> 
>> Thoughts, comments?
>
> Could you please specify who an SME is? Does this stand for the Society 
> of Manufacturing Engineers (sme.org)?
> I tried to search the virtio-comment and virtio-dev archives, but 
> couldn't find anything relevant:
> https://lore.kernel.org/virtio-comment/?q=SME
> https://lore.kernel.org/virtio-dev/?q=SME
> Also not in the spec repository.

SME == Subject Matter Expert

I was simply trying to describe the reality: we have people familiar
with virtio and the spec, and we have people familiar with with
technologies, and in the ideal case, we'd have both agree on a change
(can obviously be one person, if they're familiar with both :)

/me thinks she should never have brought that up and thought that was a
very common TLA :(

Re: [RFC] Process to request a vote for an issue

[Alexander Gordeev]

On 31.05.24 13:03, Cornelia Huck wrote:
> On Fri, May 31 2024, Alexander Gordeev <alexander.gordeev@opensynergy.com> wrote:
> 
>> Hi Cornelia,
>>
>> On 28.05.24 14:51, Cornelia Huck wrote:
>>> [first of all: there are still issues with our usage of the platform...]
>>>
>>> [Also, first discussing this on virtio-comment, as this is (a) where
>>> people who want to submit changes usually are subscribed, and (b) an
>>> actually working list, unlike the list for the TC...]
>>>
>>> The current process to include an update in the spec is something like
>>> the following:
>>> - open a github issue
>>> - post a patch on the list, link it from the issue
>>>     - iterate through some review cycles
>>> - ask for a vote, so that the Chairs will open a ballot
>>>
>>> The last step currently mostly happens in the thread for the latest
>>> revision; such an email is easily missed if you're not actively
>>> following the discussion. IMHO it isn't a very reasonable expectation
>>> for the chairs to follow each and every discussion in detail; at some
>>> point, it is much more reasonable to expect trusted reviewers and SMEs
>>> to reach a consensus.
>>>
>>> Therefore, I propose that
>>> - request for votes be posted in a new, separate thread, referring to
>>>     the version proposed for inclusion and ideally containing a note on
>>>     who deems this proposal ready for inclusion,
>>> - and those requests be clearly marked in the subject, for example with
>>>     a "[Request for vote]" prefix that can be easily filtered for.
>>>
>>> Thoughts, comments?
>>
>> Could you please specify who an SME is? Does this stand for the Society
>> of Manufacturing Engineers (sme.org)?
>> I tried to search the virtio-comment and virtio-dev archives, but
>> couldn't find anything relevant:
>> https://lore.kernel.org/virtio-comment/?q=SME
>> https://lore.kernel.org/virtio-dev/?q=SME
>> Also not in the spec repository.
> 
> SME == Subject Matter Expert
> 
> I was simply trying to describe the reality: we have people familiar
> with virtio and the spec, and we have people familiar with with
> technologies, and in the ideal case, we'd have both agree on a change
> (can obviously be one person, if they're familiar with both :)
> 
> /me thinks she should never have brought that up and thought that was a
> very common TLA :(

Thanks for the explanation. :) I understand the intention now. It is 
still not completely clear to me who would qualify as an SME, but I 
think we can try it this way.

-- 
Alexander Gordeev
Senior Software Engineer

OpenSynergy GmbH
Rotherstr. 20, 10245 Berlin
www.opensynergy.com