Vox Populi Congress Guide

Recursive

Already Looping
Moderator
Supporter
Joined
Dec 19, 2017
Messages
4,585
Location
Antarctica
The Vox Populi Congress is a formal system to propose changes to the mod which will be run by me, Recursive (the Host) throughout the year. It began on October 1, 2022.

VP Congress Phases
Anyone who wishes to propose a change to the mod (even if they're just a player and not a coder!) can go through the following process. There are four VP Congress Sessions annually.

The months of January, April, July and October are Proposal Months. This is the only time where new proposals may be made in the VP Congress subforum. During these months, the schedule is as follows:
First 15 days of the month: Proposal Phase
Days 16 – 18 of the month: Counterproposal Phase
Days 18 – 21 of the month: Sponsorship Phase
Remainder of the month: Voting Phase

The months of February, May, August and November are Implementation Months. The entire month is dedicated to the Implementation Phase, where sponsors fulfill the proposals they sponsored during the previous VP Congress Session. At the end of the month, there will be a new release of the mod. There can be new releases at other times as well - a release is simply guaranteed those four times each year.

The months of March, June, September and December are Playtesting Months. The entire month is dedicated to the Playtesting Phase, where the community playtests the implemented proposals. This is also a month for discussion and brainstorming of proposals.

Here is the annual schedule:
January - Proposal Month (1st Session)
February - Implementation Month
March - Playtesting Month
April - Proposal Month (2nd Session)
May - Implementation Month
June - Playtesting Month
July - Proposal Month (3rd Session)
August - Implementation Month
September - Playtesting Month
October - Proposal Month (4th Session)
November - Implementation Month
December - Playtesting Month

Each of these phases will be explained below.

No Proposals Outside of VP Congress
Because we now have a formal system for proposing changes to the mod, it shall be forbidden to post proposals to make a change on the Community Patch Project forums outside of the VP Congress Process.

Other polls (for instance, to measure what people think of a current mechanic, or to consider potential options for a proposal) are permitted.

Posting discussion/feedback threads is still okay, of course.

Playtesting Phase Can Begin Early
If all sponsored proposals are implemented and released earlier than the end of the Implementation Month, the Playtesting Phase begins early.

Schedule Extensions
In the event that the Host is running behind schedule, he may extend the deadlines for the next Phases in a Session as needed. This will be noted in the Discord announcement for the change of Phase, as well as the Current VP Congress Phase thread.




Structure and Management of the VP Congress
Here are the roles of the key figures involved in the Vox Populi Congress:

Lead Developers
@Gazebo, @ilteroi, @Recursive
- Have the reserve power to veto any VP Congress proposal for any good reason
- Can approve balance changes outside of the VP Congress
- Can approve the addition of new game options to the Advanced Options menu
- Can approve the sponsorship of proposals which require a supermajority vote to pass
- New lead developers may be added by a unanimous vote of the existing lead developers

Host
@Recursive
- Examines how well the VP Congress is functioning in general, and makes adjustments to the rules as needed
- Moves and merges threads, opens and closes each phase of the VP Congress, creates Voting Phase threads and polls, makes announcements, performs other miscellaneous tasks
- Supervises the general discourse of the VP Congress; intervenes if things are getting out of hand
- Manages the Session Results and Proposal Queue threads
- Oversees the Implementation Phase; makes required judgement calls on implementation; makes a new release at the end of the phase
- Appoints and supervises the three Magi who scrutinize the proposals and assist in management of the Congress
- Settles appeals to Magi decisions; the Host has the powers to suspend or overrule them, and exercise Magi powers, but these reserve powers will not be used often

The Magi
@Stalker0, @axatin, @Hinin
- Three members of the community who serve for four Congress sessions (one year), appointed by the Host after an application process
- During the Proposal, Counterproposal and Sponsorship phases, scrutinize proposals and decide whether they're compliant with the Congress rules; veto those which are not
- Make judgement calls, such as whether proposals should be combined or separated and whether a proposal should be fast-track accepted
- List the required skill sets to implement proposals into Vox Populi
- Ensure all proposals provide sufficient and true background information; assist in providing such knowledge when needed
- Supervise the mod's balance and submit counterproposals when they feel that an alternative should exist to be voted on
- Decide the list of options on Voting Phase polls, especially when there is overlap between game mechanics
- Casts the tiebreaking vote when two or more non-Nay options in a vote have equal vote totals
- In the event that the Host is temporarily unable to perform his duties, the Magi collectively function as the Host for VP Congress purposes

Sponsors
Are listed in this thread
- Volunteer to do the coding work for valid proposals made by the Populi, enabling them to proceed to the Voting Phase

Populi (Everyone!)
- Make proposals on how to change Vox Populi, in accordance with this guide
- Vote on which proposals are approved into Vox Populi




Rules for New Proposals and Counterproposals
Anyone can post a proposal for a change they’d like to see in Vox Populi in the Vox Populi Congress subforum. They must meet the requirements below:

Formal Requirements
Any Magus may unilterally veto (or request changes to) a proposal which fails one of these requirements. However, if another Magus objects to the decision, it must be voted on by the Magi.
  • The proposal must be posted during the Proposal Phase or the Counterproposal Phase. During the Counterproposal Phase, there are more limitations (see "Judgement Call Requirements", below).

  • The proposal must propose a change. Counterproposals must propose an alternative to an existing proposal.

  • The proposal must explain its reasoning; the intended effect(s) of the change. This doesn’t need to be long, but it does need to be present, so the community understands your goal.

  • Proposals must be submitted as their own thread in the Vox Populi Congress subforum. Proposals submitted as posts in other threads, on Discord, or in other locations will be disregarded.

  • The proposal thread's opening post (OP) must contain all the elements of the proposal. Using multiple posts (or multiple threads!) to make the proposal is not permitted. Embedding images and attachments is permitted, so there should also be no need to link to external sites.

  • The proposal must contain no optional or "figure this out" elements. You are making a proposal, not bringing up possible options or asking for suggestions. If you want to do either of these, try using the Vox Populi Congress Proposal Workshop or chat with others in the Vox Populi Discord server.

  • The proposal must not be identical to one that someone else has already made during this session.

  • A proposer is not allowed to submit a counterproposal to their own proposal; that is to say, they may not submit a proposal which directly conflicts with a proposal that they have already made during this session. Two proposals, one of which adds 2 Gold to the Granary and one of which adds 3 Gold to the Granary, would be considered directly conflicting. Multiple proposals which affect the same mechanic may be submitted if they do not directly conflict, but the Magi may require that they be merged at their discretion.

  • The proposal must not be a bugfix. All bugs should be reported on GitHub and nowhere else! (Note: A bug is unintended game behavior. An exploitable mechanic, such as save scumming, is not a bug.)

  • The proposal must be about game balance or other mechanics visible to the player. Proposals about purely internal changes such as performance improvements, modmod compatibility or database restructuring should not be made here – open an issue or submit a pull request on GitHub instead.

  • Proposals which add additional game options to the Advanced Options menu require the approval of a lead developer. Map settings for custom maps are exceptions to this rule. Options which can be edited in the mod's configuration files do not count.

  • Proposals to integrate another mod's assets into Vox Populi require permission from that mod's creator. If art assets or code are not being directly copied, it is acceptable to copy game mechanics or functionality from other mods, but it is courteous to request permission before doing so.

  • Proposals should not modify the Community Patch only version's game balance.

Judgement Call Requirements
The Magi must vote in order to veto (or request changes to) a proposal which fails one of these requirements.
  • The proposal must be specific. Explain exactly what change you want to see and use exact numbers if possible. “Make Culture Victory less easy to achieve” will be rejected, while “Reduce the base Tourism on Great Works to 1” is a valid suggestion.

  • The proposal must be in scope for the mod. This will be generously interpreted given that this process is intended to empower the voices of the players, but if you’re asking for something which is impossible, would completely upend the game, requires an infeasible amount of work, or is against the vision of the mod, your proposal will be rejected. For example, a proposal for a 64-bit version of Vox Populi would be rejected.

  • Proposals to change the one unit per tile (1UPT) rule or prevent save scumming by adding randomness when loading savegames are specifically considered out of scope. These will not be changed, the former because it is a core part of the game and the latter because it would prohibit effective debugging of savegames.

  • The proposal must provide adequate background information to allow the community to make an informed decision, including explaining the current state of whatever is being modified. As a general rule of thumb, more complicated proposals should provide more detail. Supporting facts (not opinions) made during a proposal post must be accurate. If a proposal contains misinformation as a basis for its approval, this is grounds for it to be vetoed.

  • Counterproposals submitted during the Counterproposal Phase must be roughly equal or lesser in impact as the proposal they are replacing.

  • The proposal should be serious (no jokes, spam, etc). It is acceptable for a proposal to contain humor or to include an easter egg or reference, but it should be a seriously intended suggestion.

  • Multiple proposals may be submitted by the same proposer which affect the same area of balance, as long as the proposals do not directly conflict. In that case, it is possible to include in one proposal a flexible part that depends on the outcome of the other ("If proposal B is passed, change X of this proposal will be modified as follows: …"). Flexible parts are to be used sparingly and may constitute only a small part of the proposal. The Magi may require that proposals be merged together if they are by the same proposer, if they deem that it is in the best interests of the community. They may request the merge of non-conflicting proposals by different proposers if they feel they would be better combined, but the proposers are not required to agree to this.

  • If a large proposal is submitted which affects different areas of balance ("multiple distinct proposals lumped into one"), the Magi may require that the proposal be broken apart into separate proposals, if they deem that it would be in the best interests of the community.

  • Proposals which modify bugged game mechanics might be vetoed until any bugs are fixed. A unanimous vote of the Magi may veto a proposal on this ground, as can any lead developer.

Formatting Requirements
Proposals not in compliance with these rules will need to be edited. Any Magus may edit thread titles, add counterproposal links, and note amendments if necessary, but try to reduce their workload by following these.
  • The proposal thread title should have the correct format. This depends on the game mechanic that is being modified. The Host will correct any proposals with formatting issues, but try to follow this to put less work on the Host.
    - If there is an existing proposal to modify the same game mechanic, it's a Counterproposal and the format is: (X-YYn) Thread Title

    - Otherwise, it's simply a Proposal and the format is: (X-YY) Thread Title

    X = The number of the current VP Congress Session.
    YY = The proposal number, starting at 01. This is based on the timestamp for the first post in the thread. You can view the order in which threads were created by using the "First post > Ascending/Descending" forum filter.
    n = The counterproposal letter (only for Counterproposals). If the base proposal is (2-03), then the first Counterproposal would be (2-03a), the next would be (2-03b), etc.

  • If the proposal is a Counterproposal, you must link to the first proposal in your opening post.

  • When you amend a proposal, edit your original post to note the amendment and make a new post in the thread to explain what you changed about your proposal. This rule exists so that those new to the thread and those who have already read it receive the memo.

Decorum Requirements
  • Proposals must be civil and not contain accusatory or unfriendly language towards proposers, sponsors, developers, or the community as a whole. Proposals which fail to follow this rule should be reported to the Host.

  • By making a proposal, you are providing an idea to the community and forfeit any kind of copyright-type claim to the idea. Even if you withdraw the proposal, you accept that the community may propose the idea again in the future, and you accept that your preferred implementation of the idea may not be the one that ends up being added to the mod.

  • The proposal must be safe for work and must not violate any other CivFanatics site rules or applicable laws. Proposals which violate this rule should be reported to CivFanatics moderators using the Report button.

  • The Host may temporarily or permanently ban anyone from participating in the VP Congress if they are spamming, trolling, being persistently rude and aggressive, failing to follow the rules for submitting proposals, violating CivFanatics site rules, etc. Be nice to each other!

  • Using multiple accounts to submit proposals or vote, in addition to being against site rules, will result in an automatic and permanent ban from all future VP Congress sessions.



Proposal Phase
The Proposal Phase begins on the 1st of every Proposal Month at 10 AM CST and ends on the 16th of the month at 10 AM CST.

Things which can be done during this phase are listed below.


Making a Proposal
Anyone may make a new proposal. Make sure to follow the rules in the section just above when submitting!


Making a Counterproposal
Proposals which modify the same game mechanic (e.g., increase base Trade Route Gold to 2, increase base Trade Route Gold to 3) or area of balance (two proposals which add new beliefs) are allowed. During the Voting Phase, these will be displayed as separate options.

By labelling a proposal as a counterproposal, you are indicating that it is intended as an alternative to the original proposal.


There are two types of counterproposals:
- Ones which directly conflict with each other (e.g., +1 Food to Granary, +2 Food to Granary).
- Ones which affect the same game mechanic but could both be added (+1 Food to Granary, +1 Gold to Granary).

In the first case, the voting options would look like this, assuming both proposals were sponsored:
  • Yea to +2 Food to Granary
  • Yea to +1 Food to Granary
  • Nay
In the second case, the Magi may, at their discretion, permit combinations of proposals within a single vote. For example:
  • Yea to +1 Food and +1 Gold to Granary
  • Yea to +1 Food to Granary
  • Yea to +1 Gold to Granary
  • Nay

You are not allowed to make a counterproposal which directly conflicts with another proposal you have made in the current session.


Amending an Existing Proposal
To make an amendment to an existing proposal, the original proposer should:
  • Edit the original post of their thread to change the proposal.
  • Make a note in the original post to indicate that the proposal was amended and explaining how it was amended.
  • Make a new post in the thread to say that their proposal was amended (this alerts anyone watching the thread, so they can provide feedback or act accordingly).
There is no limit to how many times a proposal can be amended during the Proposal Phase.

If a proposal is amended, anyone who doesn't like the amended version can make a counterproposal with the pre-amended version of the proposal.

If a proposer amends a proposal by making it into something completely different (e.g. "+2 Food on Granary" to "Decrease unit maintenance costs by 25%", the proposal may be vetoed and the proposer told to create a new thread by the Magi.


Discussion and Debate on Proposals
Discussion, debate and amendment of the proposals, as well as the submission of counterproposals, can begin right away once a proposal thread is made in the VP Congress subforum.

Discussion must remain civil; avoid personal attacks and accusations. If you don't like a proposal, then attack the proposal, not the proposer. Accusations and unfriendly behavior which discourages new proposals will result in intervention by the Host if seen.

Avoid any off topic posts that don't contribute to the discussion. Bringing up irrelevant and controversial topics such as politics is a violation of CivFanatics site rules.

Don't make posts which serve only to upset or anger other users (flaming/trolling).

Discussion and debate may also take place on Vox Populi's Discord server.


Fast-Track Acceptance of a Proposal
By a unanimous vote, the Magi can decide that a proposal has no reasonable objection to it (i.e., is purely an improvement to the game). Such a proposal can be sponsored immediately, which will be indicated by the [Fast Tracked] thread prefix, and if it is, that proposal is immediately passed and moved to the Passed Proposals subforum. It will be marked as (Congress Session Number-A).

If a proposal approved for fast-track acceptance has counterproposals, they are no longer a counterproposal to the accepted proposal; however, the Magi should think carefully about fast-track accepting a proposal with counterproposals, as it likely means there is a reasonable objection.


Withdrawing a Proposal
The proposer may withdraw their proposal. Please post in the thread and tag at least one of the Magi (or send them a message by conversation) informing them that you would like to withdraw your proposal. Messaging them on Discord is also acceptable.

A proposal may not be withdrawn once the Counterproposal Phase has begun.

A withdrawn proposal may be resubmitted by anyone else.

A withdrawn proposal will be labelled as (Congress Session Number-WD) and moved to the Failed Proposals subforum.


Vetoing a Proposal
If the Magi judge that a proposal is in violation of the VP Congress rules, they may veto the proposal. They may unilaterally veto any proposal which fails to meet a Formal Requirement. A Magi Vote must take place in order to veto any proposal which fails to meet a Judgement Call Requirement. Any lead developer is also permitted to veto any proposal for any good reason.

A Magi Veto must explain which requirement(s) the proposal failed to meet, and a lead developer veto must explain the problem(s) with the proposal. Please don't take a proposal being vetoed personally; you are free to submit a corrected proposal immediately.

Proposals may not be vetoed for failing to meet a Formatting Requirement, but they may be edited for compliance.

In the case of a Magi decision that proposals must be merged or separated, the Magi should merge or separate the proposals themselves if the original proposer does not respond (rather than simply vetoing it). Proposals submitted due to a merge or separation do not count as proposals made by the Magi.

If you’re unsure of whether your proposal is acceptable, you can always consult the Magi or else submit the proposal well ahead of time to give yourself time to edit it in the case of a rejection.

A vetoed proposal will be labelled as (Congress Session Number-VT) and moved to the Failed Proposals subforum.


Implementation Requirements Designation
If the Magi do not veto a proposal, they will list what skill set(s) are required to implement the proposal:
  • Database (SQL/XML/some others): Generally, this means the proposal requires changing SQL/XML files. Some LUA files (such as AssignStartingPlots.lua) and art asset files also qualify as database changes.
  • UI Changes (LUA): Requires changes to the UI.
  • DLL Changes (C++/DLL): Require changes to the GameCoreDLL.
  • New Artwork: Requires creating or editing art assets. Merely adding already existing art assets is considered a database change.
  • Complex: More than one of the above components is required.
An implementation requirement designation can be made or amended by any Magus unilterally.

The Magi should tag the thread with the [Database], [UI], [DLL], [Artwork] or [Complex] thread prefix.

For Complex proposals, they should also edit in a note at the bottom of the original post, as follows:
Complex Proposal: DLL + Database Changes

Implementation requirements should be reevaluated if the proposal is amended.


Supermajority Designation
Some proposals require a supermajority to approve them. These are:
- The addition of a new civilization
- The addition of a new victory condition
- The addition of a new era
- The addition of a new policy tree or ideology
- Anything else which majorly affects game balance on a similar scale as any of the above (judgement call)

A supermajority designation may be done by any Magus unilterally, but if another Magus disagrees, a Magi Vote is required.

The Magi are responsible for noting at the bottom of the original post whether a proposal requires a supermajority to pass (Requires Supermajority). A lead developer must also approve the sponsorship of such a proposal.

A proposal requiring a supermajority must always be its own separate Yea/Nay proposal, and only passes if 75% of voters vote Yea, rounded down. If there are multiple options for such a proposal, the Host will handle the situation (it will involve a longer voting period followed by a Yea/Nay proposal).




Counterproposal Phase
The Counterproposal Phase begins on the 16th of every Proposal Month at 10 AM CST and ends on the 19th of the month at 10 AM CST.

The Counterproposal Phase is intended to prevent:
  • Proposals with large amounts of changes being proposed at the last minute with no opportunity for anyone to make a counterproposal
  • Proposals being withdrawn at the last minute with no opportunity to resubmit it if someone else likes it
During the Counterproposal Phase:
  • No new proposals may be submitted.
  • Proposals cannot be withdrawn.
  • Proposals which were previously withdrawn can be resubmitted.
  • Amendments (including the restoration of the old version of a proposal) can still be made.*
  • New counterproposals may be made.*

* = However, unlike during the Proposal Phase, the Counterproposals and amendments made during this phase cannot greatly exceed the scope of the original proposal; the amount of things changed must be around the same amount or lower. If this rule is not followed, the change will be reverted and/or vetoed.


Other Events
New counterproposals will still receive Implementation Requirement Designations, can be vetoed, and can be fast-track accepted, but can no longer be withdrawn.

Discussion and debate may continue as normal.




Sponsorship Phase
The Sponsorship Phase begins on the 19th of every Proposal Month at 10 AM CST and ends on the 22nd of the month at 8 AM CST.

To advance to the Voting Phase, at least one coder must “sponsor” the proposal by making a post in the proposal thread. The proposer can sponsor their own proposal if they have the coding skills for it, and multiple coders can sponsor the same proposal. The main purpose of this phase is to ensure that the community does not vote on changes that have no chance of getting implemented due to lack of modder availability. Side purposes are to encourage communication between modders and players, to improve awareness of the development process, and to give anyone new who wants to contribute to the project opportunities to do so.

If your proposal is complicated or difficult to implement, it is recommended to find a sponsor for your proposal before the game begins.

The Magi will regularly review the forum during the Sponsorship Phase and add the [Sponsored] thread prefix to all sponsored proposals. They will add the [Backup Needed] thread prefix to threads which need a backup sponsor (see below).

Sponsorship Rules
  • You must register as a sponsor in the Sponsorship Registration thread in order for your sponsorships to be considered valid. Registration is as simple as making a short post explaining what you're able to sponsor; read the first post in the thread for further instructions.

  • To sponsor a proposal, you must post in the thread to announce that you sponsor it. You must use the word "sponsor" in your announcement.

  • Anyone with the necessary skills, even if they have never previously contributed to Vox Populi, can sponsor a proposal.

  • By sponsoring the proposal, a coder confirms that they are able and willing to do the necessary coding changes by the end of the Implementation Phase (the end of the following month) should the community approve the proposal.

  • The coder does not necessarily need to agree with the proposal, they only need to be capable and willing to do the work required to add it to the mod if the vote is Yea.

  • Sponsoring of a proposal cannot be done before the Sponsorship Phase, except for proposals approved for Fast-Track Acceptance.


Sponsorship Deadline
The deadline to submit the changes for a sponsored proposal to the GitHub repository is the end of the Implementation Phase (the end of the following month). For instance, a proposal passed during January 2023's Voting Phase must be implemented by February 28, 2023.

If a proposal is not implemented by that deadline, it will be dropped from the queue and fails automatically. Reaching out to other coders, etc. is all perfectly fine if you're having trouble meeting the deadline. There are no penalties for failing to meet the deadline, provided it is not intentional or repetitive on the sponsor's part. This is volunteer work and life happens.

If a modder submits the changes from a proposal past the Sponsorship Deadline, it will be treated as a balance change outside of the VP Congress, which must be approved by a lead developer. The Magi may also be asked to provide input on the decision.


Partial Sponsorship
If two or more coders can cover different parts of a proposal (for example, one can handle SQL/XML changes and the other can handle DLL integration), this will be counted as valid sponsorship provided that all requirements of the proposal are met.


Magi Option Lists
During the Sponsorship Phase, in addition to tagging sponsored proposals, the Magi are responsible for building a list of voting options for the Host to add to all proposals with counterproposals. They should first assume that all proposals will get sponsored. If there are three or more counterproposals in play, they should also plan alternate scenarios if some of the proposals are not sponsored (unless they have already been sponsored, of course).


AI Must Be Able To Handle Changes
Implementing a balance change requires that the AI is able to handle the change. A sponsor must be able to modify the AI to be able to handle the balance change, if necessary.


New Proposals and Amendments
No proposals (including counterproposals) or amendments to existing proposals may be made during the Sponsorship Phase.


Clarity Edits
Edits may be made to the text of a proposal during the Sponsorship Phase only to clarify the proposal's intent or provide additional background information.


Proposals Not Sponsored
If a proposal is not sponsored by the end of the Sponsorship Phase, it will be marked as (Congress Session Number-NS) and moved to the Failed Proposals subforum.


Discussion and Debate
Discussion and debate on proposals may continue during the Sponsorship Phase.

It is not allowed to request that developers not sponsor a proposal, or to demand that developers do sponsor a proposal. Sponsorship is voluntary and should not be subject to undue pressure. The community is the one making the decision on whether or not to approve the changes.


Host Allowance
The Host is permitted to sponsor proposals between the end of the Sponsorship Phase and the start of the Voting Phase. At his discretion, he may allow others to do last-minute sponsorships as well.




Voting Phase
The Voting Phase begins on the 22nd of every Proposal Month at 12 PM CST and ends on the 1st of the next month at 6 AM CST. (Note: The time between 8 AM and 12 PM CST is reserved for processing of proposals prior to the Voting Phase.)

At the start of the Voting Phase, the Host will add a poll to all valid proposals in the Vox Populi Congress subforum.

If a proposal has counterproposals, the Magi will decide which options will be included in the poll (see "Making a Counterproposal", above), and a new thread will be created by the Host for those proposals, which links back to the original thread(s).

Discussion and debate can still continue.

All members of the community have one vote on each proposal thread. Voting will be publicly visible, and votes can be changed until the end of the month.

At the end of the month, the polls and threads will be closed and moved to the Passed or Failed Proposals subforums depending on the outcome.


Criticism, Analysis, etc. of Vote Choices
Listing or calling people out by name to analyze, criticize or insult their vote choices on proposals (unless the person brings up their vote choice themselves first, in which case polite debate is allowed) is not cool. Please don't do it. The reason the voting is public is so that everyone can be confident that the people voting are real people from the community and not a legion of anonymous alternate accounts. It isn't to facilitate any of the above.


Approval Voting
A voting poll will include the main proposal and all counterproposals as options, as well as an option for no changes. Everyone votes for all options they would be happy with, including combinations of options and contradictory options. This method is known as approval voting.

If an option receives at least 25 votes in favor and more votes than any other option, it will be selected. If "no changes" got the most votes, nothing happens. If an option for changes got the most votes, it will be added to the next release of Vox Populi once the coding work for it is complete.


Ties
Tied votes in which Nay is one of the options in the tie are an automatic failure due to lack of a majority.

If there is a tie between two or more non-Nay options, the tie will be broken by a Magi Vote.


Unclear Proposals At Voting Time
If, during the Voting Phase, a proposal's opening post needs to be edited to be made clear to voters, the proposal will be vetoed. The proposer and the Magi are responsible for ensuring that a proposal's text is clear to voters.

Prior to the Voting Phase, clarity edits may be made (even during the Sponsorship Phase).


Voting Thread Title Prefix
The [Vote] unique thread title prefix will be added to Voting Phase threads.


New Proposals and Amendments
No proposals (including counterproposals) or amendments to existing proposals may be made during the Voting Phase.




Implementation Phase
The Implementation Phase begins on the 1st of every Implementation Month at 6 AM CST and ends on the 1st of the next month at 12 AM CST.

During the Implementation Phase, sponsors will code and test their proposals. The deadline for them to be submitted to the repository is the end of the month.

All passed proposals and their sponsors will be noted in the Proposal Queue thread.

If it is discovered during the implementation of a proposal that it is unexpectedly difficult or impossible to implement, has gamebreaking effects, or the AI is unable to handle it:

1. If the proposal can be made feasible with small modifications which don't defeat the purpose of the proposal, it will be implemented in modified form.

2. If this cannot be done, the proposal will be vetoed, unless a lead developer decides to accept the changes as a balance change outside of the VP Congress.

The Host is responsible for making these judgement calls.


Discussion of Game Balance and Future Proposals
During this Phase, it is recommended to use the main forum to debate, discuss and develop game balance and future proposals. The Vox Populi Congress Proposal Workshop thread can be used for this purpose. The Discord server may also be used for this purpose, although it is generally better for brainstorming than detailed discussions.

Implementation By Non-Sponsors
If it appears that the sponsor of a proposal is inactive or will be unable to fulfill it, any community member with the capability to implement a proposal (whether they agreed to be a backup sponsor or not) may do so.

New Proposals and Amendments
No proposals (including counterproposals) or amendments to existing proposals may be made during the Implementation Phase.

New Release
At the end of the Implementation Phase, a new version of Vox Populi will be released. This does not prevent releases from being made at other times.




Playtesting Phase
The Playtesting Phase begins on the 1st of every Playtesting Month at 12 AM CST and ends on the 1st of the next month at 10 AM CST.

During the Playtesting Phase (which lasts one month), players will playtest the changes that have been made during the Implementation Phase (and any made outside of the VP Congress; see below).

This phase is intended for players to have fun, understand and experiment with the changes, discuss balance issues in the main forum, plan out and brainstorm proposals, have discussions with sponsors about what they'd be willing to sponsor, etc. It is focused on community discussion.


Discussion of Game Balance and Future Proposals
During this Phase, it is recommended to use the main forum to debate, discuss and develop game balance and future proposals. The Vox Populi Congress Proposal Workshop thread can be used for this purpose. The Discord server may also be used for this purpose, although it is generally better for brainstorming than detailed discussions.

Playtesting Phase Can Begin Early
If all sponsored proposals are implemented and released earlier than the end of the Implementation Month, the Playtesting Phase begins early.

New Proposals
No proposals (including counterproposals) may be made during the Playtesting Phase.




Balance Changes Outside the VP Congress
The VP Congress is intended to give the community more control over the changes they’d like to see in the mod, so it is ideal to run balance changes through the VP Congress process.

However, with the approval of a lead developer, a balance change can be made outside the VP Congress process by submitting a pull request or pushing code to GitHub.

Lead developers do not have to give this approval if they don’t think the community will appreciate the change, instead directing the proposer to the VP Congress process.

This retains the ability for seasoned developers to contribute to the mod on their own time and schedule (which is necessary for us devs). Balance changes which are added outside of the VP Congress can still be reverted via proposal in the next VP Congress Session, should members of the community be unhappy with them.


Early Integration of Proposals / Changes Which Conflict With Current Proposals
This should only be done sparingly. If a developer pushes a change to the mod on GitHub which affects the same game mechanics as a current proposal, and a lead developer approves it, the Magi will vote on how to handle the situation.

Implementation of Proposals from Previous Sessions
A previously passed proposal which was not implemented is considered a balance change outside the VP Congress; it can be implemented with a lead developer's approval (and generally will be provided the area of balance has not changed that much since the proposal was passed; otherwise, a revote may be required).




The Magi System
This section describes the Magi, the main decision-makers of the VP Congress, in more detail.

The Magi are three members of the Vox Populi community chosen to serve for one year of Congress sessions (four sessions). Each Magus is chosen by the Host via an application process during the June Playtesting Phase of each year.

Three members, rather than a single assistant, are chosen for a few reasons: to ensure a variety of perspectives, to distribute the workload to avoid burnout, and to ensure there are several people able to fulfill the tasks.

Responsibilities by Phase

All Phases During Proposal Months
- Vote on Magi Votes within 24 hours.
- In the event that the Host is temporarily unable to perform his duties, the Magi collectively function as the Host for VP Congress purposes. This may be done by the Host's request, or if the Host is absent and fails to respond to prompting for 7 days.
- Respond to questions and appeals from community members. If any Magus thinks that a decision is worth revisiting as a result of new information or a change in perspective, they should call a Magi Vote.
- Using their expertise of game balance, respond to questions from community members seeking to design or critique proposals.
- Process Sponsorship Registrations (edit the main post in the thread to add new valid sponsors).
- Manage own workload and deliberations. The Magi may pass rules to manage these by majority vote, which will be enforced by the Host upon request.

Proposal & Counterproposal Phase
- Scrutinize new proposals, counterproposals, and amendments and ensure they're compliant with the Congress rules.

- Work with proposers to make sure the text of the proposal is clear and sufficient background information is provided for the community to understand the current state of things and how they're being modified.
- Edit proposals which fail to meet a Formatting Requirement (including renumbering proposals when one is withdrawn or vetoed).
- Unilaterally veto or require changes to proposals which fail to meet a Formal Requirement.
- A Magi Vote is required to do this for proposals which fail to meet a Judgement Call Requirement.
- Designate proposals as approved for fast-track acceptance with the [Fast Tracked] thread prefix.

- List the required skill sets to implement proposals into Vox Populi
- Designate proposals as requiring a supermajority to pass.
- Make judgement calls on whether proposals need to be merged or separated.
- Supervise the mod's balance, and submit counterproposals when it is desired for an alternative should exist to be voted on.

Sponsorship Phase
- Ensure sponsors are registered and capable of sponsoring their proposals.
- Mark proposal threads as [Sponsored] or [Backup Needed] as valid sponsorships occur.
- Make judgement calls on whether proposals affect the same area of balance and should be included as a voting option.
- Decide the list of voting options for such proposals, as well as proposals that have counterproposals.

Voting Phase
- Via a Magi Vote, cast the tiebreaking vote when two or more non-Nay options in a vote have equal vote totals.
- If a developer pushes a change to the mod on GitHub which affects the same game mechanics as a current proposal, and a lead developer approves it, vote on how to handle the situation.

Implementation Phase
- No additional responsibilities.

Playtesting Phase
- No additional responsibilities.


Magi Powers
Each Magus will have the following abilities, which only work in the Vox Populi Congress and its subforums:
- Edit posts/thread titles
- Move threads
- Lock/unlock threads
- Authority to make decisions in the "Responsibilities" section above

These abilities may only be used for their official role. Magi are not site moderators and are not permitted to act as such; they may not delete posts, enforce site rules, use Moderator Action: Moderator Tags etc. If they notice discussions getting out of hand, they should report it to the Host and/or hit the Report button on the relevant post(s).

Any use of these abilities for tasks outside of their role will result in immediate dismissal as a Magus.


Magi Deliberations
The Magi will be provided with their own channel on the Vox Populi Discord server for their deliberations. They will be publicly visible. Other members of the community cannot discuss in the channel directly, but can create threads and send messages there.

In addition, the #petitions channel can be used by any members of the community to post their questions, appeals, or comments, including requesting a review of any decision. Whether the Magi take up individual appeals is at their discretion.

Pestering, abusive behavior, bad faith appeals, etc. directed at the Magi will result in moderation action on the Discord server.


Magi Votes
During Proposal Months, any Magus may call for a Yea/Nay vote in the deliberation channel. This vote must be responded to within 24 hours by the other two Magi during Proposal Months, and within 72 hours otherwise. If necessary, the Host will step in if a Magus fails to vote on time.

Abstention is not permitted: Yea and Nay are the only valid options, and a majority of 2/3 wins, unless the vote is required to be unanimous (see below). However, the vote does not take effect until each Magus has had a chance to explain their point of view on the vote (if desired). The Magi may change or reverse their own decisions at any time with another vote.

If the Magi are unable to reach a conclusion because they lack knowledge about an issue, they should refer the issue to the Host, who will make a ruling.

If a Magi Vote is not unanimous and the Magi in the minority strongly disagrees with the outcome, they may petition the Host to examine the deliberations and make a ruling on the situation, but they should attempt to reach a consensus with the other Magi before doing so. Failure to do so may result in the decision being returned to the Magi for further deliberation.

Appeals by other members of the community are permitted, but the Host's reserve powers will typically not be used unless in his estimation, major errors are being made or the VP Congress System is not functioning to the benefit of the community.


Votes When The Host Has Been Temporarily Replaced
When the Host is unable to handle appeals temporarily, Magi decisions are settled by a 2/3 majority vote (except for proposals which require a Unanimous Vote).

Should the Host disappear indefinitely or permanently, the community will have to decide how to proceed with the VP Congress system.


Unanimous Votes
Certain votes must be unanimous:
- A vote for Fast-Track Acceptance of a proposal.
- A vote to veto a proposal because it modifies game mechanics which are currently bugged.
- Any decision-making vote which involves a proposal that was submitted by one of the 3 Magi.

If even one Magus disagrees with a unanimous vote, the vote does not pass. If a consensus cannot be reached, the Host will make a ruling. If the Host is not available, the vote fails until the Host can be reached.


Magi Composition
The Host shall select three people from the community who are highly active/dedicated based on two factors: merit and conflicting perspectives. The Magi System is intended to encourage debate by selecting members who have different views and opinions on game balance. This internal diversity (and the ability for the member in the minority to appeal the decision if they strongly disagree) is intended to result in better decision-making by considering more perspectives. However, there is still executive oversight should the deliberations get out of hand.

If possible, at least one Magus will be a developer with experience in coding, so as to be able to determine what proposals are feasible to implement. If this is not possible, the Host may need to intervene for such judgement calls.


Magi Selection Criteria (Merit)
Requirements
- Able to be reasonably active in the community
- Able to check in at least once every 3 days during the upcoming months: July, October, January, April
- Able to respond to Magi vote summons within 24 hours during those months
- CivFanatics account in good standing (not known for violating site rules, picking fights, etc. - this will be checked!)
- Discord account & joined the VP Discord server
- Strong knowledge of Vox Populi's game balance
- Strong written communication skills in English
- Willing to make unpopular decisions
- Relatively impartial (the three Magi perspectives should balance out)
- Even-tempered; respectful of others, even if there's a disagreement
- Able to work with the other 2 Magi and the Host
- Able to explain perspectives and opinions in detail and support them with evidence

Assets
- Experience with coding or developing modmods, or knowledge of what is required to implement proposals
- Longer experience within the community
- Strong attention to detail
- Strong memory
- Strong interpersonal skills


Magi Retirement/Replacement/Incapacitation
The Host will select one or more Alternate Magi to step in for any kind of situation like this. If this is not possible, or the Host is unable to find 3 Magi, he will assume the remaining responsibilities himself.
 
Last edited:
maybe consider deferring some proposals this first round. There are so many! Difficult to digest them all in one go
It is quite a few, but it will probably look a lot cleaner once Recursive makes them into polls, as all of the counterproposal threads would be condensed into just a few options. Also we need to keep in mind sponsorship, there are a number of proposals on the board right now that don't have one, if a dev doesn't commit to coding something, it just gets dropped.

So I share your concern that we did get quite a few out of the gate, but I don't think it will look as bad once its tidied up for the actual voting. We will see!
 
maybe consider deferring some proposals this first round. There are so many! Difficult to digest them all in one go
It is quite a few, but it will probably look a lot cleaner once Recursive makes them into polls, as all of the counterproposal threads would be condensed into just a few options. Also we need to keep in mind sponsorship, there are a number of proposals on the board right now that don't have one, if a dev doesn't commit to coding something, it just gets dropped.

So I share your concern that we did get quite a few out of the gate, but I don't think it will look as bad once its tidied up for the actual voting. We will see!

I'd like to try one round of this before making changes to the system if need be.

Though I am making one important change: majority voting is replaced by approval voting, which is a fairer system for simple decisions like these and will stop multiple counterproposals from preventing a change that the majority desires from happening (so, more democracy).

Approval voting is simple: everyone votes for as many options in a set of proposals/counterproposals as they would be happy with (including contradictory options and "no changes"). The option with the most votes wins (I will break ties).

 
Last edited:
Could we introduce the rule that proposal thread titles have to start with a number, and counterproposals start with the number of the proposal they're referring to? That way, by sorting the threads alphabetically, it would be easy to see all (counter)proposals to one topic:

(1) Proposal: Granaries should give more food
(1) Counterproposal: Granaries should ...
(2) Proposal: Nerf Songhai
...
 
Could we introduce the rule that proposal thread titles have to start with a number, and counterproposals start with the number of the proposal they're referring to? That way, by sorting the threads alphabetically, it would be easy to see all (counter)proposals to one topic:

(1) Proposal: Granaries should give more food
(1) Counterproposal: Granaries should ...
(2) Proposal: Nerf Songhai
...
Probably easier to do 1, then 1a, 1b for the counterproposals, as the numbers won't increase as fast. But I like the idea.
 
Could we introduce the rule that proposal thread titles have to start with a number, and counterproposals start with the number of the proposal they're referring to? That way, by sorting the threads alphabetically, it would be easy to see all (counter)proposals to one topic:

(1) Proposal: Granaries should give more food
(1) Counterproposal: Granaries should ...
(2) Proposal: Nerf Songhai
...
Probably easier to do 1, then 1a, 1b for the counterproposals, as the numbers won't increase as fast. But I like the idea.
I have numbered the proposals as such.
 
Are we going to have 50+ proposals on the main forum or should there be a different sub forum specifically for voting?
 
Are we going to have 50+ proposals on the main forum or should there be a different sub forum specifically for voting?
The main forum, but by then I'll have moved all the old threads to the Archive subforum.
 
maybe consider deferring some proposals this first round. There are so many! Difficult to digest them all in one go
This is how it should work for those proposals, that didn't manage to get a Sponsor during the Sponsorship phase. It's not possible that all of them would get a Sponsor if we notice how many Developers VP has. Maybe next sesion someone will decide to support the project, and then it will go under the voting. Instant failure when the Proposal doesn't get the Sponsor might kill some good ideas.
 
This is how it should work for those proposals, that didn't manage to get a Sponsor during the Sponsorship phase. It's not possible that all of them would get a Sponsor if we notice how many Developers VP has. Maybe next sesion someone will decide to support the project, and then it will go under the voting. Instant failure when the Proposal doesn't get the Sponsor might kill some good ideas.
Correct me if I'm wrong, but I assume that a proposal without a sponsor doesn't count as rejected for the purposes of the rule below:
The proposal must not be identical (or very similar to) a proposal that was rejected by the community in last month’s Voting Phase, or which was overturned during ratification within the past 30 days. A substantially changed proposal on the same topic is allowed.
A rejection requires it to go to the Voting Phase in the first place.

If someone's proposal doesn't get a sponsor this session, one can still propose it again next session.
 
Correct me if I'm wrong, but I assume that a proposal without a sponsor doesn't count as rejected for the purposes of the rule below:

A rejection requires it to go to the Voting Phase in the first place.

If someone's proposal doesn't get a sponsor this session, one can still propose it again next session.
If a proposal fails because it lacked a sponsor, it can be proposed again next session. It's only changes that are voted down by the community that can't be proposed again for 30 days.

Does it need to be proposed separately for each session?
It could stay in the subforum for months if that was the case.
 
Correct me if I'm wrong, but I assume that a proposal without a sponsor doesn't count as rejected for the purposes of the rule below:

A rejection requires it to go to the Voting Phase in the first place.

If someone's proposal doesn't get a sponsor this session, one can still propose it again next session.
On Discord is written otherwise.
 
I think we should reconsider the policy on polls in the general forum. I think polls can still be a useful tools as people are crafting proposals and getting a toe in the water on what the community might like. they just won't have any "power" anymore except through teh voting phase.
 
Top Bottom