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.c...@cloud.com> wrote: > Thanks for your feedback @Jan Beulich <jbeul...@suse.com> and @Stefano > Stabellini <sstabell...@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 < > sstabell...@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. >> >>
