This gives a much lenient window for scam bug squashing; scam bugs are hard to spot and in the current system we can’t depend on the 8 hour edit window; scammers can do a preemptive vote to close the window.

Would be interesting to know if any players would say that they’d expect to cast these kinds of early votes. Would there be implied pressure on an early FOR voter to check back later to see if they still approved, or would we be happy about people absently leaving early votes in place after a proposal had (even quite openly) added a controversial rider or pivoted to something entirely different?

“Whenever an official post is edited, the author must make a comment to the post describing the changes made in the edit.” might be a bit strict - I know I sometimes correct mistakes or change my mind about bits of my own proposals immediately after posting them, which would be boring for everyone to have to read an edit-by-edit account of, but maybe that’s just me. I guess there are also cases where an official post is edited by an admin (either closing the proposal, or enacting one of those rare CfJs that amend other posts), which the author shouldn’t have to do anything about.

Re. the comments - don’t we have something somewhere that allows us to combine several gamestate changes into one update? In any case I would expect that a single comment summarising five minutes of tinkering would fail to elicit much controversy and would be arguably compliant with the rule as written.

I don’t think we’d want to weaken anything that enforces the principle that edits have to be signposted.

Oh, it would always be one proposal edit at a time, each one made under the mistaken conviction that nothing else will need to be changed afterwards (until I notice another typo or redundancy or have second thoughts about a particular number, two minutes later). Maybe I’m in a minority for idly polishing a proposal once it’s gone up, though. And pressure to get the first draft right certainly isn’t a bad thing.

strongly opposed to the idea that I can vote for something, the proposal changes, and now I’m voting for something I’ve never read.

imagine a scenario where someone makes a proposal called “Give everyone on the blue team one point”. Quorum is say 5. Two blue teamers vote on it then go to bed. Three hours after its posted it switches to “Give everyone on the red team one point”. Now all you need is two red teamers to vote on it below the blue teamers wake up and realize its changed.

if we’re worried about making changes after people have voted, maybe give a “fast kill” window where if you kill a proposal soon enough after making it you get a slot back?

@Clucky I would never support any proposal that starts screwing with the way that the queue enacts.

I don’t know how other people play the game; I find it implausible that sometime could edit their proposal to completely change its meaning within a 4h window and not have enough people notice to defeat it unless the game had other, more serious health problems, especially with the 12 hour minimum window for popularity. Part of the reason for the comment on this is to test my own assumption on this matter, though.

Clucky’s red/blue thing seems plausible enough. If two blue players vote early and drop offline for 12 hours, it doesn’t matter if everyone else notices the 4-hour pivot and votes frantically against it, the scammer has got quorum. It doesn’t even need to be a “blue team wins” proposal, it can be anything that a couple of sleepy players have voted on.

we could consider having the comment clear the validity of all votes cast before the comment was made. that way you don’t need to worry about voting FOR something you don’t actually support, but that might be a bit of a pain to properly admin.

I did think of that but it not only makes admining hard, but it makes it not visually intuitive whether someone has voted or not.

So what if just, you can get a third proposal slot if you have a pending proposal that you have voted against within 4 hours of making the original proposal?

that wouldn’t mess with the queue at all. But would make it less annoying to discover an error in your proposal after someone voted on it.

It doesn’t do anything about the 8 hour edit window bogging down the queue; it just means that more proposals are waiting for 8 hours to elapse.

The objective here is to defray the etiquette around sitting and silently watching a proposal for 8 hours before you’re allowed to vote for it; there’s no way of doing that I can think of without at some point allowing voting during the edit window.

Reducing the 8 to 4 might help? Not sure that it completely solves the problem and give than both Kevan and ais seem to think that 12 hours is the smallest meaningful unit of time in BN I don’t think it would be that popular.

Me, I was a big fan of the original two hours (I voted against Ais changing it to eight) and would be happy to go back to that.

Etiquette-wise, back when the window was six hours Cuddlebeam would say “greentick” to signify that they’d read the proposal, liked it and saw no problems with it. Which was helpful, but I don’t remember it being adopted by anyone very much else - perhaps because saying “I think this is ready for voting” (and potentially prompting others to do so) isn’t that different to actually starting the voting yourself.

:D

because it’s not ridiculous for a proposal to become Popular within 4 hours (imagine an Emperor’s first proposal in a new dynasty), and this would open up a scam in which it could be edited to do anything before enacting it.

Re: Clucky’s “fast kill” idea, we experimented with something like that for a while (giving the Emperor discretion as to whether the proposal deserved to gain the slot back), and I was a huge fan of it, but most players disagreed with me so I got outvoted on it. (One issue is that it perhaps lead to more Emperor discretion than many Emperors were comfortable with, so perhaps having an objective view will be better.)

@ais Proposals currently have to be open for a minimum of 12 hours before they can be popular, so you’re nightmare scenario isn’t possible.

i do the edit-a-few-times-right-after-posting thing too

[ais523] I think the main issue with allowing (even a single) fast self-kill is that it splits the voting discussion. If I propose something and someone has spotted a loophole, I can self-kill it, shut down that discussion and repost it as a v2 or v3. Not everyone voting on the final version is going to bother going back and reading earlier closed discussions, and a returning commenter’s “hey, this still has the loophole!” might come too late.

It also has the exhaustion problem of the 8-hour edit window - voters are expected to reread a proposal in depth a second time, to check that it’s not doing anything the first version wasn’t doing. Self-killing is a little better than the edit window because players can (if they know how to) at least do a side-by-side diff to see whether a “fixed to use the correct terms for map squares, sorry everyone!” version actually snuck a scam into a boring mid-proposal paragraph, but it’s still a bit tiring.