Vox Populi Congress Guide

[Stalker0]

32 currently has more than 50% of people voting, thus by definition a majority, voting for Yea. I also has even more peple, a plurality, voting for Nay. This is because like 1 in 10 voters voted for both Yea and Nay for some reason.

Proposal 32 currently has 37 votes for yes, 40 for no. So based on simple majority, No would be the current push should the vote end.

Because of multi-option voting, it doesn't matter how many people voted, its purely about vote totals. Option with the most votes wins.

 

[Cebrudras]

Proposal 32 currently has 37 votes for yes, 40 for no. So based on simple majority, No would be the current push should the vote end.

Because of multi-option voting, it doesn't matter how many people voted, its purely about vote totals. Option with the most votes wins.

That is true if you give people who click both buttons two votes. At the same time it is also true that 37 out of 71 Voters support Yes, meaning it has a majority.

 

[CppMaster]

Whichever option has more votes win, regardless of number of total voters.

 

[Cebrudras]

Whichever option has more votes win, regardless of number of total voters.

Then language needs to be changed to plurality rather than majority. Majority just cares about the 50% of voters threshold.

 

[Rekk]

Then language needs to be changed to plurality rather than majority. Majority just cares about the 50% of voters threshold.

Majority, does not care about a threshold. It cares about having more votes than the other options combined.

 

[Stalker0]

Majority, does not care about a threshold. It cares about having more votes than the other options combined.

Actually under that definition maybe we do have a plurality then.

If there are 3 vote options, whichever one is highest wins. There is no “more than other options combined”, if the number of votes is bigger than every other number of votes, it wins

 

[Recursive]

Then language needs to be changed to plurality rather than majority. Majority just cares about the 50% of voters threshold.

Okay, plurality via approval voting wins. I edited my post.

 

[Stalker0]

Okay, plurality wins. I edited my post.

To be fair, the guide does clearly say “whichever option has the most votes wins”, it didn’t say “majority”

 

[Recursive]

To be fair, the guide does clearly say “whichever option has the most votes wins”, it didn’t say “majority”

Yes, but I miswrote it as "majority wins" later on. That's the post I edited.

 

[InkAxis]

First 15 days of the month: Proposal Phase
Days 16 – 18 of the month: Sponsorship Phase
Remainder of the month: Voting Phase
30 days after a new change was released: Ratification of Changes (once the next Voting Phase occurs)

So, is a new version released as soon as the voting ends? That means sponsors should actually be finishing their code during the voting phase.

 

[Recursive]

So, is a new version released as soon as the voting ends? That means sponsors should actually be finishing their code during the voting phase.

Releases do not happen on any set schedule. When a change is voted on, it is queued to be added within a reasonable time frame, not necessarily immediately.

 

[InkAxis]

Releases do not happen on any set schedule. When a change is voted on, it is queued to be added within a reasonable time frame, not necessarily immediately.

So then, I want to clarify ratification: it happens on the first voting phase that is at least 30 days after the release date of the version with that change? (So almost always more than 30 days, if a release happens in the middle of the month, which sounds reasonable, it would be about a month and a half)
I assume it doesn't just happen 30 days after, seems like a lot of work to have individual dates for ratification.
And what about a change that was released later (let's say the modder didn't have time to implement it while everyone else did so a version was released)? It would be ratified 30 days after it's sub-release, right? Also, the delayed release should count things like a feature being implemented but broken by a bug, so that the release is when it's released as "working", ie. the latest release that changes that feature as only bugfixes should be posted through non-VP Congress.

This makes me think of an issue, that if the VP version isn't released at the start of the month then what are people proposing changes for. It could very easily take 15 days to make a working VP version in which case people are suggesting changes for a version they've never played. Of course they could base things off of what they *think* will happen, or what were issues last time, but it's a little limited.

 

[Rekk]

This makes me think of an issue, that if the VP version isn't released at the start of the month then what are people proposing changes for. It could very easily take 15 days to make a working VP version in which case people are suggesting changes for a version they've never played. Of course they could base things off of what they *think* will happen, or what were issues last time, but it's a little limited.

I will reiterate.

Releases are completely disassociated from Congress. If work for a proposal is completed when it's time to make a new release, it will be included. Otherwise, releases are tied to bug fixing and performance improvements.

Proposals must be made with this knowledge.

 

[InkAxis]

I will reiterate.

Releases are completely disassociated from Congress. If work for a proposal is completed when it's time to make a new release, it will be included. Otherwise, releases are tied to bug fixing and performance improvements.

Proposals must be made with this knowledge.

Yeah, so what are the proposals going to do while the releases "catch up"? We are going to see something is off, and change it, when really a previously approved change might have affected that thing in a way that is basically impossible to realize. There's no evidence or play testing for/against you can use exactly.

Also the section above about ratification also should be clarified.

 

[nekokon]

Probably Congress shouldn't be a monthly thing, as votes/proposals are concluded at the end of the month, and both devs and players need some time to finish the changes, release a new update and play test for an extended period.

We can change it into a bi-monthly thing, so that dev can have half a month after congress is concluded to finish the changes, and players get a total of 1 month to play test, ratify old changes and discuss potential new proposals based on new release before next Congress's sponsorship phase start (and proposals are locked).

With more time hopefully devs can have more leeway to pick up bigger changes. Those would be more important/worth extended discussion and voting than some simple QoL proposals or minor changes like +1 food to a building. Right now almost all big changes come from mod mod which are already finished.

 

[CppMaster]

We can change it into a bi-monthly thing, so that dev can have half a month after congress is concluded to finish the changes

Devs do not have a deadline to finish the changes. It could be even couple of months. Accepted proposal means that it will be developed at some time in the future.

 

[nekokon]

While that's sensible, as InkAxis has stated, there would be issues with ppl coming up with proposals that don't taking upcoming changes into consideration and we might get stuck in a loop. If that's the case not having a scheduled Congress would be better, and the dev can hold a new one after a big release whenever it's done.

 

[CppMaster]

While that's sensible, as InkAxis has stated, there would be issues with ppl coming up with proposals that don't taking upcoming changes into consideration and we might get stuck in a loop. If that's the case not having a scheduled Congress would be better, and the dev can hold a new one after a big release whenever it's done.

Oh yeah, that could be problematic. @Recursive what would be the solution for that? Vetoing proposals that conflicts with not yet implemented passed proposals?

 

[Legen]

Something I missed to have in the guide is the option to have multiple numeric variants in a proposal. For instance, say that I want to propose something like "20% <<insert yield>> when...", but I'm not sure if 20% is the right number for balance. I'd like to provide a range of values as separate votes in the same proposal, for instance:

"X% <<insert yield>> when...", with the following as separate votes:

• Yes, at 15%
• Yes, at 20%
• Yes, at 25%

, instead of either committing to one value, or create multiple counterproposals for each value.

 

[Legen]

While that's sensible, as InkAxis has stated, there would be issues with ppl coming up with proposals that don't taking upcoming changes into consideration and we might get stuck in a loop. If that's the case not having a scheduled Congress would be better, and the dev can hold a new one after a big release whenever it's done.

Oh yeah, that could be problematic. @Recursive what would be the solution for that? Vetoing proposals that conflicts with not yet implemented passed proposals?

Why not have a section of passed proposals that are under implementation, and add the rule that new proposals should not conflict with these? There's already a rule stating that a proposal can't be too similar to one that has been rejected or overturned in the prior month or 30 last days.