[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Informal voting proposal
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 Nov 6, 2023, at 13:53, Kelly Choi < kelly.choi@xxxxxxxxx> 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.
|
