UDWiki talk:Administration/Policy Discussion/Revised Historic Group Policy: Difference between revisions

From The Urban Dead Wiki
Jump to navigationJump to search
mNo edit summary
 
(3 intermediate revisions by 2 users not shown)
Line 20: Line 20:
::::I think it would be a good idea to clarify the two different meanings that we are applying to 'meatpuppets'. TripleU and yourself have described a form of historical voting as meatpuppeting, but I don't agree that is the case. To me, a meat puppet is somebody who is invited onto the wiki with either a fresh or functionally fresh account to vote on something on UDWiki that is unrelated to their interests or expertise. For example, voting on something related to UDWiki's core function or something they'd otherwise not care about.  
::::I think it would be a good idea to clarify the two different meanings that we are applying to 'meatpuppets'. TripleU and yourself have described a form of historical voting as meatpuppeting, but I don't agree that is the case. To me, a meat puppet is somebody who is invited onto the wiki with either a fresh or functionally fresh account to vote on something on UDWiki that is unrelated to their interests or expertise. For example, voting on something related to UDWiki's core function or something they'd otherwise not care about.  
::::I do not consider what has been referred to above as meatpuppeting. Someone coming onto UDWiki to vote their own group in as a show of support for the group's off-wiki impact should not be considered meatpuppeting. In fact, I consider it a core part of UDWiki that should be encouraged (when it pertains to UD-related things). Extrapolating from that, I agree with your hypothetical argument that a group that can't meet an arbitrary attendance threshold, they shouldn't be considered historical. Not because it's the best way, but because it's the same threshold that every other historical group has needed to surpass to be admitted. Should that threshold be scaled to be made fair? Possibly. But I don't think it should be eliminated. {{User:DanceDanceRevolution/sig5}} 03:12, 9 July 2024 (UTC)
::::I do not consider what has been referred to above as meatpuppeting. Someone coming onto UDWiki to vote their own group in as a show of support for the group's off-wiki impact should not be considered meatpuppeting. In fact, I consider it a core part of UDWiki that should be encouraged (when it pertains to UD-related things). Extrapolating from that, I agree with your hypothetical argument that a group that can't meet an arbitrary attendance threshold, they shouldn't be considered historical. Not because it's the best way, but because it's the same threshold that every other historical group has needed to surpass to be admitted. Should that threshold be scaled to be made fair? Possibly. But I don't think it should be eliminated. {{User:DanceDanceRevolution/sig5}} 03:12, 9 July 2024 (UTC)
:::::I could respond that meatpuppeting to get a group to pass historical voting just turns it into a popularity contest. But, it ''is'' a popularity contest, and perhaps meant to be one from the start. If historical groups were meant to be objectively determined, you wouldn't use voting. Anyways. --{{User:A Helpful Little Gnome/Sig}} 20:22, 13 July 2024 (UTC)


