Wikipedia talk:Request an account: Difference between revisions
Okeyes (WMF) (talk | contribs) →Discussion: could you elucidate |
|||
| Line 63: | Line 63: | ||
===Want the extension=== |
===Want the extension=== |
||
# [[tools:~acc]] is a bad hack. Most of the original authors later agreed with this. One or two were even granted commit access to MediaWiki's code repo to work on an extension to replace it. The tool is an unnecessary external server dependency, it has separate user authentication, it has data storage and management issues (IP addresses, e-mail addresses, and whatever other personal info gets input), etc. It's also become a mini-bureaucracy within Wikipedia. It should be in an extension. --[[User:MZMcBride|MZMcBride]] ([[User talk:MZMcBride|talk]]) 13:32, 12 April 2012 (UTC) |
|||
#Sign your name here |
|||
===Do not want the extension=== |
===Do not want the extension=== |
||
Revision as of 13:32, 12 April 2012
CheckUser authorization?
It seems like only a handful of CheckUsers have ACC Toolserver usage authorization, and about a couple are reasonably active. Do all CheckUsers have ACC authorization? If it isn't true, I would think they should automatically get authorization. Just a thought. -- Luke (Talk) 16:09, 28 December 2011 (UTC)
- I think this proposed is a really good idea. A few months ago we had a big backlog of account requests which needed a CU, luckily I'm a bit familiar with some because of some chats in different IRC channels. Since then we have "a new CU" helping us out (and luckily very active atm). mabdul 20:56, 28 December 2011 (UTC)
- Right now we actually as I've seen it had 2 very active CUs if not three. All Checkusers are entitled to flags once they register for their own account, otherwise, we can't force them to have an account. I know for a fact that not all CUs want to register either, so we have to let them do it on their own. But I am happy to approve all CUs and poke Stwalkerster for the Checkuser flag for them. -- DQ (t) (e) 00:24, 29 December 2011 (UTC)
- It may not be necessary for all CUs to have access, like you said, but it can useful if there is a backlog of requests. They don't have to be active, either. -- Luke (Talk) 00:28, 29 December 2011 (UTC)
Addihockey's account creator proposal at VPP
see proposal at Wikipedia:Village pump (proposals)#ACC_e-mail feature. mabdul 00:26, 15 January 2012 (UTC)
request
hi
i want to ask you guys somthing
i creat an account befor maybe 5 or 6 months "i think " anyway i would like to creat a new account and remmber that i have another account .
please give me clear answer ,thakkkkkkkkkkkkkkksssssss
please help guys and thank you — Preceding unsigned comment added by 79.179.170.235 (talk) 18:59, 27 February 2012 (UTC)
- yes you are allowed to create a new account as described here WP:CLEANSTART as long as you only use one of your accounts. Regards, mabdul 19:55, 27 February 2012 (UTC)
Hi
thank you but i need to tell me how to do a new account or at least a link ...
thanksssssssssssssssssss help pleaseeeeeeeeeeeeeeeeeeeee — Preceding unsigned comment added by 79.179.170.235 (talk) 20:19, 27 February 2012 (UTC)
Proposal - complete unified login for all eligible accounts
I have created a proposal at Meta, to complete unified login for all eligible accounts. Unified login is a relatively new feature to the WMF wikis, allowing each user to have a single combined account in every project. Users that only have an account on one wiki would extend that to all wikis, and users that already have accounts on multiple wikis would have them combined. It was initially an opt-in for existing users, but it is now done by default for all new users. This leaves us with three groups of users: those with UL, those that cannot complete UL because of a naming conflict on another wiki, and those with no conflict that have simply not completed the process. I am proposing that account unification be completed for all eligible accounts without requiring the user to take any additional steps. This would make UL the rule rather than the exception that it currently is, and bring us closer to the goals of universal watchlists, recent changes, interwiki page moves, etc. This would be especially helpful on Commons, which has so many images that were originally uploaded at another WMF wiki, enabling better attribution without interwiki links. I propose that it be carried out as a one-time process rather than a continuous automatic software process, allowing users to still adjust ULs as they see fit.
If you have any opinion one way or the other, please reply at the proposal at Meta. ▫ JohnnyMrNinja 01:01, 23 February 2012 (UTC)
Account Request extension, revisited
Hey guys. I've been speaking with Sumana Harihareswara, Brandon Harris and a couple of other WMF people about the ConfirmAccount extension, which was formally requested four years ago following a discussion here on enwiki. For those of you who weren't in the original discussion; ConfirmAccount is a MediaWiki extension that creates a new process for account creation, in which accounts are requested and authorised by someone with a specific user-right rather than merely created through the registration scheme. This is most useful in situations where the "normal" registration process doesn't work - for instance, when CAPTCHA issues make it difficult to fill out our standard form. This may sound similar to the Account Creation interface currently hosted on the Toolserver. In fact, the idea is that this extension would completely replace it, moving ACC functionality "in house" and clearing up the need to go off-site to use it.
Nothing was done at the time because of a dearth of developer time, and soon after, the ACC system on the toolserver was developed, which removed much of the need for this extension. However, it has been mentioned that:
with the current setup at [the toolserver] there is an external server dependency, an entirely separate user interface, a separate user auth and permissions system, and the possibility for unwittingly leaked data like IP addresses of users requesting accounts. This is undesirable and unacceptable.
Putting in the ConfirmAccount extension would completely clear up these issues, if they exist. However, we still (and probably forever will) have less developer time than we do things to do. The consensus reached in 2008 is now stale, and we need to know, broadly-speaking, if there is a strong feeling in the community that this extension should be enabled. We don't want to waste our time reviewing code for something that isn't wanted, when we could be working on other, necessary bugfixes that improve the editing and reading experience :).
So, TL;DR: I would be very grateful if people could indicate, in the sections below, whether they think this is necessary. If so, we can prioritise switching it on: if not, we won't. It is worth noting that the need to identify to the Wikimedia Foundation will still apply, and we will have to create a new user group; I imagine the process will work along the lines of "a user requests the permission, submits identification to the WMF, the WMF confirms the identity, a bureaucrat gives the user the appropriate user group status". Obviously, there's no reason that people who already use ACC and have identified shouldn't get this new right automatically. Okeyes (WMF) (talk) 12:58, 12 April 2012 (UTC)
Want the extension
- tools:~acc is a bad hack. Most of the original authors later agreed with this. One or two were even granted commit access to MediaWiki's code repo to work on an extension to replace it. The tool is an unnecessary external server dependency, it has separate user authentication, it has data storage and management issues (IP addresses, e-mail addresses, and whatever other personal info gets input), etc. It's also become a mini-bureaucracy within Wikipedia. It should be in an extension. --MZMcBride (talk) 13:32, 12 April 2012 (UTC)
Do not want the extension
- Sign your name here
Discussion
- Good idea. Von Restorff (talk) 13:28, 12 April 2012 (UTC)
- Could you indicate how good/bad by elucidating or !voting? :). Okeyes (WMF) (talk) 13:29, 12 April 2012 (UTC)