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 <jul...@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 >