It's worth noting that, with the current criteria, 14 yeses would fail, but 10 yeses and 5 nos would succeed. Surely we do not want a system in which people showing up to vote no causes the vote to pass and people refraining from voting no causes the vote to fail. If we end up deciding to keep a vote minimum, we should at least change the minimum from 15 votes to 10 yes votes. --{{User:TripleU/Sig}} 03:50, 8 July 2024 (UTC)
It's worth noting that, with the current criteria, 14 yeses would fail, but 10 yeses and 5 nos would succeed. Surely we do not want a system in which people showing up to vote no causes the vote to pass and people refraining from voting no causes the vote to fail. If we end up deciding to keep a vote minimum, we should at least change the minimum from 15 votes to 10 yes votes. --{{User:TripleU/Sig}} 03:50, 8 July 2024 (UTC)
:A funny quirk, to say the least... {{User:DanceDanceRevolution/sig5}} 03:12, 9 July 2024 (UTC)
:A funny quirk, to say the least... {{User:DanceDanceRevolution/sig5}} 03:12, 9 July 2024 (UTC)
== A different take ==
Obviously late to the party here (A/PD isn’t on my watchlist these days), but it seems like there are several valid concerns that could be solved with a policy update that simply had the following stipulations:
# '''2/3 must vote Yes'''
# '''Voting lasts 4 weeks'''
# '''At least X people must vote Yes, where X is the lesser value between:'''
## '''10'''
## '''1/3 the active, unblocked wiki users at the time voting closes'''
To explain:
* Keeping the supermajority just makes good sense.
* Extending the period gives more time to rally.
* Tying the number of votes required to Yes instead of the total ensures that someone adding a No vote won’t help a bad entry pass.
* Using 10 for the Yes count actually matches the existing policy (i.e. 10 Yes == 2/3 Yes from 15 total)
* In much the same way that sane economies tie minimum wage to inflation, the use of a value that’s pegged to active users so that it deflates with user shrinkage ensures that the policy can remain relevant, and may actually provide a framework for similar updates to other policies or rules in the future.
** I pulled 1/3 out of my ass, but it seems reasonable enough and would result in the minimum number of Yes votes required being 7 right now, which seems about right.
* Using the lesser value between the two not only allows for it to shrink, it also ensures that an attempt at rallying active accounts to deny a successful vote will be extremely limited in its effectiveness. In most cases, they’d be better off just voting No, which would be fine.
As for MOB, just re-hold the vote after the policy update passes. I don’t see a need to grandfather them in, though I’d be fine with something applying retroactively if that’s a hang-up for others. {{User:Aichon/Signature}} 05:57, 10 July 2024 (UTC)
:I think everyone's fine with voting being increased to 4 weeks. For the other points, looks like we're all fine with a reduced threshold for success. But not to the extent that you only need 1 vote (e.g., only 1 yes vote, no other votes at all). --{{User:A Helpful Little Gnome/Sig}} 20:15, 13 July 2024 (UTC)
::I generally like the take, but I also agree with Gnome. Maybe set a minimum of 3 votes, so that not simply anyone and their one buddy can rubberstamp any random group to Historical status. --'''<span style="font-family:monospace; background-color:#222222">[[User:Spiderzed|<span style="color:Lime"> Spiderzed</span>]][[User talk:Spiderzed|<span style="color:Lime">▋</span>]]</span>''' 16:47, 23 July 2024 (UTC)

Latest revision as of 16:47, 23 July 2024

I would double check that there's no errant low-vote-but-100%-positive historical group nominations other than the one in question. --  AHLGTG THE END IS NIGH! 23:21, 29 June 2024 (UTC)

Couldn't we make it retroactive only through 2024, so we don't have to do an archeological dig? --VVV RPMBG 04:13, 30 June 2024 (UTC)
Yes. --  AHLGTG THE END IS NIGH! 00:28, 3 July 2024 (UTC)

In my opinion, the minimum vote requirement should be abolished entirely. The functionality of the system should not be allowed to decline as we go deeper into the long tail in the years to come. If there's a concern about this making historical status too easy to achieve, we could increase the required supermajority from 2/3 to 3/4. To preserve turnout, I also propose extending the time limit from two weeks to one month. There's no need to rush this kind of vote. --VVV RPMBG 04:13, 30 June 2024 (UTC)

I'm okay with this change too. Maybe I have a preference for 3/4 if there's no minimum vote number requirement. --  AHLGTG THE END IS NIGH! 00:28, 3 July 2024 (UTC)

I suspected this is what the policy would suggest and honestly, I disagree. The potential effects of removing a bare minimum standard like this on a dead website could open up all sorts of potential for abuse. To me, this isn't a problem that needs fixing. It's 15 votes for god's sake, just make a new vote for MOB and ask a few more people on discord. I'll even @ everyone on #udwiki. DANCEDANCEREVOLUTION 11:00, 7 July 2024 (UTC)

