All gameplay changes need to be tested on a server first

[DolceTriade]

This is a proposal to codify that all gameplay changes should be gameplay tested on a custom server and get some play tests and mileage on them before merging.

This issue is to help crystallize the criteria that would make a gameplay change acceptable.

Some open questions:

• Who gets a vote (developers only? developers, contributors? everyone?) (ofc everyone can give input...)
• What percentage of acceptance does a change need to get merged?
• What constitutes a gameplay test?

My propsoal is:

• Only developers and contributors get a vote
• A simple majority is sufficient to merge a change
• A gameplay test is any custom server that gets 10 or so gameplay tests that include human only games and receive positive feedback from the players who play on it. The "test" doesn't need to be only the feature being tested.

[necessarily-equal]

I like the idea. Just a quick note:

A gameplay test is any custom server that gets 10 or so gameplay tests that include human only games and receive positive feedback from the players who play on it.

I think this may be a strong requirement

[sweet235]

all gameplay changes should be gameplay tested on a custom server

I agree from the depths of my heart.

I think this may be a strong requirement

As long as we have most games with regular users going on on one or two popular servers, it is too strong a requirement. It would effectively give the server maintainers an absolute veto power.

I have no idea how to fix this.

[DolceTriade]

I suppose having a few games of the feature and having it show promise is sufficient to merging tbh.

It doesn't need to be amazing. Just needs to show promise such that eligible voters vote to merge it.

[sweet235]

And I will certainly try to make this possible on my server. But I serve two masters here, the other master is the regular users.

[Viech]

In the meantime I have added the [poll] label and issue type to have something like a vote (though naming it poll as opposed to vote is intentional) for minor changes but I would be wary to use votes or even polls for anything bigger, in particular with a majority rule replacing discussion and compromise.

There are many scenarios in which a vote can be given to the detriment of the game:

• someone hates the problem being resolved and has a bias towards any change
• someone likes what is being changed and has a general bias against any change
• someone's vote is affected by their standing with the developer
• someone took a shower, came up with an alternative idea, and wold prefer this over the proposed change which may have undergone hours of planning, implementation, and (local) testing that the shower thought would not withstand (personal shower experience)

In theory, all of this can impact also a discussion but is less likely to prevent consensus or compromise. Operationally, vouching with a LGTM is more involved than giving a thumbs up while writing a criticism is more valuable than giving a thumbs down.