AVID:Requests for Comment/Proposers cannot vote on their own RFC

From the Audiovisual Identity Database, the motion graphics museum

< AVID:Requests for Comment
Revision as of 19:03, 23 March 2023 by StarlightFantasy (talk | contribs) (Closing as no consensus)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)


The following discussion is closed.
Please do not modify it. Subsequent comments should be made in a new section.

Closing as no consensus. HibiscusCrown20 (talk) 19:03, 23 March 2023 (UTC)

Proposers cannot vote on their own RFC (one proposal only)

I have seen a few users who gave their own requests a vote for it to pass or fail. The issue with this is that it makes them look selfish and manipulative by changing the results of the RFC to their advantage, resulting in an unfair victory for one side. This tactic may possibly be used for RFCs they proposed with little to no traction in order for it to get passed/rejected. Since this rule is not mentioned on the main RFC page, I think it should be stated so that the voting counts are more fair, meaning one side does not get the upper hand because one person who supported/opposed the proposal is the author.

And one last reason: this is like non-staff requesters closing their own RFCs; both may delve into manipulation to get their request to a certain status (snowball closures may also come to mind with these issues).

EDIT: EMG raises a fair point about RFCs with single and multiple proposals. So, the focus of this proposal will shift specifically to those with just one proposal. To add on what he said, multi-proposal RFCs may not clearly state the requester's stance, so it makes sense for them to pick which one to side. Camenati (talk) 03:38, 15 March 2023 (UTC)

Support

  1. Support in the case of a 1-proposal RFC. (Lets chat!) 03:42, 15 March 2023 (UTC)
  2. Support in the case of a 1-proposal RFC per EMG. · Talk · Edits 03:45, 15 March 2023 (UTC)
  3. Support in the case of a 1-proposal RFC. IAmThe789Guy (talk) 15:09, 15 March 2023 (UTC)
  4. Support in the case of a 1-proposal RFC as per above (Talk to Me!) 15:12, 15 March 2023 (UTC)
  5. Support for 1 proposal this was an old Qualitipedia habit. I want to get rid of this. Additionally, for 2+ proposals, this helps with change of opinion as was the case with me removing the Home Entertainment Bumpers section. (Talk!) 15:16, 15 March 2023 (UTC)
  6. Support for both proposals. In order to eliminate all variables of a conflict of interest, all situations need to be covered - and that includes multi-stage proposals. Solarstrike (talk) 06:12, 16 March 2023 (UTC)
    Sounds pretty much like the best solution to me. Gilby1385 (talk) 21:33, 16 March 2023 (UTC)

Abstain

Oppose

  1. Oppose in the case of a multi-proposal RFC, so the creator can make clear their preferred option. (Lets chat!) 03:42, 15 March 2023 (UTC)
    Just to add to this, a user should only be able to vote on ONE proposal of a multi-proposal RFC unless the proposals are all for separate items (Lets chat!) 05:16, 17 March 2023 (UTC)
  2. Oppose in the case of a multi-proposal RFC per EMG. · Talk · Edits 03:45, 15 March 2023 (UTC)
  3. Oppose in the case of a multi-proposal RFC per everyone above (Talk to Me!) 15:13, 15 March 2023 (UTC)
  4. Oppose on all counts. I believe this proposal is fundamentally flawed and supports are piling on without considering a broader perspective. These are my counterarguments.
    • There is nothing selfish nor manipulative about standing behind an idea you have. That is an aggressive and frankly insulting insinuation to base this RfC on and is much of why I decided to oppose in depth. You could argue that in one sentence though I don't think it quite makes the point: Just because you suggest something doesn't mean your input, your personal want on the subject should be discounted or void. Coming up with the idea =/= seeing it through by vote, in the limited way you can (your vote balanced by the determination of the community).
    • The loophole is inherent in the modified proposal: you can support one of multiple ideas. What's the difference? A proposer can imply what they like from the start and put their vote in to stack towards it. There's something unfair about stripping someone's personal vote because there's 2-3(+ abstain/neutral) sections but it's suddenly okay because the number is 6, 9, whatever instead. This doesn't seem consistent to me. Then there are other scenarios. Maybe you only made the single-item RfC to give the idea a chance and wanted to express something nuanced, ie, abstain, no vote but give the idea a chance, or not vote as an expression of neutrality. You could formulate the original post based on certain facts and have a more nuanced opinion in your original vote. The RfC itself is not forced to state the requestor's in depth opinion. It can and does already including on multi-section proposals.
    • The impact of the proposer's vote doesn't stack a meaningful outcome. A meaningful RfC involves at least 4, 5 other people and anything less isn't an idea with traction to close as having consensus. It would be so minor that staff could have done it by their own pleasure, a tiny voting pool is not representative of the community. If the line in a larger RfC is thrown by a single vote then it was already a mixed result and evidently the idea had merit enough to make it to the line. If the idea was good then it will be stacked in support; if not then a self-vote won't save a thing. When disputed to the point of +/- one vote, I say you should call for bureaucrats and rely on their conclusion based on what was argued and the merits of the idea/consequences of its implementation since a line that narrow is already a weak result.
    • "It's like non-staff requesters closing their own RFCs" - no it isn't. Voting isn't determining consensus on a topic. One is your personal impact and the other is the resolution of what quite a few people think about whatever thing is being discussed, and in some cases, determining the viability and execution of that idea, again a completely different matter than standing by your suggestion.
    • "snowball closures may also come to mind with these issues" - how?
    • "this was an old Qualitipedia habit" - this happens on Meta and Wikipedia too. This isn't just another qualitipedia thing. There's plenty of those otherwise - one of them is the stacking of votes when the RfC has presented faulty ideas in need of refinement or challenge.
    This isn't to criticize the original poster in general as I've seen decent RfCs from them, but I thought this one needed a step against snowballing without further considering what the proposal says. --Raidarr (talk) 22:58, 18 March 2023 (UTC)
    Thanks for using my reason as a counterargument, as I got reminded for this. (Talk!) 14:03, 19 March 2023 (UTC)
  5. Originally supported for 1-proposal RfCs and opposeed for multi-proposal RfCs, but changed to Oppose on all counts after reading Raidarr's rationale. · Talk · Edits 23:33, 18 March 2023 (UTC)
  6. I am switching to a full Oppose, after having read Raidarr's explanation. (Lets chat!) 11:17, 19 March 2023 (UTC)

Comments

  1.  Comment: I would like to retract this proposal after reading Raidarr's reasoning. Camenati (talk) 23:40, 18 March 2023 (UTC)
  2.  Comment: AAAAAAAAAAAAAAAAAAAAA, yeah I'm just dropping a comment here, mainly because I'm not sure what to think of this. Other reasons, well, I'm leaving them unexplained.
    OK but really idk why I typed this in 14:07, 19 March 2023 (UTC)

The above discussion is preserved as an archive.
Please do not modify it. Subsequent comments should be made in a new section.


Retrieved from "https://www.avid.wiki/AVID:Requests_for_Comment/Proposers_cannot_vote_on_their_own_RFC?oldid=492479"
Cookies help us deliver our services. By using our services, you agree to our use of cookies.
More information