That's what they said about the APD voting change. Wink --  AHLGTG THE END IS NIGH! 15:08, 7 July 2024 (UTC)
And it then allowed them to accept a similarly themed proposal to this one, which (sorry to be cruel) was, in my opinion, again an awful decision with real potential issues and no real benefit. DANCEDANCEREVOLUTION 06:01, 8 July 2024 (UTC)
Might argue that a lack of edits doesn't mean inactivity, just that there isn't much to edit. And that that policy just removes the tedium of making a necessary 12 edits to make an otherwise active but technically in-active sysop eligible for A/BP. (Though a minimum 1 edit per month would have also been an appropriate change.) --  AHLGTG THE END IS NIGH! 14:18, 8 July 2024 (UTC)
You're right, a 1 edit minimum would have enabled someone like Ross who is "inactive but available" to be eligible for an election but locked out sysops who literally could not have performed their crat roles for 4 months until they 'idle out'. I woulda preferred that. DANCEDANCEREVOLUTION 03:12, 9 July 2024 (UTC)
This may have been a bare minimum standard a decade ago, but nowadays, it's the most difficult criterion to meet. Today, Special:ActiveUsers only lists 21 non-blocked users. As that number continues to decline, a vote minimum is only going to get harder to meet. Our duty is to keep this wiki as functional as possible for as long as possible, even when there are only 10 active users, even when there are only 5 active users. You said you worry about potential for abuse. What form of abuse are you concerned about? Perhaps we can design a policy that can reduce those risks. If you worry that a vote will sneak by unnoticed, we can extend the voting deadline beyond two weeks. If you worry too many groups will qualify, we can increase the required supermajority beyond 2/3. If you worry that it will become too easy for groups to meatpuppet themselves into historical status, I worry that under the current system it is only possible for a groups to become historical if the meatpuppets show up; See the vote for East Becktown Defenders. Tell us what problems you worry about, and we'll work to address them, just like we're working to address the problem of there being too few users to meet the vote minimum. --VVV RPMBG 03:50, 8 July 2024 (UTC)
It's prob worth noting that without the MOB vote, those 21 active users over the past 30 days would be 16. 5 of the 9 MOB voters were users that wouldn't have edited on UDWiki otherwise. You may see this as a bad thing. I think however that it's impressive that with (what I assume was) minimal rallying on other platforms, the vote managed to get a third of the minimum votes just from randoms. Honestly, I see that as fairly in line with the way historical voting has always gone - it's always been dependent on outside rallying from the nominated group in question because the active userbase of UDWiki has not been designed to be the sustaining part of Historical Groups voting for a long time. For example, what you describe as a meat puppet session with East Becktown Defenders, is functionally how almost all non-shoe-in nominations have gone for over 10 years, and again, I see that as an appropriate filter for groups to have to breach to get into historical status. I don't think MOB can't achieve this. Just renominating and having a sysop @all the discord, you'd make 15 votes easily. But I see all of the above as a feature, not a bug. And I see the minimum requirement needs to exist because there's only 15 active users a month, not despite it.
In a less symbolic sense though, yes, I think there are issues with implementing this and you've touched on the big one with people 'sneaking' through a vote. 16 users in 30 days means removing the minimum may genuinely pose an issue with sneaking through unworthy groups with 3 votes during times of extreme slowness. 16 users in 30 days means extending it from 2 weeks to 4 weeks may not matter. And if it fails, they could probably just put it up again a week later, multiple times. etc etc...
I'm not against change. The 100% requirement is good, but when the next MOB vote is 90% yes, one no, and still doesn't hit the threshold, what then? We'll presumably end up here again over the minimum requirement. Why not just reduce it to 10 or something? Even 5 is better than nothing. But nothing would be bad. DANCEDANCEREVOLUTION 06:01, 8 July 2024 (UTC)
Suppose it could be argued that if you can't get 15 people to meatpuppet a historical group, the group isn't really notable. Also possible that the group really is worthy, but that most people who knew about it were long gone. You would want a system that wouldn't forget about these old-but-historical groups. I'm convinced we need to lower the minimum threshold somehow... the drop in userbase has been massive over the years. Could be minimum 10. Or 7. Or 5. But I think regardless, we should have the voting up for 4 weeks to give more chance for occasional wiki users to see the voting. And you could make things retroactive to MOB. --  AHLGTG THE END IS NIGH! 14:46, 8 July 2024 (UTC)
If I want to be the devils advocate here, you could solve the "it's now 5 votes min and 5 randoms got their random group in because no one was around to notice" problem by requiring that some voters be themselves active by some criteria. --  AHLGTG THE END IS NIGH! 14:46, 8 July 2024 (UTC)
I think it would be a good idea to clarify the two different meanings that we are applying to 'meatpuppets'. TripleU and yourself have described a form of historical voting as meatpuppeting, but I don't agree that is the case. To me, a meat puppet is somebody who is invited onto the wiki with either a fresh or functionally fresh account to vote on something on UDWiki that is unrelated to their interests or expertise. For example, voting on something related to UDWiki's core function or something they'd otherwise not care about.
I do not consider what has been referred to above as meatpuppeting. Someone coming onto UDWiki to vote their own group in as a show of support for the group's off-wiki impact should not be considered meatpuppeting. In fact, I consider it a core part of UDWiki that should be encouraged (when it pertains to UD-related things). Extrapolating from that, I agree with your hypothetical argument that a group that can't meet an arbitrary attendance threshold, they shouldn't be considered historical. Not because it's the best way, but because it's the same threshold that every other historical group has needed to surpass to be admitted. Should that threshold be scaled to be made fair? Possibly. But I don't think it should be eliminated. DANCEDANCEREVOLUTION 03:12, 9 July 2024 (UTC)
I could respond that meatpuppeting to get a group to pass historical voting just turns it into a popularity contest. But, it is a popularity contest, and perhaps meant to be one from the start. If historical groups were meant to be objectively determined, you wouldn't use voting. Anyways. --  AHLGTG THE END IS NIGH! 20:22, 13 July 2024 (UTC)

