[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: Informal voting proposal
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |