The next release (a week from Monday) will include a useful new feature: extending the expiration of edits that receive ‘No’ votes! I’d like to take a bit to explain how it’ll work.
The problem
Especially since the amount of time edits stay open was reduced to 7 days, but also before, several problematic situations could arise when edits were contested:
- If voters cast ‘No’ votes shortly before the expiration of the edit, the original editor may not have time to respond to the concerns before the edit closes. As a result, it’s generally been considered bad etiquette to cast ‘No’ votes right before an edit expires unless the edit is particularly destructive.
- In a somewhat related case, sometimes an edit can get many ‘No’ votes in short succession. Since 3 unanimous ‘No’ votes will close an edit, the period between the first vote cast and the edit being closed can be as short as an hour, which is certainly not enough time for the original editor or other voters to respond.
- It’s also occasionally possible for edits to be put at risk of failing without an email being sent. Specifically, the current code only sends an email on the very first ‘No’ vote. Therefore, if a voter votes ‘No’ early in the voting period and later changes their vote, a second voter later voting ‘No’ would not result in an email being sent. However, a tied vote or a majority of ‘No’ votes will result in an edit being closed, so even a lone vote can tip the balance.
The solution
In light of all of these problems, the next release will work differently to give editors time to respond to votes against their edits.
In short: editors will always have at least 72 hours (three days) to respond after the first vote against their edits.
More specifically, and more technically:
To address the third point above, the emails for ‘No’ votes will now be sent whenever the count of ‘No’ votes goes from 0 to 1. That is: if two people vote ‘No’ with neither changing their vote in-between, only one email will be sent. But, in a case like the one described above, where an early ‘No’ vote is superseded and the total count goes back to 0, a subsequent ‘No’ vote will send a new email.
To address the second point above, ModBot will not reject an edit before its expiration time due to three unanimous ‘No’ votes unless 72 hours have passed since the earliest ‘No’ vote (that is, the vote which resulted in an email being sent). If the expiration time passes or an edit has three unanimous ‘No’ votes after 72 hours, the edit will be closed as usual.
Finally, to address the first point above, when new ‘No’ votes are cast close to an edit’s expiration time, the edit’s expiration time will be extended to allow 72 hours for response. This extension will, once again, only happen when the total count of ‘No’ votes goes from 0 to 1 – so only when an edit becomes contested and previously was not.
In total, these changes should hopefully ensure that editors are better informed about edits that are in danger of being voted down, and given sufficient time to respond to voter concerns.
In summary
First of all, this change will be fully live on Monday, June 24th. Before then, votes cast on the beta server may result in a small number of edits having their expiration times extended, but it won’t happen on the main server or for the majority of edits.
While editing: Rest assured you’ll be informed and given time to fix problems with your edits!
While voting: Don’t worry too much about casting ‘No’ votes when edits need improvement. Certainly be ready to supersede your votes if things do get fixed up, but if you find an edit in need of fixing just before it closes, or which already has a bunch of recent ‘No’ votes, don’t hold back or vote differently to give the original editor time to respond. This should take care of that for you!
Happy editing!
MetaBrainz Blog 