It's worth noting that, with the current criteria, 14 yeses would fail, but 10 yeses and 5 nos would succeed. Surely we do not want a system in which people showing up to vote no causes the vote to pass and people refraining from voting no causes the vote to fail. If we end up deciding to keep a vote minimum, we should at least change the minimum from 15 votes to 10 yes votes. --VVV RPMBG 03:50, 8 July 2024 (UTC)

A funny quirk, to say the least... DANCEDANCEREVOLUTION 03:12, 9 July 2024 (UTC)

A different take

Obviously late to the party here (A/PD isn’t on my watchlist these days), but it seems like there are several valid concerns that could be solved with a policy update that simply had the following stipulations:

  1. 2/3 must vote Yes
  2. Voting lasts 4 weeks
  3. At least X people must vote Yes, where X is the lesser value between:
    1. 10
    2. 1/3 the active, unblocked wiki users at the time voting closes

To explain:

  • Keeping the supermajority just makes good sense.
  • Extending the period gives more time to rally.
  • Tying the number of votes required to Yes instead of the total ensures that someone adding a No vote won’t help a bad entry pass.
  • Using 10 for the Yes count actually matches the existing policy (i.e. 10 Yes == 2/3 Yes from 15 total)
  • In much the same way that sane economies tie minimum wage to inflation, the use of a value that’s pegged to active users so that it deflates with user shrinkage ensures that the policy can remain relevant, and may actually provide a framework for similar updates to other policies or rules in the future.
    • I pulled 1/3 out of my ass, but it seems reasonable enough and would result in the minimum number of Yes votes required being 7 right now, which seems about right.
  • Using the lesser value between the two not only allows for it to shrink, it also ensures that an attempt at rallying active accounts to deny a successful vote will be extremely limited in its effectiveness. In most cases, they’d be better off just voting No, which would be fine.

As for MOB, just re-hold the vote after the policy update passes. I don’t see a need to grandfather them in, though I’d be fine with something applying retroactively if that’s a hang-up for others. Aichon 05:57, 10 July 2024 (UTC)

I think everyone's fine with voting being increased to 4 weeks. For the other points, looks like we're all fine with a reduced threshold for success. But not to the extent that you only need 1 vote (e.g., only 1 yes vote, no other votes at all). --  AHLGTG THE END IS NIGH! 20:15, 13 July 2024 (UTC)
I generally like the take, but I also agree with Gnome. Maybe set a minimum of 3 votes, so that not simply anyone and their one buddy can rubberstamp any random group to Historical status. -- Spiderzed 16:47, 23 July 2024 (UTC)