SFML community forums

General => SFML development => Topic started by: SuperV1234 on June 17, 2024, 04:54:46 pm

Title: Defining "consensus" policy for disagreement on proposals
Post by: SuperV1234 on June 17, 2024, 04:54:46 pm
As there recently were some disagreements on whether certain PRs should be merged or not, or on whether SFML should move in a specific direction compared to another, I believe it would be in the best interest of the SFML project and of the maintainers' time to decide on a simple process that defines "consensus" for us, to minimize time spent arguing and working on changes that will not end up being part of SFML.

I propose a simple system loosely based on WG21 straw polling -- basically, in case of a disagreement, all active SFML team members will vote with a Y/N. 75% of voting in favour of changing the status quo is required to proceed.

Despite many SFML team members being listed on GitHub, I believe the currently most active ones are:
- Vittorio Romeo
- Chris Thrasher
- Lukas Dürrenberger
- binary1248

I suggest that those four should be the ones taking the vote when required. If anyone else from the SFML team would like to be included in the polls, please let me know.

Note that there won't be a formal process for polling, but let's say that if 75% of voting members express concerns/disagreements with a proposed change either on GitHub or on Discord then there's no point in trying to argue or continue work on that proposed change.
Title: Re: Defining "consensus" policy for disagreement on proposals
Post by: eXpl0it3r on June 22, 2024, 07:18:05 pm
Not to hold it over anyones head, but I believe it's important to keep in mind that I was appointed BDFL (https://en.sfml-dev.org/forums/index.php?topic=29004.0) (internal thread (https://en.sfml-dev.org/forums/index.php?topic=28992.0)) to solve exactly this issue.

I'm not against voting necessarily, but having this as a general approach politicizes things too much for me and shifts the focus from the user to who can convince others of some random arguments.

In my opinion it's much more useful to create a common understanding, than to force through some change, and to focus on prioritized work, that users actually want, instead of focusing on artificial/technical/idiomatic improvements that likely few users profit from.

I also hope we can somehow get to a point where we have a shared vision on SFML's direction, so we're not pulling on different ends burning up all the energy and not going anywhere.
This requires understanding the SFML user and their problems, putting one owns pet peeves at a lower flame, be willing to take on work, that might not be as exciting, and try and really understand and accept the other people's perspectives.

I plan to create a separate thread on priorities (multiple dimensions), which I guess goes a bit towards vision.

75% out of 4 is 3, feels kind of natural/obvious that if everyone else doesn't like a change, that the work shouldn't be continued/included.
Title: Re: Defining "consensus" policy for disagreement on proposals
Post by: Sub on June 22, 2024, 07:56:10 pm
How is this not anything other than a play for you to exert more influence over the direction of the library?
Title: Re: Defining "consensus" policy for disagreement on proposals
Post by: eXpl0it3r on June 22, 2024, 08:11:46 pm
Not sure what you're trying to achieve with that comment.

In case that's directed at my points:
The appointing of me as BDFL wasn't my doing, but came from the team (incl. Vittorio) and the understanding of its meaning was in agreement with everyone.
Proposing a voting system that doesn't consider this point goes against that understanding and as such should be considered in the discussion.

My other points are not really in connection with that topic.

In case it's directed at Vittorio points:
I believe it's okay to discuss ways to get to common understanding. Don't think we need to assume "malice" here.
Title: Re: Defining "consensus" policy for disagreement on proposals
Post by: Sub on June 22, 2024, 08:26:04 pm
My comment wasn't directed at you or related to having a BDFL. I was trying to achieve calling out a self serving proposal by Vee, one which would give him much more influence over the direction of the library at the expense of other stakeholders.
Title: Re: Defining "consensus" policy for disagreement on proposals
Post by: Thrasher on June 23, 2024, 01:46:24 am
As Lukas pointed out this is already a settled matter.
Title: Re: Defining "consensus" policy for disagreement on proposals
Post by: SuperV1234 on June 24, 2024, 06:34:30 pm
My comment wasn't directed at you or related to having a BDFL. I was trying to achieve calling out a self serving proposal by Vee, one which would give him much more influence over the direction of the library at the expense of other stakeholders.

Could you please point out where I said that my vote would weigh twice as much as the other stakeholders' vote?

Or could you please point out where my proposal mentioned that if one of Vittorio's proposals gets below 75% approval he gets a pass anyway?

Oh, I guess I never said neither of those things. Just complete insanity.