The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.
No consensus to implement this. That being said, it's not a terrible idea, in theory, since many wikis have few contributors, and, arguably, a constructive contributor, being the only active contributor, to a wiki is a better indicator than a user who has made only one edit to a wiki, the edit for which is to hold a local election. This would need further ellucidation on the details, though. Dmehus (talk) 22:39, 30 January 2022 (UTC)
Proposal 1: [allow users to get admin when adopting a wiki][edit | edit source]
[Proposal 1 content] Snail destroyer (talk) 18:18, 25 January 2022 (UTC)
i feel like u should get admin when adopting a wiki just normal admin perrimsons removing that was dumb cus then its not even adopting it its more just opeining it
Strongest oppose This RfC is rather messy, and the nominator has received multiple warnings for disruption prior to this creation. I'm not quite sure what this user is trying to accomplish here, but this is awkward writing, especially if you count the spelling errors that are in this RfC. This is bound to be snowballed at anytime. --DarkMatterMan4500 (talk) (contribs) 18:44, 25 January 2022 (UTC)
Oppose Per the above voters' reasonings. This doesn't seem like a well formatted proposal in all honesty. Hypercane (talk) 00:16, 26 January 2022 (UTC)
Oppose Ill-defined proposal per Agent Isai. The preload isn't even filled in properly! Anpang📨 06:51, 26 January 2022 (UTC)
Comment: This one looks like a snowball. I'd like that, but you didn't provide many reasons for the proposal. You should have consulted the community properly too. Otherwise it could be snow. --YellowFrogger (talk) (✔) 18:24, 25 January 2022 (UTC)
To clarify the user's proposal above, which snowballed (because didn't make an ad beforehand or because it was poorly formatted), I'll clarify. After an RfC, users who "adopt" the wiki can no longer be bureaucrats and administrators, instead the wiki is just reopened by a steward, and in order to gain the rights the user has to make a local election (in wiki you want to adopt) (that lasts at least 1 week).
We want to undo this idea because:
The name "adoption" no longer makes sense after that. The page can now be called "requests for reopen", but it is no longer possible to adopt. This is bad because:
Closed wikis, most of the time, are abandoned by bureaucrats, (or they just got tired of it). Also, the wiki doesn't even have a community (in closed wikis). The person who wants to adopt wants to redo the wiki (especially if the request is in good faith).
Election on closed wikis (or reopened by stewards), results in little most of the time. The user makes an election in a deserted location, with no community. And, if a malicious person votes against it, the user won't have the chance to enjoy the wiki he wanted so badly to adopt (and, imagine if he contributed a lot?).
Please provide more opinions against this, you who are in favor of disabling this rule. --YellowFrogger (talk) (✔) 00:33, 26 January 2022 (UTC)
Strong oppose Personally, I don't believe adoption should equal automatic rights. That means a random person can come along and, without having contributed at all, can now basically takeover a wiki. What if this user doesn't contribute at all to this wiki? Instead of having 1 inactive bureaucrat, now you'd have 2. If anything, I think we should revert to the old system of Stewards assigning rights only after 2 weeks of constructive upbuilding from the adopting user. But even after that, what's the issue with having to wait 1 week to gain rights via the process of a local election? Your ultimate goal of building a wiki should not be hindered by the fact that you have no rights and if it is, I'd suggest you're hat-collecting (remember to wear your hats!). The current process of having to hold an election is, in my opinion, a good one as it serves as a notice that someone is contending for rights. Sure, users usually win by acclamation but at the same time, if there is an actual local user who opposes for valid reasons, they are able to express their concern and be heard. Do remember too that !votes do not equal consensus. As part of the consensus determination process, Stewards don't simply count !votes and determine consensus from there. Instead, Stewards weigh all arguments and weigh votes with solid arguments heavier than simple !votes without a reasoning/with a small, lacking reasoning so a simple !oppose vote to a request for local rights lacking a solid basis (or any reasoning accompanying it) is unlikely to affect the local request for rights. Also, I would like to note that the recent Dormancy Policy RfC actually did not undo the "old system" in which users gained rights when adopting. As pointed out on IRC, it seems that that process was added into the Dormancy Policy against consensus so if anything, the recent "change" to the Dormancy Policy actually fixed a mistake in the policy. Agent IsaiTalk to me! 01:42, 26 January 2022 (UTC)
I understand very well your point on rights over users who have never contributed to the wiki. But, what about the users who edited for a long time? If so, I prefer the system you cited (stewards give rights to users who contributed to the wiki for at least 2 weeks), or else provide rights to users who contribute anyway. The problem with waiting 1 week is that the wiki is practically deserted. It's good that you mentioned that stewards don't count votes (about the part that a malicious user can unfairly vote against, even against a user who contributes a lot), so you mention that it's for this case? Even so, I don't think this is hat collection, as it only includes two privileges that are needed to administer the wiki (and especially if it's only done once). --YellowFrogger (talk) (✔) 02:26, 26 January 2022 (UTC)
Oppose I agree with Agent above, I don't think rights are needed to build a wiki. I'm more inclined to let users be locally elected versus just automatic appointments via this proposed method. My suggestion to anyone (especially less experienced users) is to request admin rights via local elections first. Then if and when you feel more comfortable to request bureaucrat rights. It just makes it easier to adjust a bit (at least I'd think.) Anyways, I believe that is my take on this matter. Hypercane (talk) 03:10, 26 January 2022 (UTC)
Oppose Per Agent Isai and Hypercane. YellowFrogger, don't mess with this one now, I know... Anpang📨 06:52, 26 January 2022 (UTC)
Whenever I vote oppose in an RfC or any request for ... created by you, I like to use the word "per". You will always come reply and say something like "Please be more clear for why you're opposing. And don't use the word per and don't generalize etc", I explained many times that "per" means "same opinion as". Anpang📨 01:41, 27 January 2022 (UTC)
@Anpang: I'm saying your final words, not the "per" where you said "don't mess with this". --YellowFrogger (talk) (✔) 01:47, 27 January 2022 (UTC)
Weak oppose I do think Miraheze stands to improve as far as making things easier for a local administration of ailing, abandoned wikis to get off the ground. This includes a more clear local election/permissions process perhaps described or mentioned in the current RfA page, a Steward finally and properly transferring the current RfA page to a new name for clarity (deja vu of completed RfCs going unimplemented for a lengthy period of time) and a recognition of the fact that sometimes a wiki will be stunted to the point it really just needs new management off the bat and the process as now becomes needlessly bureaucratic. Global intervention for local needs is both spotty in its consistency and not ideal. While improper and poorly upheld, the midterm 'oldish' way of giving permissions after a review period made some sense, because the chances of contention to a request for permissions in a newly reopened wiki by someone authoritative in time is dramatically rare. However I think we can do better with the system as it stands. Additionally I do affirm that the 'oldish' process was improper and should not have been done by policy in the first place. I'd rather streamline and complete elements of the above than return to it. --Raidarr (talk) 11:45, 26 January 2022 (UTC)
Strong oppose Sorry, but having it changed like that wouldn't really make a difference, nor would it make sense in this case. --DarkMatterMan4500 (talk) (contribs) 14:09, 27 January 2022 (UTC)
Strong oppose My issue is that there is a possibility of a takeover. 29TB (talk) 22:23, 29 January 2022 (UTC)