Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: Defining "consensus" policy for disagreement on proposals  (Read 1283 times)

0 Members and 1 Guest are viewing this topic.

SuperV1234

  • Moderator
  • Full Member
  • *****
  • Posts: 190
    • View Profile
Defining "consensus" policy for disagreement on proposals
« 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.

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 10930
    • View Profile
    • development blog
    • Email
Re: Defining "consensus" policy for disagreement on proposals
« Reply #1 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 (internal thread) 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.
« Last Edit: June 23, 2024, 02:02:49 am by eXpl0it3r »
Official FAQ: https://www.sfml-dev.org/faq.php
Official Discord Server: https://discord.gg/nr4X7Fh
——————————————————————
Dev Blog: https://duerrenberger.dev/blog/

Sub

  • Full Member
  • ***
  • Posts: 159
    • View Profile
Re: Defining "consensus" policy for disagreement on proposals
« Reply #2 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?

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 10930
    • View Profile
    • development blog
    • Email
Re: Defining "consensus" policy for disagreement on proposals
« Reply #3 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.
« Last Edit: June 22, 2024, 08:23:13 pm by eXpl0it3r »
Official FAQ: https://www.sfml-dev.org/faq.php
Official Discord Server: https://discord.gg/nr4X7Fh
——————————————————————
Dev Blog: https://duerrenberger.dev/blog/

Sub

  • Full Member
  • ***
  • Posts: 159
    • View Profile
Re: Defining "consensus" policy for disagreement on proposals
« Reply #4 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.

Thrasher

  • Moderator
  • Jr. Member
  • *****
  • Posts: 54
    • View Profile
Re: Defining "consensus" policy for disagreement on proposals
« Reply #5 on: June 23, 2024, 01:46:24 am »
As Lukas pointed out this is already a settled matter.

SuperV1234

  • Moderator
  • Full Member
  • *****
  • Posts: 190
    • View Profile
Re: Defining "consensus" policy for disagreement on proposals
« Reply #6 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.