Wikipedia talk:User access levels

Page move vandalism

I thought that to be WP:Autoconfirmed, your account needs to be both four days old and have ten edits. Is this correct?

Domas Mituzas and ProvidentialPrudence have both been involved in Grawp-themed page move vandalism for Amyotrophic lateral sclerosis and VeggieTales respectively. The first editor's contribution history lists zero edits. The second's lists five. But they were both able to move pages. Why is this? WhatamIdoing (talk) 03:32, 14 February 2009 (UTC)

How many edits

How do I know how many edits I have? Dpalme (talk) 23:00, 31 March 2009 (UTC)

If you want to know your edit count go to your contributions page, go to the bottom, were you will see a number of tools, including User rights, Edit count, Articles created, and files uploaded. Click on 'Edit count' and you will go to Toolserver.org, were you find your top ten most edited articles, month edits, and percents of templates, talk pages, articles, and WP pages, and much more. A quicker way to find out is to go to your preferences and it will show an edit count there. --The High Fin Sperm Whale (Talk • Contribs) 01:28, 4 January 2010 (UTC)

Trusted Editor

Might it be wise to have a kind of Trusted Editor category? The potential benefits of this include not having to contact an administrator should they want to edit something. A potential candidate should prove that they can make non-controversial edits and have the ability to think things through. They should also have a good track record among other users. This person could act as sort of a quasi administrator.

Other abilities could include:

• Page deletion, but another administrator has to confirm it
• Not being affected by a rate limit
• View deleted history
• Editing locked pages that only administrators can edit

This ability could speed up the backlog of some of the things here. I know that there are probably those out there who either support or are against this proposal, so add ideas that you see fit. Kevin Rutherford (talk) 02:25, 22 February 2009 (UTC)

I think that we'd much rather make these people be full admins. WhatamIdoing (talk) 19:11, 23 February 2009 (UTC)

Poll on reviewer autopromotion for flagged protection and patrolled revisions

There is currently a poll on the autopromotion of reviewers at Wikipedia talk:Reviewers#Poll on autopromotion, for the trial implementation of flagged protection and patrolled revisions. For information, see general documentation and overview. All users are invited to comment, and to participate in the elaboration of a reviewing guideline as well. Cenarium (talk) 13:47, 12 April 2009 (UTC)

What the Hell?

When I created my account I could not create articles until I was autoconfirmed. Why? Daniel Christensen (talk) 16:05, 12 April 2009 (UTC)

You can create articles regardless of autoconfirmation. Ruslik (talk) 16:51, 12 April 2009 (UTC)

Maybe you were instead trying to edit an locked article? I hear those are easy to mix up...Fuzbaby (talk) 19:50, 19 May 2009 (UTC)

Changing the name

Once you have an account, can you change the name of your account, or would that wreak havoc? --The High Fin Sperm Whale (talk) 02:00, 9 June 2009 (UTC)

See WP:CHU. Ruslik_Zero 19:27, 9 June 2009 (UTC)

Who can see Special:Userrights

As an admin, I can (obviously) see the flags at Special:Userrights, including the flags I don't have the ability to change, which appear "grayed out." However, a non-admin sees "Your account does not have permission to assign user rights." Is there a reason he doesn't just see the same page with all of the boxes "grayed out"? It seems like a good idea, especially since this is the best place to check what permissions a given user has. --Philosopher ^{Let us reason together.} 04:59, 27 June 2009 (UTC)

You could request an enhancement at bugzilla:. Cenarium (talk) 16:01, 20 September 2009 (UTC)

The bottom of contributions pages have a "User rights" link anybody can see. Maybe this should be mentioned at Wikipedia:User access levels. PrimeHunter (talk) 13:21, 25 November 2009 (UTC)

Turning Autoconfirmed into an explicit userright

Please see and comment here. Thanks, Cenarium (talk) 16:02, 20 September 2009 (UTC)

Help

Hello, I am busy with a school project, and I cannot upload images, how do I get confirmed as a user? I have to complete this page —Preceding unsigned comment added by Super Warmonkey (talk • contribs) 12:41, 25 November 2009 (UTC)

Your account is old enough and you have 4 edits so you just need to make 6 more edits to any page to become autoconfirmed. You can upload images right away to Wikimedia Commons at http://commons.wikimedia.org and use them in Wikipedia. But see also Wikipedia:FAQ/Organizations,Wikipedia:Notability, Wikipedia:Reliable sources. Advertising statements like "has qualified and determined teachers and faculty, giving individual attention to each and every pupil" increase the risk that a page will be considered spam and deleted. PrimeHunter (talk) 13:15, 25 November 2009 (UTC)

Okay thank you —Preceding unsigned comment added by Super Warmonkey (talk • contribs) 17:37, 1 December 2009 (UTC)

Be autoconfirmed to create a page?

Ok, I already checked at WP:PEREN and this isn't there, so here we go: I propose we make users become autoconfirmed before they can create a page. This would have positive effects:

• It would force users to have at least a tiny amount of familiarity with Wikipedia before they add a page
• It would severely reduce the number of pages that get speedy deleted, especially blatant vandalism/attack/nonsense pages, as most vandals are too lazy/stupid to make ten good edits and too impatient to wait four days
• It seems to me to just make good plain common sense. We make users become autoconfirmed before they can move a page or upload an image, yet they can create a new article the second they register an account. WP:AFC will still be available for ip or non-autoconfirmed users.

• I'm going to cross-post this in a few places, and if it no serious problems/opposition become apparent we can move on to listing on WP:CENT or something. Beeblebrox (talk) 21:41, 18 December 2009 (UTC)

I've often thought this was a good idea for all the reasons you say above, but I'm fairly sure its been outright rejected on more than one occasion, I just can't remember when or where--Jac16888^Talk 21:48, 18 December 2009 (UTC)

• I like the idea and agree it would solve problems, but let's try a softer approach first and see if it would work:

1. Change the text that comes up when you type in a missing article name so that it strongly encourages using the New Article Wizard and adds an option to create a draft as [[Special:Mypage/{{PAGENAME}}]].
2. Change the behavior when you click on a redlink so it opens the New Article Wizard with the article name pre-filled in, unless you have gone to your preferences and changed it to bypass the Wizard. Existing accounts would have this setting automatically set when the preference is added to Special:Preferences.

davidwr/(talk)/(contribs)/(e-mail) 21:59, 18 December 2009 (UTC)

• I can't say the New Article Wizard has improved things from my point of view, instead I've just being deleting more articles with a few headings and a reference to example.com, although in fairness I'm less active at speedy deletion now--Jac16888^Talk 22:03, 18 December 2009 (UTC)

I don't have a problem with the article Wizard, and I'm sure it has helped folks who come here with good intentions, but it hasn't slowed the flow of garbage pages at all, just made them look a little better before they are deleted. This way those well intentioned people would have four days to make sure that they are not creating an article that will be speedied, and outright vandals will give up in the vast majority of cases. Of course this won't stop them from vandalizing other articles, but I think it's effect on attack and nonsense pages would be quite something. We could still allow them to create subpage drafts so that they could work on the pages and get them up top snuff before they go live. If they are ready before that they can use AFC. I've tried to think this through for any serious problems that might be caused by it, and I can't think of any. Beeblebrox (talk) 22:09, 18 December 2009 (UTC)

Despite my comments above, I could live with not allowing users to create pages in article space if any attempt to do so automatically created the page in user-space, with a note to them explaining how to move it to article space when they had autoconfirmed status, and an easy/automagic-button way for them to add it to a Category:Articles by new editors ready to be published or someplace similar asking that an established editor give the article a patroller's-eye-view once-over, and make the move if it's not speedy-deletion-eligible, tagging it with cleanup tags if necessary. I would suggest having the software pre-fill the page with a template that has a "ready to publish=no" field, instructing the editor to change it to "yes" when it is ready. davidwr/(talk)/(contribs)/(e-mail) 23:53, 18 December 2009 (UTC)

I'm not sure we need to construct such an elaborate system, if they tried to create a new page and were blocked for not being confirmed, they could simply be presented with the choice to either make a userspace draft, submit what they have at AFC, or wait until they are autoconfirmed to proceed. Beeblebrox (talk) 01:45, 19 December 2009 (UTC)

If this choice were presented in a welcoming way, I could concede to it. We are trying to solve one problem - reducing the number of hopelessly bad articles created by new users - and we will create another problem - scaring off new editors who want to share their pride and joy. If we do nothing but impose this rule, the cure will be worse than the disease. If we do it right, with a strong eye to saying "we like you and value your efforts," we can reduce the number of scared-off newcomers to low enough levels that it's worth it to stop them from creating articles. davidwr/(talk)/(contribs)/(e-mail) 01:50, 19 December 2009 (UTC)

If we do it right it should actually encourage new users by lessening the chance that their first contribution will be a page that is deleted 2 minutes after they post it. I do agree that we need to make sure we are clear that it's not that we don't value them but that we are trying to make sure that their first Wikipedia experience is a positive one. The devil is in the details, as they say, but for now I'm just trying to see if this has any hope at all. Coming up with a detailed proposal at this point is probably premature. Beeblebrox (talk) 01:56, 19 December 2009 (UTC)

• This was discussed with an RfC in October, see Wikipedia:Village pump (proposals)/Archive 53#autoconfirmed for unassisted article creation. I support the idea, but it didn't gain approval. Fences&Windows 02:08, 19 December 2009 (UTC)
• As I said to Rd232 a month ago, the benefit of this proposal is to funnel new articles by non-autoconfirmed users via the same avenue as IP users, to delineate newbie articles from general user articles, and have newbies operating in the less Wild West arena of AFC rather than their first experience of Wikipedia being a zealous NPPer. Fences&Windows 02:15, 19 December 2009 (UTC)
• I think there is no question that the most common bad first experience a newbie can get is to have his first article speedily deleted — no matter how necessary that deletion was. Guiding them towards a user space draft and making them wait until they got their feet wet with a couple of edits and a few days sounds like a good method to help them not be scared off; and has the nice side effect of making life hard(er) enough to discourage many drive-by vandals. I'd support. — Coren ^(talk) 02:29, 19 December 2009 (UTC)
• Although I completely understand why this would be nice and save a lot of troubles overall, I have to go against it on principle and that it's opposite some of Wikipedia's general philosophy. Perfect idea and a no-brainer one would think, but it's just not "Wikipedia~y". We have enough of a public image problem as it is, and, *gasp* once word got out your account had to exist for 4 days (or 10 edits, but no one would mention that) before you could create anything it would be on every last media outlet you could think of, and we'd just be feeding fuel to general naysayers and just continuing the spiral of what seems to be keeping things status quo in stats instead of possibly growing much more.. Requiring an account to publish was passed over pretty quick (for most, not all) once people realized it was even more dull than any other web signup and, but this would be a very drastic change. "Wikipedia: The encyclopedia anyone can edit ... after waiting a few days. Check back at the end of the week"? Sigh. I'm going to be stubborn and say that Wikipedia's core nature is not compatible with this. ♪ daTheisen(talk) 03:30, 19 December 2009 (UTC)

  I agree with daTheisen on this one. Although I like the basic idea (and in some ways agree with it), I do think that this would go against the basic premise of Wikipedia being the encyclopedia that anyone can edit! Not allowing IPs to create new articles makes sense, not allowing registered editors is more iffy. Yes, it means that a vandal can create an account and create a new article - but most vandals can't be bothered to make an account. So, I say "IPs no, all registered users yes" to creating new pages. -- PhantomSteve/talk|contribs\ 09:22, 19 December 2009 (UTC)

Comment. The philosophy of being "The encyclopedia anyone can edit" is in opposition to the philosophy of traditional encyclopedias of only allowing experts to contribute. That's what it means. Only an attempt to identify users' credentials or otherwise gauge their knowledge and experience as a pre-requisite to contributing would conflict with the Wikipedia philosophy. All other changes (like being able to protect pages from editing, prevent IPs creating pages, the ability to block/ban) may or may not be desirable, but are merely technical decisions on what is best for the encyclopedia. So much for the general philosophy; on this specific proposal, it bears pointing out that we're merely talking about delaying (very slightly) the ability to immediately create new, live encyclopedia entries. Anyone can still edit existing entries, or draft new ones in userspace.

And this change is exactly the sort of change we should be examining periodically, because (a) the bigger and bigger WP gets, the less and less likely that completely inexperienced users are creating articles that should go live without some kind of review. The proportion of junk and spam (in articles created by such users) must be increasing, simply because there are less and less easy, popular topics not covered yet. Increasingly topics not covered are hard, boring ones - to get these covered we need to pull more people in for the longer term, rather than drive-by editing. In addition, (b), we need to work a lot harder to reduce the learning curve. Opponents of this change tend to focus on the idea that not being able to create new articles immediately is massively off-putting. Supporters reckon getting your first contribution deleted in minutes is more off-putting. In terms of the pros/cons, this is where the debate needs to focus. Some way of testing these things would be great, so the impact of a trial could be evaluated instead of merely being speculated about. Rd232 ^talk 12:19, 19 December 2009 (UTC)

I'm not disagreeing with you on your finer points of philosophy-- you're right that it wouldn't change the fact, but having a wait time like it's a firearms purchase is an unusual thing to try to get the public to understand out of the blue. Instead, it snowballs into another media media mess that hurts i the long run. I'll argue that part of Wikipedia "spirit" at this point is how pop culture has soaked it in, and the ultimate direction and progress of the project is directly tied to this in many ways. This does NOT mean we make any changes to the encyclopedia for this reason, just to clarify on that. Cutting away one of our "special things" would hurt people, and I'd argue that it'd be on par with theoretical restrictions on IP edits or flagged revisions in terms of "not cool". For better or worse, Wikipedia-- and en.Wikipedia in particular-- are dug into normal culture on basically the principles of easy creation and anyone can edit. Concerns of censorship would be my biggest worry with this, and actually would have some merit. We'd need a new user rights for this on this, too. Autoreviewers would have to be expanded 10-fold or admins almost the same for there to be any chance of new pages getting "the okay" without falling into the backlog of 300,000 or so articles that have citation templates on them.

I don't care how other language Wikipedias do it, but this English version is webbed in deeply with so many things in both the Encyclopedia and as a an internet icon that we should try as hard as we can to preserve it as something that encourages more productive participation. Put new users through article GNG "quizzes", drill NPP with a newly-reviewed and adjusted-as-necessary for new consensus set of CSD criteria, offer us userfication, give us templates with green borders and exclamation marks for talk pages as assistance and reminders instead of an automatic scolding and being yelled at to check policy along with angry red signs. All common sense issues and would just need more diligence, and these were all suggestions that came from the infamous WP:NEWT but never went anywhere. This is at least one more chance for it to end up productive. ♪ daTheisen(talk) 15:16, 19 December 2009 (UTC)

• I don't know about you, but I edited on-and-off as an IP for about a year before I got an account. Why did I get an account at all, then? Simply because I wanted to create an article and that was the only way I could do it. Most unconfirmed users probably created their accounts to create their first articles. That's why this proposal won't fly. A Stop at Willoughby (talk) 19:49, 19 December 2009 (UTC)
  • That's not a sufficient explanation, for me. The autoconfirmed hurdle (4 days + 10 edits) is low. The opportunity to draft in userspace exists in the mean time, and some mechanism to put drafts live with assistance (for the impatient) is easy to create. And we absolutely must avoid assuming that doing this loses us more users than the WP:BITEy status quo, where stuff gets deleted so quickly. In addition, I'd argue that one key thing we need is long-term contributors who really learn the system; losing drive-by "My Spam" contributors is little loss. And these potential long-term contributors need to be helped, and I'd argue that this is help, in the same way that requiring people to get driving licences before they can drive alone is help. Rd232 ^talk 00:02, 20 December 2009 (UTC)
• I may be the exception, but I edited as a registered user for about six months before I ever created an actual article. Creating an article really shouldn't be someone's first edit on Wikipedia, because of the high likelihood that it will have serious problems and be deleted within minutes. I think the "media frenzy" is a red herring. Most people in fact do not understand the whole autoconfirmed thing, and it's actually not that big of a change. Non-autoconfirmed users are already restricted from certain actions, we would just be adding one more to the list. Most of the objections I am seeing so far seem to be saying that they don't actually think that this is a bad idea, but they don't think we should do it for some other reason. If it's not a bad idea, those other reasons can be overcome. The idea that this goes against Wikipedia's core philosophy doesn't jive with me, since one of the five pillars of Wikipedia is to ignore any rule when following that rule would harm rather than help the project. Beeblebrox (talk) 20:26, 19 December 2009 (UTC)
• I must be odd too, it was over two years and several hundred edits from me creating an account to creating my first article. Note that this proposal is not to stop new users from starting articles, but to filter them through WP:AFC. Fences&Windows 23:25, 19 December 2009 (UTC)
• Would people's opinion on this matter be different if we had FlaggedRevisions enabled on this Wikipedia? (And yes, I saw that daTheisen referred to FR above) (Incidently, have you seen the Wikipedia:Flagged revisions petition?) -- PhantomSteve/talk|contribs\ 00:06, 20 December 2009 (UTC)

Strong oppose. This is one worst ideas I have ever seen. For Wikipedia, this is just an equivalent to the suicide. How many users will reappear after 4 days and 10 edits? My guess is less than 1%. How many spammers will be deterred by this? My guess is zero. They will simply reprogram their bots to wait 4 days and to make 10 meaningless edits. Are new users scared to death by article deletions? This has been claimed many times but I have never seen any hard evidence. Just another red-herring, in my opinion. In any case articles are not deleted without a good reason. If somebody creates an article containing I am Jimmy. I go to school., it will be deleted, of course, and the editor is likely to disappear. However, is loss of such editors a really big problem? I am much more concerned that if somebody wants to create an article about a new planet discovered somewhere, they will be told to wait 4 days (and make 10 meaningless edits) or go through a bureaucratic maze, which someone proposed above. How many editors will want to contribute under such conditions? And finally how many editors will be required to staff the AFC in this case? Ruslik_Zero 15:40, 20 December 2009 (UTC)

"My guess is ...." + "I have never seen any hard evidence...." = ??? Are you happy to make up your mind based on speculation about how many and what kind of users the proposed approach deters versus the current one, or would some way of testing the impact of such a change actually be a good idea? Nobody is being told to wait four days, they can draft the article in userspace immediately. If whatever mechanism put in place to ensure that people can put their drafts live more quickly than that gets backlogged (WP:AFC? no, userspace drafts are much better for this), the impact of that is so very much mitigated by the fact that users can come back in four days and move it themselves (and no doubt mechanisms for reviewing abandoned drafts will be created, with no greater workload than NPP now). In fact people seem generally happy to support Flagged Revisions, which is a VASTLY more problematic version of this proposal in terms of putting people off editing and in terms of workload created.

More generally, the argument about junk contributors being willing to jump through any hoops is irrelevant - we'll deal with them either way. The real issue is those inexperienced contributors who might actually contribute substantially - how can we improving their experience, and make their first contribution more likely to stick, their second contribution a substantially better one once they starting getting how things work, and the contributor more likely to stick around. I'm amazed at the idea that the Potential Longterm Contributor will be put off by having to draft the article first (if they have ZERO experience), yet won't mind at all if their poor yet good faith article idea gets unexpectedly slapped with delete tags, being happy to soldier on nonetheless. For me, it's all about expectations. Saying "anyone can create an article (but you need to draft it first, if you've no experience)" is much better than "anyone can create an article (but your contribution WILL get roundly slapped with all manner of tags and possibly be deleted for being rubbish, you ignorant fool, because you've no experience and we haven't told you what experience you need or what treatment to expect)". Basically, do we want to hand the keys to our Ferrari to anyone who walks through the door and let them straight out onto the open road (if you crash and burn, we'll tag your wreckage!), or do we ask them to drive round the carpark a bit first, to get used to the controls? Rd232 ^talk 17:05, 20 December 2009 (UTC)

RFC on autoconfirmed status required to create an article

Moved to Wikipedia talk:User access levels/RFC on autoconfirmed status required to create an article, on request. Reason: Section is getting too big. davidwr/(talk)/(contribs)/(e-mail) 23:41, 27 December 2009 (UTC)

User Rights Table

I have made a table showing who can give/revoke certain rights.

Granted	Inherited	Denied

	Confirmed	Bot	Sysop	Bureaucrat	Rollbacker	Checkuser	Autoreviewer	Oversight	Boardvote	Import	Ipblock-Exempt	Edit Filter managers	Acccount Creator	Steward	Founder
Anonymous users
(Auto)Confirmed/Registered User
Bot
Sysop	+/-				+/-		+/-				+/-	+/-	+/-
Bureaucrat			+	+	+/-		+/-				+/-	+/-	+/-
Rollbacker
Checkuser
Autoreviewer
Oversight
Boardvote
Import
Ip-block-Exempt
Edit Filter managers
Acount Creator
Steward	+/-	+/-	+/-	+/-	+/-	+/-	+/-	+/-	+/-	+/-	+/-	+/-	+/-	+/-	+/-
Founder	+/-	+/-	+/-	+/-	+/-	+/-	+/-	+/-	+/-	+/-	+/-	+/-	+/-	+/-	+/-

I thought it could be included in this article so people know who can grant them a particular right, if you agree with me feel free to add it. Thanks Paul2387 16:50, 17 January 2010 (UTC)

Seems like overkill to be honest, it would be much easier to simply having a passage saying admins can do x, crats can do x and y and stewards can do x, y and z. I suppose if you really want a table then you should take out everyone who can't do anything at all, a huge block of red is pointless--Jac16888^Talk 21:13, 20 January 2010 (UTC)

I tend to agree, it would be easier to convey this information with words, considering that three quarters of the table is just "denied." Beeblebrox (talk) 21:18, 20 January 2010 (UTC)

I have improved the above table and it can be seen below:

Granted	Inherited	Denied

	Confirmed		Bot		Sysop		Bureaucrat		Rollbacker		Checkuser		Autoreviewer		Oversight		Boardvote		Import		Ipblock-Exempt		Edit Filter managers		Acccount Creator
	give	take	give	take	give	take	give	take	give	take	give	take	give	take	give	take	give	take	give	take	give	take	give	take	give	take
Sysop
Bureaucrat
Steward
Founder

Feel free to comment on it and if you like it feel free to add it to the main article. Paul2387 13:42, 21 January 2010 (UTC)

What is 'confirmed bot'? Ruslik_Zero 14:08, 21 January 2010 (UTC)

A bot which has a more perfect bond with God. Or, it might be that you missed the line between Confirmed and Bot--Jac16888^Talk 15:10, 22 January 2010 (UTC)

On a friend's wiki, she found that if you made a non-admin a 'crat, they didn't inherit the admin properties - they couldn't block users, delete pages or protect pages. I don't know what version of MediaWiki they are using, but are you sure that enwiki 'crats would have the admin rights as well? I know no one's ever been a 'crat without being an admin, but I was just curious. -- PhantomSteve/talk|contribs\ 07:43, 2 April 2010 (UTC)

I have done some tests on my own wiki I set up today and crats alone (without admin bit) can't delete pages or block users, however if the rights are changed in the LocalSettings.php then Crats can be given those rights, could someone do a experiment(test) on wikipedia and report back here - maybe someone could create a test account and only add crat rights. Please Leave your reports in the relevent sections below. Paul2387 10:57, 2 April 2010 (UTC)

Beautified and updated for File Mover

Behold:

Granted	Inherited	Denied

	Confirmed		Rollbacker		Autoreviewer		Filemover		Ipblock-Exempt		Bot		Edit Filter managers		Acccount Creator		Sysop		Bureaucrat		Checkuser		Oversight		Boardvote		Import
	give	take	give	take	give	take	give	take	give	take	give	take	give	take	give	take	give	take	give	take	give	take	give	take	give	take	give	take
Sysop
Bureaucrat
Steward
Founder

By the way, why do we list Jimmy/Founder here when he can do everything? We should remove that, as in all honesty, it adds just as little as including the Anonymous users section, which can do none of these things, and was also cut. Sven Manguard Wha? 01:01, 16 April 2011 (UTC)

We should raise the level of auto confirmation

accounts that are more than four days old and have made at least 10 edits are considered autoconfirmed

This is shouting out to be increased, it should better be at least two weeks and at least 200 edits as it is right now it is very easy to create new accounts and be disruptive daily at the same article, I can't see a benefit in having this so low, at this level semi protection is worthless. A good faith account with a 100 edits will easily say hey, can you make this edit for me, what will we lose by raising this level to a point to deter trolls and vandals? Off2riorob (talk) 00:47, 10 February 2010 (UTC)

This isn't exactly the same proposal, but a review of this rfc will show what you are up against here. It would only stop them from vandalizing semi-protected articles anyway. Beeblebrox (talk) 02:01, 10 February 2010 (UTC)

That was my objective from the change, I will have a read of the link, thanks.. as far as BLP articles and the flagged revision goes, if we semi protected all BLP articles and raised the auto confirmed level, many of the disruptive editors would simply go away. Off2riorob (talk) 02:07, 10 February 2010 (UTC)

Why not grant autoconfirmed status 4 days after the 10th edit, rather than granting for users who have made 10 edits and been here 4 days since the 1st edit? Under the current system, someone (e.g. a spambot operator) can make 1 harmless edit, then wait 4 days, make 9 bad edits in quick succession, and then become autoconfirmed. Tisane (talk) 11:03, 1 April 2010 (UTC)

Actually the 4 days are counted since the date of registration, not of first edit. Cenarium (talk) 23:49, 3 April 2010 (UTC)

The threshold definitively needs to be raised, as 10 edits are not enough to stop highly motivated vandals like Serafin who has created hundreds of autoconfirmed socks. The other option would be an additional user status between autoconfirmed and sysop. -- Matthead  Discuß   16:37, 3 April 2010 (UTC)

We'll have the usergroup of reviewers with WP:FPPR which does include an intermediary protection level (to handle cases like Seraffin, persistent targeted disruption). Patrolled revisions will give us a much better monitoring capability as well. So the autoconfirmed threshold would not need to be raised. Cenarium (talk) 23:49, 3 April 2010 (UTC)

Do IPs still have the way to request a change on a page except via the discussion page?

Well, I can't remember where it was but I encountered the rare case of a discussion (talk) page blocked for anonymous edits!! That means I cannot even request changes (grammar in this case) anymore. However, WP had a page where we could request these changes, I just cannot remember it anymore. Can anyone please help me out? -andy 85.179.125.6 (talk) 07:09, 13 February 2010 (UTC)

Try the protecting admin's talk page, then WP:RFPP. -- zzuuzz ^(talk) 12:49, 13 February 2010 (UTC)

You could also file a request at requests for page protection, which has a section for requesting edits to protected pages.By the way, the other two discussions you just posted in are extremely stale, and it's unlikely you'll receive any reply, in fact this edit [1] was the first edit to that talk page in nearly five years, and the page it is a talk page of is marked as "historical and inactive." Beeblebrox (talk) 16:45, 13 February 2010 (UTC)

Researcher?

What is the researcher user group (see here)? Thanks, -- Black Falcon ^(talk) 05:02, 22 April 2010 (UTC)

See Special:ListGroupRights. They can see deleted histories, but not deleted text, for research purposes. Log Happy‑melon 08:51, 22 April 2010 (UTC)

Ah, I see. Thank you, -- Black Falcon ^(talk) 17:09, 22 April 2010 (UTC)

Obtaining Research Rights

Hello. I understand the "researcher" permission is a relatively new one. How does one go about obtaining/requesting this right? It is not yet documented on the traditional "request-for-permissions" page. My user-page should contain the pointers sufficient to demonstrate I do Wikipedia research. Thanks, West.andrew.g (talk) 02:36, 4 June 2010 (UTC)

Proposal to rename Autoreviewer to Autopatroller

Proposed here. Cenarium (talk) 16:28, 12 June 2010 (UTC)

Nano-x API

Extended content

{{editsemiprotected}} Nano-X Based on the original mini-X tutorial by David I. Bell 2000/10/3 Revision 1.0 This is a simple tutorial on using the Nano-X graphics system. Much of this is a lot easier to understand if you are familiar to X. I am not going to try to explain every concept in detail here, nor how to put it all together to make really fancy programs. Instead, I am only going to tell you just enough to let you make some simple graphics programs which work. Experience with simple test programs will enable you to build much fancier graphics programs much easier than trying to decipher what I could tell you. I am assuming that you basically know what a screen, pixels, colors, keyboards, mice, buttons, and windows are. However, you probably don't know exactly what the properties of windows in this system are. Also, you might not know two other concepts which are important here, which are graphics contexts and events. So these things will be explained in this tutorial. WINDOWS Windows are rectangular areas which can be drawn into. Windows have a position, specified by the x and y coordinates of their upper left corners, and also a size, specified by their width and height. Windows are arranged in a tree structure, with the parent windows controlling the child windows. The top of the tree is known as the root window. The root window is always present, and represents the total screen area. Each child window is clipped by its parent window. This means that a window can be very large, but the only part of the window that can ever be seen is the part which shows through its parent window. This applies recursively, so that all of the parents of a window limit its visibility. The position of a window is specified relative to its parent, and not absolutely. This means that for example, when a window is moved, then all of its children will move with it. The position of a window can be negative. Windows which have the same parent can clip each other. That is, there is a defined order among the children of a window as to which is more important. If two sibling windows overlap, then the more important window will be visible in preference to the less important window. The precedence of visibility of siblings can be dynamically adjusted. Clipping can also occur on a window by earlier siblings of any of the window's parents. Windows can be mapped or unmapped. Unmapped windows are not visible, and cause no events. They can be thought of as "in storage" or off screen. When a window is mapped, then it can become visible on the screen. Children of an unmapped window are implicitly also unmapped. So a window is not visible until it and all of its parents are mapped. A newly created window starts off unmapped. Windows have a background color. A newly mapped window is filled with its background color. Clearing the window later, or having obscured portions of the window become visible again, will fill the region with the background. The client program can then draw into the window to make it look correct. Windows may have a border. A border is a set of rectangles adjacent to the four sides of the window which is drawn in a specified color, with a specified width. This makes pretty lines around the window, for example. The border cannot be drawn in by the program. Borders are optional, so that a window with a border width of zero has no border at all. Borders are "around" the window, so that they do not affect the coordinates of the window. Whether or not a window has borders, its position determines the location of the upper left corner which can be drawn into. Windows can have a cursor associated with them. The graphics server tracks the location of the mouse, and maintains the position of a graphics cursor on the screen. This cursor can automatically change its shape and colors as it moves between different windows. The use of different cursors for different windows can be used to provide a powerful clue to the user as to what will happen if a mouse button is pressed in a window. Newly created windows inherit the same cursor as their parent. There are two types of windows, input-output and input-only windows. Input-output windows are normal windows which are visible and can be drawn into. Input-only windows are invisible, have no border, and cannot be drawn into. Their purpose is to catch events, and to enable the cursor to be changed in different regions of a visible window. The only children of input-only windows are also input-only windows. Windows are identified by integers called window ids. The root window has a constant window id value of GR_ROOT_WINDOW_ID. The root window does not need creating, and cannot be unmapped, moved, resized, or destroyed. However, it can be drawn into and events can be delivered to it. New windows can be created from existing windows. Their window ids are not constants, but once created the window id remains until the window is destroyed. Window ids are not reused as windows are created and destroyed. GRAPHICS CONTEXTS When drawing objects such as lines, there are many parameters that can be specified for the function call that affect the operation. Besides the minimum information needed for the function such as the endpoint coordinates, there are extra parameters that are less important and less variable. Examples of these extra parameters are color, width (thin or thick), style (dashed, dotted), and drawing operation (setting, XOR'ing). Instead of requiring the specifying of each of these extra parameters for every function call, graphics contexts are used. Graphics contexts are just a collection of specific combinations of these extra parameters. The many possible extra parameters to each function are replaced by just one extra parameter, which is the graphics context. For example, instead of a function call like: drawline(window, x1, y1, x2, y2, color, width, style, operation); you have instead drawline(window, gc, x1, y1, x2, y2), where the graphics context contains within itself the parameters color, width, style, and operation. Graphics contexts are stored in the graphics server, and are identified by unique numbers in a way similar to window ids. Your program must allocate graphic contexts, which then can be used in drawing functions. A newly allocated graphics context is supplied with default parameters, such as a foreground color of white, drawing operation of setting, and width of 0. You can modify the parameters associated with the graphics context one by one, by for example, setting the foreground color to black. A single graphics context could be used for every drawing operation by constantly setting the parameters associated with it to the values needed for each drawing call. But this is inefficient. The reason that multiple graphics contexts can be allocated is so that you can minimize the setting of their parameters. By presetting the parameters of several graphics contexts to commonly used values in your program, you can avoid changing them later. For example, you can call one graphics context white_gc, and another graphics context black_gc, and then use the correct graphics context in the drawing functions to draw in either black or white. The parameters contained within a graphics context are currently the following: Drawing mode. Specifies the operation performed when drawing each pixel. One of: GR_MODE_SET draw pixels as given (default) GR_MODE_XOR draw pixels using XOR GR_MODE_OR draw pixels using OR GR_MODE_AND draw pixels using AND Text font. A small integer identifying the font for drawing text. The first few are built-in to the device driver, others must be loaded by the graphics server. The default font is 0. Foreground color. The color that is used to draw almost all objects with, such as lines, points, ellipses, text, bitmaps, and filled areas. Default is white. Background color. The color used for some functions in addition to the foreground color. For bitmaps and text, this is the color used for the zero bits. The default background color is black. The drawing of this color can be disabled by the next parameter. UseBackground flag. This is a boolean value which indicates whether or not the background color is actually to be drawn for bitmaps, text, and the GrArea8 function. The default is GR_TRUE. EVENTS Events are the way in which the graphics system notifies your program of asychronous changes in the state of the screen, mouse, or keyboard. Whenever the state changes, your program is notified of this change and can act on it. The word "event" is used both for the actual change that took place, and also for the data that is returned to your program which describes the change. Events are generated for various different types of changes that may be useful for your program to know. Events directly related to the hardware are the keyboard and mouse events. Keyboard events are generated for each key which is pressed (and released, if possible). The event contains the character which caused the event. Mouse events are generated when a button on the mouse is pressed or released, or when the mouse position moves. The event contains the buttons which are pressed, and the current position of the mouse. Other events are more subtle, and are based on non-physical changes, such as having the mouse move into or out of specific windows. Events are generally tied to individual windows. Your program can enable or disable which kinds of events it wants for each window. Part of the data associated with an event is the window associated with the event. For example, if a key is pressed on the keyboard, the event for that key will indicate which window that key is for. You program can then act differently for different windows. Events which you have not indicated an interest in are simply discarded. The keyboard and mouse events can propagate upwards through the window tree and be delivered to some parent window. This occurs if the window does not select for the event, but one of the parent windows does. Part of the information returned about these events is the window that accepted the event, and also the original window which caused the event. Therefore, your program can determine which child window an event was for without having to select for the event for each child. Events other than keyboard and mouse events never propagate. The window that keyboard events are delivered to depends on the current mouse position or on the "input focus". The input focus is a way of specifying that keyboard events are to be delivered to a particular window, no matter where the mouse is currently pointing. Your program can change the input focus as desired. If the input focus is set to the root window, then the keyboard events will be delivered to the window which contains the mouse pointer (or one of its parents). Events are returned to your program as a structure containing the information about the event. This information is the event type, the window id which the event is associated with, and other event-specific data. Events are stored in a queue, and are delivered to your program one by one as requested. The order of the events is preserved. Your program can either simply ask for the next available event (waiting for one if none are yet available), or it can check to see if an event is available without waiting. The delivering of events only occurs when you request an event. So even though events themselves are asychronous, the reading of them is synchronous. There are no "interrupts" for events, you must explicitly ask for them. The important thing about programming with events is that your program should be written to run "upside-down". That is, you do not have a main routine which checks that the mouse has been moved, or the keyboard has been typed on, or which window the mouse is in. Instead, your main routine just waits for an event, and then dispatches on its type and which window it is for. Generally, you must keep some state information to remember what is happening in your program. For example, if the user wants to click the button in a window to indicate where some text should be inserted, then your program cannot simply detect the mouse click, and then wait for the text to be typed. Instead, when the mouse is clicked, it should just remember the position of the mouse and set a flag to indicate that text typing is allowed, When the keyboard event arrives, this saved information then enables you to draw the text at the correct location. Your program basically becomes one large state machine. One obscure event is the exposure event. This is sent to your program when a window requires redrawing. Due to lack of memory space, the graphics server does not attempt to save the data from the parts of windows which are covered by other windows. Therefore, when the obscured parts of the window are uncovered, your program must be told to redraw those parts. The exposure event contains a rectangular area which requires drawing (which may in fact be larger than the area which was actually uncovered). Your program can either just redraw that area, or if more convenient, redraw the whole window. The area to be redrawn has already been cleared to the window's background color. When a window is mapped, an exposure event is sent for the window. Therefore, you should not explicitly draw into a window when it is first created and mapped, but should instead just wait for the exposure event, and then draw it. In this way, the code to draw the window only resides in one place in your program, and you prevent redundant drawing of the window. If you are drawing the complete window on all exposure events, then it might be useful to use GrPeekEvent to examine the next event too. If it is also an exposure event for the same window, then you can read it by using GrGetNextEvent, and thereby prevent redundant redrawing. Of course, to be able to redraw the window, you may need to save extra data in order to regenerate the drawing commands. (Pixmaps are one way of doing this in the future, but they are not currently implemented.) The following is a description of the various types of events which are available, and (in parenthesis) the typedef name for the structure that returns the event. Each event has a type field, which can be used to distinguish between the various events. For details on the other data within the structures, refer to graphics.h. The typedef GR_EVENT is a union which contains all of the possible event structures. GR_EVENT_TYPE_NONE (GR_EVENT) This indicates that no event has occurred. GR_EVENT_TYPE_EXPOSURE (GR_EVENT_EXPOSURE) This is generated when a window needs redrawing because it is either newly mapped, or has been uncovered by another window. This returns the window id, and the x, y, width, and height of the area within the window which needs redrawing. GR_EVENT_TYPE_BUTTON_DOWN (GR_EVENT_BUTTON) This is generated when a button is pressed down on the mouse. This returns the window id which generated the event, the window id which actually contains the mouse, the current position of the mouse, the buttons which are currently down on the mouse, the buttons which were just pressed down, and the current modifier flags. GR_EVENT_TYPE_BUTTON_UP (GR_EVENT_BUTTON) This is generated when a button is released on the mouse. This returns data similarly to button down. GR_EVENT_TYPE_MOUSE_ENTER (GR_EVENT_GENERAL) This is generated when the mouse enters a window. This returns the window id which generated the event. GR_EVENT_TYPE_MOUSE_EXIT (GR_EVENT_GENERAL) This is generated when the mouse leaves a window. This returns the window id which generated the event. GR_EVENT_TYPE_MOUSE_MOTION (GR_EVENT_MOUSE) Mouse motion is generated for every motion of the mouse, and is used to track the entire history of the mouse. Mouse motion generates many events and causes lots of overhead. This returns data similarly to mouse enter. GR_EVENT_TYPE_MOUSE_POSITION (GR_EVENT_MOUSE) Mouse position ignores the history of the motion, and only reports the latest position of the mouse by only queuing the latest such event for any single client (good for rubber-banding). This returns data similarly to mouse enter. GR_EVENT_TYPE_KEY_DOWN (GR_EVENT_KEYSTROKE) This indicates that a key has been pressed on the keyboard. This returns the window id which generated the event, the window id which actually contains the pointer (if the pointer is outside of the event window, this will be the event window), the current position of the mouse, the current buttons on the mouse which are down, the current modifier flags, and the character which was typed. GR_EVENT_TYPE_KEY_UP (GR_EVENT_KEYSTROKE) This indicates that a key has been released on the keyboard. This event is not necessarily available, and should not be depended on.This returns data similarly to key down. GR_EVENT_TYPE_FOCUS_IN (GR_EVENT_GENERAL) This indicates that the input focus has just changed to this window. This returns the window id which got focus. GR_EVENT_TYPE_FOCUS_OUT (GR_EVENT_GENERAL) This indicates that the input focus has just left this window. This returns the window id which lost focus. To select for events, you use GrSelectEvents, and specify the window which wants to receive the events, and also specify a mask indicating the events you wish to receive. The mask is the logical OR of individual bit values representing the event types. The mask names are the same as the event names, except that the "_TYPE_" string is replaced by "_MASK_". For example, the mask associated with the event GR_EVENT_TYPE_FOCUS_IN is GR_EVENT_MASK_FOCUS_IN. If you select for both button down and button up events, then the mouse will be implicitly "grabbed" when any button is pressed down in that window. This means that the mouse position and button down and up events will be delivered only to that window, and the cursor shape won't change, even if the mouse leaves that window. The implicit grabbing ends after the last button is released. While this grabbing occurs, the input focus is also not changed as the mouse is moved. MODIFIER AND MOUSE BUTTONS Modifiers are the status of special keyboard shift-like keys. The state of these keys can be read as up or down, and don't generate any characters by themselves. These keys are for things like SHIFT, CTRL, and ALT. They are returned as bit values OR'd together in various events. Not all of these modifiers may be implemented. The GrGetScreenInfo function returns the modifiers that are implemented. The following modifiers are defined: GR_MODIFIER_SHIFT shift key is down GR_MODIFIER_CTRL ctrl key is down GR_MODIFIER_META meta (or ALT) key is down GR_MODIFIER_ANY any of the modifiers is down The mouse button state are returned as bit values OR'd together in various events. Not all of these buttons may be implemented. The GrGetScreenInfo function returns the buttons that are implemented. The following mouse buttons are defined: GR_BUTTON_1 button 1 is down (left) GR_BUTTON_2 button 2 is down (middle) GR_BUTTON_3 button 3 is down (right) GR_BUTTON_ANY any of the buttons is down BITMAPS Bitmaps are defined as an array of GR_BITMAP values, which are unsigned shorts. Each word is 16 bits, which specify foreground and background values, with 1 being foreground and 0 being background. Higher order bits in the word represent pixels to the left of the lower order bits. Bitmaps have a width and a height, measured in pixels. The width does not need to be a multiple of 16. In this case, remaining bits in the last word of a row are unused, so that each row starts with a new bitmap word. The GR_BITMAP_SIZE macro can be used to allocate the proper number of bitmap words for a bitmap, as in: GR_BITMAP_SIZE(width, height). The symbol GR_MAX_BITMAP_SIZE is the number of bitmap words required for the maximum sized cursor. ERROR CODES Calls to the graphics libraries may produce errors. Most errors that occur are due to specifying a window or graphics context which does not exist, or attempting an operation which is illegal. Many things are allowed even if pointless, such as drawing outside of the window boundaries, or while a window is not mapped. The things which return errors are those which definitely indicate a program bug, attempts to exceed the system limits, or a fatal device error. In order to be as efficient as possible, error codes are not returned by individual function calls. Instead, if a function fails, an error event is generated which will eventually be noticed by the program at a possibly much later time. This allows many drawing requests to be sent at one time without having to worry about the status of each one. Error events are detected when the program checks for events, such as by calling GrGetNextEvent. At this point, if an error had occurred, a special error handler routine is called to notice the error. If the program had not set up its own error handler, a default one is called which will disconnect from the server, print out an indication of the error, and exit the program. The following is a list of the possible errors: GR_ERROR_BAD_WINDOW_ID the specified window id is unknown GR_ERROR_BAD_GC_ID the specified graphics context id is unknown GR_ERROR_BAD_CURSOR_SIZE the specified cursor is too large GR_ERROR_MALLOC_FAILED no more memory is available in the server GR_ERROR_BAD_WINDOW_SIZE the specified window size is illegal GR_ERROR_KEYBOARD_ERROR an error occurred reading from the keyboard GR_ERROR_MOUSE_ERROR an error occurred reading from the mouse GR_ERROR_INPUT_ONLY_WINDOW drawing was attempted in an input-only window GR_ERROR_ILLEGAL_ON_ROOT_WINDOW an illegal operation was attempted on the root GR_ERROR_TOO_MUCH_CLIPPING complexity of windows exceeded clipping limits GR_ERROR_SCREEN_ERROR an error occurred talking to the screen driver GR_ERROR_UNMAPPED_FOCUS_WINDOW attempted to set focus to an unmapped window GR_ERROR_BAD_DRAWING_MODE illegal drawing mode specified for a GC SCREEN PROPERTIES You do not have to hard code the size of the screen or the number of colors available in your program. Instead, you can find this information out dynamically after the connection is made to the graphics server, by using the GrGetScreenInfo call. This returns the above information, and in addition returns the color values for black and white, the aspect ratio of pixels, the number of built-in fonts available, and the modifiers and buttons which are available. The aspect ratio is useful for drawing objects which need to be scaled correctly, such as circles. The aspect ratio is the quotient of xdpcm and ydpcm, which are integer values. typedef struct { GR_SIZE rows; /* number of rows on screen */ GR_SIZE cols; /* number of columns on screen */ GR_SIZE xdpcm; /* dots/centimeter in x direction */ GR_SIZE ydpcm; /* dots/centimeter in y direction */ GR_COLOR maxcolor; /* maximum legal color value */ GR_COLOR black; /* the color black */ GR_COLOR white; /* the color white */ GR_COUNT fonts; /* number of built-in fonts */ GR_BUTTON buttons; /* buttons which are implemented */ GR_MODIFIER modifiers; /* modifiers which are implemented */ } GR_SCREEN_INFO; INCLUDE FILE AND GRAPHICS LIBRARY To use the graphics server, your program must include "graphics.h". This should be put into /usr/include, so that your program simply has the following line at the top: #include <graphics.h> Including this file gives you all of the definitions you need to use the graphics library. These are the typedefs, function declarations, event structures, and various constants. When loading your program, you need to load the graphics server into the program by using the -lgraph option in the cc command. For example, if your program is called myprog, then you could build it using the following: cc -o myprog myprog.c -lgraph TYPEDEFS The following is a list of the typedefs in the include file, and a short description of their purpose. Refer to their definitions in graphics.h to find out what their actual C base type is. Most are shorts, unsigned shorts, or longs. GR_COORD coordinate value (x, y locations, signed) GR_SIZE size value (widths, heights, signed) GR_COUNT number of items (signed) GR_COLOR full color value (32 bit value for full generality) GR_COLOR8 eight bit color value (8 bit value for efficient storage) GR_BITMAP bitmap unit (single words of 16 bits for bitmaps) GR_MODE drawing mode (setting, xoring, anding, oring) GR_CHAR text character (normal chars) GR_ID resource ids (window, graphics context, pixmap) GR_DRAW_ID drawable id (window, pixmap) GR_WINDOW_ID window id (identifies individual window) GR_PIXMAP_ID pixmap id (identifies individual pixmaps, not yet used) GR_GC_ID graphics context id (identifies indiviual graphics contexts) GR_FONT font number (identifies individual fonts, first few built-in) GR_BOOL boolean value (GR_TRUE or GR_FALSE) GR_FUNC function codes (not for clients to use) GR_ERROR error value (reasons for graphics calls to fail) GR_EVENT_TYPE event types (identifies the type of event) GR_BUTTON button flags (which mouse buttons are depressed) GR_MODIFIER modifier flags (CTRL, SHIFT, etc) GR_EVENT_MASK event masks (mask values corresponding to event types) GR_FUNC_NAME function name (for error reporting) GR_ERROR_FUNC error function (for defining error handlers) The following typedefs may be useful to your program. None of the library functions (currently) accept any of these structures as arguments, except for the GrPoly and GrFillPoly routines, which use GR_POINT. typedef struct { GR_COORD x; /* x coordinate */ GR_COORD y; /* y coordinate */ } GR_POINT; typedef struct { GR_COORD x1; /* x coordinate of first point */ GR_COORD y1; /* y coordinate of first point */ GR_COORD x2; /* x coordinate of second point */ GR_COORD y2; /* y coordinate of second point */ } GR_LINE; typedef struct { GR_COORD x; /* x coordinate of center */ GR_COORD y; /* y coordinate of center */ GR_SIZE rx; /* radius in x direction */ GR_SIZE ry; /* radius in y direction */ } GR_ELLIPSE; typedef struct { GR_COORD x; /* x coordinate of top left corner */ GR_COORD y; /* y coordinate of top left corner */ GR_SIZE width; /* width of rectangle */ GR_SIZE height; /* height of rectangle */ } GR_RECT; LIMITS The coordinate system is limited to integers in the range GR_COORD_MIN to GR_COORD_MAX. This is -32768 to 32767, and fits in a short. The maximum size of a cursor definition is GR_MAX_CURSOR_SIZE, which is 16 pixels by 16 pixels. The complexity of overlapping windows is limited to GR_MAX_CLIPRECTS regions, which is 200. Each window which overlaps another requires another 1 to 4 regions depending on its position and size. GRAPHICS CALLS int GrOpen() Open a connection to the graphics server. This must be the first graphics function used by your program. Currently, this sets the screen into graphics mode. Returns zero if successful, -1 on failure. void GrClose() Close the connection to the graphics server, first flushing any graphics calls that have been buffered. Currently, this sets the screen back into text mode. This (currently) should be called before your program exits, otherwise the screen will be left in graphics mode. If this occurs, you can run the 'tm' program to reset the terminal to text mode. GR_ERROR_FUNC GrSetErrorHandler(func) GR_ERROR_FUNC func; /* function to handle errors */ Set an error handling routine, which will be called on any errors from the server (when events are asked for by the client). If zero is given, then a default routine will be used which will describe the error and exit. Returns the previous error handler (0 if none). When an error occurs, the error handling function is called with the following parameters: GR_ERROR, GR_FUNC_NAME, and GR_ID. These are the error code, the name of the function which failed, and a resource id (0 if not meaningful). The error routine can return if desired, but without corrective action new errors will probably occur soon. void GrGetScreenInfo(sip) GR_SCREEN_INFO *sip; /* location to return info into */ Return useful information about the screen. This information returned has been documented above. void GrGetFontInfo(font, fip) GR_FONT font; /* font number */ GR_FONT_INFO *fip; /* address of font info */ Return useful information about the specified font number. This information is the font number, the height of the font, the maximum width of any character in the font, the height of the baseline, a flag indicating whether or not the font is fixed-width, and a table of the individual widths of each character in the font. If the font is unknown, the returned font number is set to zero and the remainder of the information is undefined. Refer to graphics.h for a definition of the fields of GR_FONT_INFO. void GrGetGCInfo(gc, gcip) GR_GC_ID gc; /* graphics context */ GR_GC_INFO *gcip; /* address of graphics context info */ Return useful information about the specified graphics context. This information is the graphics context id, the current font, the foreground and background colors, and so on. If the graphics context is unknown, the returned id is 0, and the other information is undefined. Refer to graphics.h for a definition of the fields of GR_GC_INFO. voidGrGetGCTextSize(gc, cp, len, retwidth, retheight, retbase) GR_GC_ID gc; /* graphics context containing font */ GR_CHAR *cp; /* address of text string */ GR_SIZE len; /* length of text string */ GR_SIZE *retwidth; /* returned width of string */ GR_SIZE *retheight; /* returned height of string */ GR_SIZE *retbase; /* returned height of baseline */ Return the size of a text string for the font in a graphics context. This is the width of the string, the height of the string, and the height above the bottom of the font of the baseline for the font. The returned sizes are in pixels. void GrGetNextEvent(ep) GR_EVENT *ep; /* address where event is returned */ Return the next event from the event queue, waiting for it if necessary. If a graphics error had occurred, the error handler will be called at this point. This routine first flushes any buffered graphics commands. The GR_EVENT is a union of all the possible events. The type field of the union indicates which of the possible events took place, and then the correct element of the union can be used to access that particular event type's data. void GrCheckNextEvent(ep) GR_EVENT *ep; /* address where event is returned */ Return the next event from the event queue if one is ready. If one is not ready, then the event type GR_EVENT_TYPE_NONE is returned. Therefore, this routine never blocks. This routine first flushes any buffered graphics commands. void GrPeekEvent(ep) GR_EVENT *ep; /* address where event is returned */ Return the next event from the event queue if one is ready, without removing it from the queue. If one is not ready, then the type GR_EVENT_TYPE_NONE is returned. This routine never blocks. This routine first flushes any buffered graphics commands. void GrSelectEvents(wid, eventmask) GR_WINDOW_ID wid; /* window id */ GR_EVENT_MASK eventmask; /* mask of events wanted */ Select events for a window for this client. The events are a bitmask specifying the events desired for this window. This totally replaces any previously selected event mask for the window. GR_WINDOW_ID GrNewWindow(parent, x, y, width, height, bordersize, background, bordercolor) GR_WINDOW_ID parent; /* parent id */ GR_COORD x; /* x position relative to parent */ GR_COORD y; /* y position relative to parent */ GR_SIZE width; /* width */ GR_SIZE height; /* height */ GR_SIZE bordersize; /* size of border */ GR_COLOR background; /* background color */ GR_COLOR bordercolor; /* border color */ Allocate a new input-output window which is a child of the specified window. A new top-level window is made by specifying a parent of GR_ROOT_WINDOW_ID. The x and y position is the upper left corner of the window, relative to the parent's upper left corner. These corners are only for the drawable area of the windows, so that the border does not affect the position. An input-output window cannot be made as a child of an input-only window. The new window starts off unmapped, and must be mapped before it can be seen. The new window inherits the cursor of the parent window, and initially is set to select no events. This routine returns the window id of the window which can be used in other calls. GR_WINDOW_ID GrNewInputWindow(parent, x, y, width, height) GR_WINDOW_ID parent; /* parent id */ GR_COORD x; /* x position relative to parent */ GR_COORD y; /* y position relative to parent */ GR_SIZE width; /* width */ GR_SIZE height; /* height */ Allocate a new input-only window which is a child of the specified window. An input-only window is invisible, and cannot be drawn into. It's only purposes are that it can select events, and can have it's own cursor. The new window starts off unmapped, and must be mapped before it is effective. The new window inherits the cursor of the parent window, and initially is set to select no events. This routine returns the window id of the window which can be used in other calls. void GrDestroyWindow(wid) GR_WINDOW_ID wid; /* window to destroy */ This unmaps and then destroys the specified window, and all of its children. The root window cannot be destroyed. After destroying a window, you must be careful about handling events which refer to the dead window, but which have not been read yet. void GrGetWindowInfo(wid, wip) GR_WINDOW_ID wid; /* window id to find out about */ GR_WINDOW_INFO *wip; /* location to return info into */ Return useful information about the specified window. Refer to the graphics.h include file for the definition of GR_WINDOW_INFO to see what data is returned. If the window id is not valid, an error is NOT generated. Instead, the wid value in the returned structure is set to zero, and the other fields are not defined. GR_GC_ID GrNewGC() Allocate a new graphics context with default parameters. These defaults are: background of black, foreground of white, font as font 0, and drawing mode as setting. This routine returns the id for the graphics context which can be used in other calls. GR_GC_ID GrCopyGC(gc) GR_GC_ID gc; /* graphics context to copy */ Allocate a new graphics context which is a copy of another one. The new graphics context has the same parameter values as the old one, but is then independent. This routine returns the id for the graphics context which can be used in other calls. void GrDestroyGC(gc) GR_GC_ID gc; /* graphics context to destroy */ Destroy an existing graphics context. void GrMapWindow(wid) GR_WINDOW_ID wid; /* window to be mapped */ Map the window to make it (and possibly its children) visible on the screen. This paints the border and background of the window, and creates an exposure event to tell the client to draw into it. void GrUnmapWindow(wid) GR_WINDOW_ID wid; /* window to be unmapped */ Unmap the window to make it and its children invisible on the screen. void GrRaiseWindow(wid) GR_WINDOW_ID wid; /* window to be raised */ Raise the window to the highest level among its siblings. This means that this window will be visible in preference to those siblings. Siblings are windows which have the same parent as this window. void GrLowerWindow(wid) GR_WINDOW_ID wid; /* window to be lowered */ Lower the window to the lowest level among its siblings. This means that this window will be covered by any siblings which overlap it. void GrMoveWindow(wid, x, y) GR_WINDOW_ID wid; /* window to be lowered */ GR_COORD x; /* new relative x position */ GR_COORD y; /* new relative y position */ Move the window to the specified position relative to its parent. void GrResizeWindow(wid, width, height) GR_WINDOW_ID wid; /* window to be lowered */ GR_SIZE width; /* new width of window */ GR_SIZE height; /* new height of window */ Resize the window to be the specified size. Resizing of a window can generate exposure events. void GrClearWindow(wid, exposeflag) GR_WINDOW_ID wid; /* window id */ GR_BOOL exposeflag; /* nonzero to cause an exposure */ Clear the specified window by setting it to its background color. If the exposeflag is nonzero, then this also creates an exposure event for the window. void GrSetFocus(wid) GR_WINDOW_ID wid; /* window id */ Set the focus to a particular window. This makes keyboard events only visible to that window or children of it, depending on the pointer location. Setting the focus window to the root window makes the input focus track the pointer (which is the default). void GrSetBorderColor(wid, color) GR_WINDOW_ID wid; /* window id */ GR_COLOR color; /* color for border */ Set the border of a window to the specified color. void GrSetCursor(wid, width, height, hotx, hoty, foreground, background, fgbitmap, bgbitmap) GR_WINDOW_ID wid; /* window id to set cursor for */ GR_SIZE width; /* width of cursor */ GR_SIZE height; /* height of cursor */ GR_COORD hotx; /* relative x position of hot spot */ GR_COORD hoty; /* relative y position of hot spot */ GR_COLOR foreground; /* foreground color of cursor */ GR_COLOR background; /* background color of cursor */ GR_BITMAP *fgbitmap; /* foreground bitmap */ GR_BITMAP *bgbitmap; /* background bitmap */ Specify a new cursor for a window. This cursor will only be used within that window, and by default for its new children. The cursor is defined by giving its width and height, its foreground and background colors, its foreground and background bitmaps, and its "hot spot" position. If a pixel is specified for both the foreground and background bitmaps, then the foreground has precedence. The hot spot is an offset from the upper left corner of the bitmap, and is the location in the cursor which is important. void GrMoveCursor(x, y) GR_COORD x; /* new x position of cursor */ GR_COORD y; /* new y position of cursor */ Move the cursor to the specified absolute screen coordinates. The coordinates are that of the defined hot spot of the cursor. The cursor's appearance is changed to that defined for the window in which the cursor is moved to. void GrFlush() Flush the graphics buffer so that all previous requests will be executed. This is only needed if you do not check events quickly and want to see the results on the screen soon, since checking for events does an automatic flush. void GrSetGCForeground(gc, foreground) GR_GC_ID gc; /* graphics context id */ GR_COLOR foreground; /* foreground color */ Set the foreground color in a graphics context. The default is white. void GrSetGCBackground(gc, background) GR_GC_ID gc; /* graphics context id */ GR_COLOR background; /* background color */ Set the background color in a graphics context. The default is black. void GrSetGCUseBackground(gc, flag) GR_GC_ID gc; /* graphics context id */ GR_BOOL flag; /* TRUE if background is drawn */ Set whether or not the background color is drawn in bitmaps and text. This affects GrBitmap, GrArea8, and GrText. The default is GR_TRUE. void GrSetGCMode(gc, mode) GR_GC_ID gc; /* graphics context id */ GR_MODE mode; /* drawing mode */ Set the drawing mode in a graphics context. The drawing mode is one of GR_MODE_SET, GR_MODE_XOR, GR_MODE_AND, or GR_MODE_OR. The default is GR_MODE_SET. void GrSetGCFont(gc, font) GR_GC_ID gc; /* graphics context id */ GR_FONT font; /* text font */ Set the font used for text drawing in a graphics context. The font is a number identifying one of several fonts. Font number 0 is always available, and is the default font. void GrLine(id, gc, x1, y1, x2, y2) GR_DRAW_ID id; GR_GC_ID gc; GR_COORD x1; GR_COORD y1; GR_COORD x2; GR_COORD y2; Draw a line in the specified drawable using the specified graphics context. void GrRect(id, gc, x, y, width, height) GR_DRAW_ID id; GR_GC_ID gc; GR_COORD x; GR_COORD y; GR_SIZE width; GR_SIZE height; Draw the boundary of a rectangle in the specified drawable using the specified graphics context. void GrFillRect(id, gc, x, y, width, height) GR_DRAW_ID id; GR_GC_ID gc; GR_COORD x; GR_COORD y; GR_SIZE width; GR_SIZE height; Fill a rectangle in the specified drawable using the specified graphics context. The boundary of this rectangle is identical to that drawn by the GrRect function. void GrEllipse(id, gc, x, y, rx, ry) GR_DRAW_ID id; GR_GC_ID gc; GR_COORD x; GR_COORD y; GR_SIZE rx; GR_SIZE ry; Draw the boundary of an ellipse in the specified drawable with the specified graphics context. void GrFillEllipse(id, gc, x, y, rx, ry) GR_DRAW_ID id; GR_GC_ID gc; GR_COORD x; GR_COORD y; GR_SIZE rx; GR_SIZE ry; Fill an ellipse in the specified drawable using the specified graphics context. void GrBitmap(id, gc, x, y, width, height, bitmaptable) GR_DRAW_ID id; GR_GC_ID gc; GR_COORD x; GR_COORD y; GR_SIZE width; GR_SIZE height; GR_BITMAP *bitmaptable; Draw a rectangular area in the specified drawable using the specified graphics context, as determined by the specified bit map. This differs from rectangle drawing in that the rectangle is drawn using the foreground color and possibly the background color as determined by the bit map. Bits which are 1 are the foreground, and bits which are 0 are the background. Each row of bits is aligned to the next bitmap word boundary (so there can be padding at the end of each row). The background bit values are only written if the usebackground flag is set in the GC. void GrArea8(id, gc, x, y, width, height, colortable) GR_DRAW_ID id; GR_GC_ID gc; GR_COORD x; GR_COORD y; GR_SIZE width; GR_SIZE height; GR_COLOR8 *colortable; Draw a rectangular area in the specified drawable using the specified graphics context. This differs from rectangle drawing in that the color values for each pixel in the rectangle are specified. The color values are estricted to 8 bit values. The color table is indexed row by row from left to right. Table values whose color matches the background color are only written if the usebackground flag is set in the GC. void GrReadArea8(id, x, y, width, height, colortable) GR_DRAW_ID id; GR_COORD x; GR_COORD y; GR_SIZE width; GR_SIZE height; GR_COLOR8 *colortable; Read the color values from the specified rectangular area of the specified drawable into a supplied buffer. If the drawable is a window which is obscured by other windows, then the returned values will include the values from the covering windows. Regions outside of the screen boundaries, or from unmapped windows will return black. void GrPoint(id, gc, x, y) GR_DRAW_ID id; GR_GC_ID gc; GR_COORD x; GR_COORD y; Draw a point in the specified drawable using the specified graphics context. void GrPoly(id, gc, count, pointtable) GR_DRAW_ID id; GR_GC_ID gc; GR_COUNT count; GR_POINT *pointtable; Draw a polygon in the specified drawable using the specified graphics context. The polygon is only complete if the first point is repeated at the end. Note: currently if the polygon crosses itself, and the drawing mode is set to XOR, then the individual line segments will affect each other. The endpoints of the lines are correct, however. void GrFillPoly(id, gc, count, pointtable) GR_DRAW_ID id; GR_GC_ID gc; GR_COUNT count; GR_POINT *pointtable; Draw a filled polygon in the specified drawable using the specified graphics context. The last point may be a duplicate of the first point, but this is not required. Note: currently only convex polygons are filled properly. void GrText(id, gc, x, y, str, count) GR_DRAW_ID id; GR_GC_ID gc; GR_COORD x; GR_COORD y; GR_CHAR *str; GR_COUNT count; Draw a text string at the specified location in the specified drawable using the specified graphics context. The background of the characters are only drawn if the usebackground flag in the GC is set. EXAMPLE PROGRAM The following simple program opens the graphics, creates a window, prints some text in it, waits for the mouse to be clicked in the window, then exits. include <stdio.h> include <graphics.h> define MARGIN 50 /* margin around window */ main() { GR_WINDOW_ID wid; /* window id */ GR_GC_ID gc; /* graphics context id */ GR_EVENT event; /* current event */ GR_SCREEN_INFO si; /* screen information */ if (GrOpen() < 0) { fprintf(stderr, "Cannot open graphics\n"); exit(1); } GrGetScreenInfo(&si); wid = GrNewWindow(GR_ROOT_WINDOW_ID, MARGIN, MARGIN, si.cols - MARGIN * 2, si.rows - MARGIN * 2, 1, si.black, si.white); GrSelectEvents(wid, GR_EVENT_MASK_BUTTON_DOWN | GR_EVENT_MASK_EXPOSURE); GrMapWindow(wid); gc = GrNewGC(); while (1) { GrGetNextEvent(&event); switch (event.type) { case GR_EVENT_TYPE_BUTTON_DOWN: if (event.button.wid != wid) break; GrClose(); exit(0); case GR_EVENT_TYPE_EXPOSURE: if (event.exposure.wid == wid) GrText(wid, gc, 50, 50, "EXIT", 4); break; } } } For a more complete demonstration program, see the file "demo.c" in the microwin/src/demos/nanox directory.

Mohanavadivelu (talk) 04:31, 22 July 2010 (UTC)

How does this apply to the content of this page? MBisanz ^talk 04:36, 22 July 2010 (UTC)

IP Vote

Are IP's allowed to !vote in Move requests? The C of E. God Save The Queen! (talk) 08:29, 22 July 2010 (UTC)

Prasanna Sanjeev

File:Http://testdiyaprasanna.bizland.com/pas.jpg

Prasanna Sanjeev born on January 07, 1987 in Manipal. —Preceding unsigned comment added by Prassuprashi (talk • contribs) 11:43, 31 July 2010 (UTC)

Edit request from Rndynolen, 4 August 2010

{{editsemiprotected}} Would like to add Photos of the Oklahoma Memorial on the island of Oahu Hawaii (Ford island). I am from oklahoma and have lived in hawaii for 3.5 yrs. I am moving back and this would be great for oklahomas people to see.

Rndynolen (talk) 06:11, 4 August 2010 (UTC)

 Not done: Please place the request on the page you would like to edit. Thanks, Stickee (talk) 06:33, 4 August 2010 (UTC)

Clarify Table terminology

In the Table of access rights, it is not clear what the difference is between ‘Revoked’ and ‘Denied’.

After trying to understand this, I assume it means that when a user is Blocked, then the Revoked rights are Denied.

The problem is that there are numerous boxes under Blocked users that are listed as Denied rather than Revoked, and yet I assume that even Autoconfirmed accounts that have been blocked would no longer have access that is Denied to Blocked accounts.

If it is the case that Revoked and Denied access rights are actually equivalent, then it would be very helpful to mention this. If they are not, then at least a hint of the differences would be helpful to understand the system. Peterbbishop (talk) 17:43, 9 August 2010 (UTC)

Could you help?

Hello all. I've decided to create an account after editing for a while with my IP address and would like to upload files but cannot as my account is new. When will I be able to? Hugahoody (talk) 21:16, 18 August 2010 (UTC)

If you are freely licensing them, see commons:commons:upload. –xeno^talk 21:27, 18 August 2010 (UTC)

Thanks but I believe they are unfree. They are the images in the category 'Images which should be in PNG format'. Hugahoody (talk) 21:32, 18 August 2010 (UTC)

"editor"

I've added the editor usergroup to the list, with info taken from Wikipedia:Administrators'_noticeboard/Archive214#Researchers, just to satisfy the curiosity of anyone who happens to stumble upon it and wonder what it is. —Soap— 23:34, 21 August 2010 (UTC)

Edit request from 76.104.178.139, 4 October 2010

{{edit semi-protected}} CHANGE "With the throne empty, he was succeeded by Cixi's handpicked heir, his two year old nephew Puyi, who became the Xuantong Emperor. Guangxu's consort, who became the Empress Dowager Longyu. In another coup de'tat," TO "With the throne empty, he was succeeded by Cixi's handpicked heir, his two year old nephew Puyi, who became the Xuantong Emperor. Guangxu's consort became the Empress Dowager Longyu. In another coup d'etat,"?

76.104.178.139 (talk) 19:36, 4 October 2010 (UTC)

 Not done: Wrong talk page. Please make your request on the talk page of the article you want to change. Celestra (talk) 20:06, 4 October 2010 (UTC)

See someone's status as autoconfirmed

Can someone see if someone else is an autoconfirmed or not?  Kenrick  Talk 12:39, 6 January 2011 (UTC)

Not really, AFAIK. You could check their edit count with a tool that shows deleted edits like this one, and check the account creation date from the logs, and if they have 10 edits total and are older then 4 days, you can assume they are autoconfirmed. ^Avic_ennasis @ 02:26, 9 Adar I 5771 / 13 February 2011 (UTC)

"Anonymous users"

{{editsemiprotect}}

Please change all occurrences of "anonymous user[s]" to "unregistered user[s]", as per WP:HUMAN, WP:ANONYMOUS and Wikipedia:IP edits are not anonymous.

I think referring to IP users as "anonymous users" is incorrect and confusing. Registered users who do not adopt their real name as their username are also anonymous. In fact, they are arguably more anonymous, since their IP address is hidden.

Also, the phrase is often used in a discriminatory way by editors who do not fully appreciate (yet) the value and potential of unregistered users.

I propose we call a spade a spade, and change to "unregistered users", or "IP users". 113.197.210.85 (talk) 09:53, 12 February 2011 (UTC)

 Done -Atmoz (talk) 15:27, 14 February 2011 (UTC)

{{editsemiprotect}}

Many thanks! Actually I notice two more occurrences of "anonymous users". Can someone please change them as well? Actually one of them seems to refer to a specific MediaWiki command. If that's the case, I'm fine to leave it as it is, but please do let me know and I'll take this up to the MediaWiki development team. Thanks again. 220.100.21.237 (talk) 23:27, 14 February 2011 (UTC)

 Done actually, the only instance of "anonymous users" I could find was the wiki setting... ~ Matthewrbowker ^{Say hi!} 01:35, 15 February 2011 (UTC)

{{editsemiprotect}}

Uhm... sorry but I cannot see any changes. I am referring to here and the table heading here (or just search the page for "anonymous"). Can you please replace them as well? Thanks. 124.147.109.144 (talk) 14:15, 15 February 2011 (UTC)

 Done Sorry. Missed one because it was in a template. The other is actually a setting in the software that administrators can tick when blocking users, so until/if that gets changed I think it's best to leave as is here. -Atmoz (talk) 03:10, 16 February 2011 (UTC)

OK yes, thought so, I'll take this to MediaWiki. Thanks again. 113.197.243.71 (talk) 23:38, 16 February 2011 (UTC)

Autoconfirmed

When you pass 10 edits after 4 days, do you automatically get the status of autoconfirmed? PaoloNapolitano (talk) 14:35, 27 February 2011 (UTC)

Mine was automatic. I just found it under "My Preferences" and came here to find out what it means.TerraNirvana (talk) 01:05, 29 March 2011 (UTC)

Proposal to rename 'confirmed' usergroup to 'preconfirmed'

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

It is proposed to rename the 'confirmed' usergroup to 'preconfirmed', this way we can designate by confirmed users the users who are either preconfirmed or autoconfirmed. I propose 'preconfirmed' because those users are given manually the same rights as the autoconfirmed (implicit) group, 'before' they reach the autoconfirmed treshold. Note that the rename cannot be done in the mediawiki configuration but it's not a problem, we can still modify most of the messages via mediawiki pages. Such a rename has already been done for the edit filter usergroup. Cenarium (talk) 21:35, 12 April 2011 (UTC)

• Oppose The confirmed usergroup shouldn't be renamed to preconfirmed. Preconfirmed would mean a user before being confirmed. Autoconfirmed is when the system automaticly confirmed the user, but confimed is when an sysop trusts the user as confirmed, before getting autoconfirmed. ~~EBE123~~ ^talk_Contribs 22:24, 13 April 2011 (UTC)
• Oppose Technically it would be "manually confirmed" versus "confirmed by meeting certain thresholds" however those get reduced to "confirmed" and "autoconfirmed". I don't know of any process where someone is confirmed before their account is created, which is what preconfirmed would lead to. Sven Manguard Wha? 00:33, 16 April 2011 (UTC)
• Comment Why do we have two separate usergroups anyway? Marcus Qwertyus 19:57, 16 April 2011 (UTC)

  I think that's a good question.. Why can't 'Autoconfirmed' just be the regular 'Confirmed' flag? The same one that admins can add/remove. Instead of being some virtual, invisible user level. -- œ^™ 07:28, 19 April 2011 (UTC)

• Oppose I'm seeing way too many "confirmed"s in this thread already, and it's making me dizzy, but I don't see a major need to do this. /ƒETCHCOMMS/ 01:43, 18 April 2011 (UTC)
• Oppose Unnecessary triviality, the abuse filter name was changed because not all edits made that triggered a filter were abusive. Altering Confirmed to Preconfirmed is completely unnecessary. —James ^{(Talk • Contribs)} • 10:04pm • 12:04, 18 April 2011 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

New users uploading files or images

Wikipedia:User_access_levels#New_users section does not say whether or not they can. I don't know because I am not a new user. Could someone please say, or add it to the section. Thanks. Anna Frodesiak (talk) 00:07, 25 April 2011 (UTC)

Top User

What is the most important and top user on Wikipedia? — Preceding unsigned comment added by MrAmberGold (talk • contribs) 09:06, 11 July 2011 (UTC)

There is no "top user". And all users who volunteer their time to improve Wikipedia are equally important. User access levels don't grant any sort of 'status', they're just tools to help do a job that needs to be done. -- œ^™ 02:50, 26 July 2011 (UTC)

The "top user" used to be User:Jimbo Wales, our founder (Jimmy Wales), but he now holds no more privileges than some other users. Wikipedia doesn't like to think of itself as a "one-top-user" website, but instead a collaborative website where everyone is equally treated.Jasper Deng (talk) 21:19, 1 January 2012 (UTC)

Edit request on 23 January 2012

Grammar fix under Autoconfirmed area(two colons and ambiguous structure).

Currently: The precise requirements for autoconfirmed status vary according to circumstances: for most users on English Wiki accounts the following must (usually) take place: that they are both more than four days old and have made at least 10 edits are considered autoconfirmed.

Change to: The precise requirements for autoconfirmed status vary according to circumstances. For most users on English Wiki accounts the following must (usually) take place: Users that they are both more than four days old and have made at least 10 edits are considered autoconfirmed.

Aqme28 (talk) 07:49, 23 January 2012 (UTC)

 Doneish. I've changed it to make it clear, but not to how you recommended, I changed it to "The precise requirements for autoconfirmed status vary according to circumstances, for most users on English Wiki accounts that are more than four days old and have made at least 10 edits are considered autoconfirmed."--Jac16888 ^Talk 15:27, 23 January 2012 (UTC)

afttest and afttest-hide

A user asked at the Help desk what afttest users were. Two experienced helpers had trouble replying. I discovered the apparent answer at Special:ListGroupRights and boldly added it here to resolve redlinks at Special:ListGroupRights. —teb728 t c 09:03, 3 February 2012 (UTC)

Does vandalism count towards getting autoconfirmed

Would a persistent vandal become autoconfirmed if they did ten vandal edits and managed to escape getting blocked for 4 days? If this is the case then semi-protection is a rather pointless tool. Roger (talk) 21:22, 27 May 2012 (UTC)

Yes, they would become autoconfirmed. That doesn't mean semi-protection is pointless. Lots of vandals are unregistered or unconfirmed and don't bother to get a confirmed account. PrimeHunter (talk) 00:38, 28 May 2012 (UTC)

New users

A user who edits through an account they have registered may immediately create pages in any namespace (except the MediaWiki namespace, and limited to eight per minute). This does not seem true. It appears that new users have to be auto-confimred before they can create new articles on Wikipedia.(striked) Regards, SunCreator ^(talk) 11:38, 2 June 2012 (UTC)

It appears you won't believe my answer at Wikipedia talk:New contributors' help page#New users can't create new articles until auto-confirmed which linked to WP:UAL#New users. Will you believe the automatically generated Special:ListGroupRights#user: "Create pages (which are not discussion pages) (createpage)". If not then you can find many examples at Special:NewPages. A red talk page is often a new user. PrimeHunter (talk) 12:33, 2 June 2012 (UTC)

Good if true, but what evidence do we have? A redlist does not show a new user just somoene without a talk page. Regards, SunCreator ^(talk) 13:02, 2 June 2012 (UTC)

Have found that User:Soumitramehrotra created both an account and a new article today. Regards, SunCreator ^(talk) 13:15, 2 June 2012 (UTC)

That's why I said "often". I tested a few cases before posting and falsely assumed you would do the same right away if you still didn't believe me, but I see you eventually got there. I have now tested the first 10 cases with red user talk pages and all 10 were new users. PrimeHunter (talk) 14:25, 2 June 2012 (UTC)

Rights of indef blocked users

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

Should rights of indef blocked users (e.g. reviewer/rollbacker/autopatroller) be removed or left as is? Nobody Ent 01:52, 5 June 2012 (UTC)

IMO, once they are blocked they are probably there for a reason (most likely socking or vandalism so yes any permissions except maybe reviewer should be removed. Kumioko (talk) 01:57, 5 June 2012 (UTC)

• Left as is - I've seen editors indeffed for a short period of time until the situation that caused them to be indeffed was resolved. Removing these rights seems to be unneccesary (and truly indeffed users won't be able to use them anyways). --NeilN ^{talk to me} 02:00, 5 June 2012 (UTC)
• Yes, they should be removed, at least in most cases (I can imagine rare exceptions). An indefinite block is not necessarily an infinite block and users who have lost the community's trust to such an extent as to warrant one should not have any tools requiring extra trust awaiting their potential return.--Fuhghettaboutit (talk)

• But an indef does not always represent a lost of community trust. A sockpuppeting admin would be desysopped, but one blocked for civility issues wouldn't be. Why should "lesser" rights be any different? Nikkimaria (talk) 03:18, 5 June 2012 (UTC)

• Remove (Copied from my user talk page) There is no reason for indef blocked users to retain any advanced permissions; I feel that it can give the wrong impression of the project if someone were to notice that an infef blocked user holds "a position of trust" in their retention of advanced user rights even while indef blocked. Furthermore, if a user would to ever be unblocked, I feel any permissions that they held before their block would have to be reconsidered on a case by case basis due to the fact that they were blocked for a reason and they may no longer be fit to hold some or all of their former user rights. Best, Mifter (talk) 02:15, 5 June 2012 (UTC)
• Leave as-is (usually). If the reason for indef is directly related to such a right, by all means remove it - for example, take autopatrolled from a hoaxer. I might see total removal for things like sockpuppetry also, where an indef actually does reflect a loss of community trust. But for other issues, it doesn't, and removal isn't necessary. Indef does not mean infinite, and it's too easy for an unblocking admin to overlook a removed right. Unless we have a reason to do otherwise, we should leave rights as they were when the user was blocked: no more, no fewer. It's not like we've a shortage of flags. Nikkimaria (talk) 03:18, 5 June 2012 (UTC)
• Left as-is Unless the indef block is some how related to the permission, or there is a reason to think the editor would abuse the permission if ever unblocked it they should be left alone. Editors are blocked for a variety of reasons and a one size fits all approach would be a bad idea. Monty₈₄₅ 03:38, 5 June 2012 (UTC)

To run through the permissions: Reviewer - currently does nothing, if pending is ever turned back on, will only be an issue if the editor has BLP issues; Rollback - as twinkle cannot be revoked and contains essentially the rollback function, rollback provides only trivially greater opportunity for disruption; Autopatrolled - Reduces scrutiny of created articles, only an issue if the editor has a history of problematic article creation; File mover - Ok, this one provides a function that lets anyone granted it conduct an action not available to other editors, but I'm not familiar with it getting much abuse. Accountcreator - Only removes a rate limit, not really a concern unless the editor has a history of socking; Ipblock-exempt - Likewise, unless the editor has a history of socking, this shouldn't be an issue; Edit Filter managers - Great potential for abuse, but by my count only about 10 non-admins accounts have the right, and at least a couple of those are well known socks of editors with admin rights on other accounts. The only one I would say should be removed proactively without cause at the time of block is edit filter. Monty₈₄₅ 07:14, 5 June 2012 (UTC)

I hope you mean alternate accounts, not socks? Nobody Ent 09:59, 5 June 2012 (UTC)

• Left as-is, with future removal or non-removal of rights on a case-by-case basis. While people are usually blocked due to their own misconduct, let's not forget that people also get blocked for things that are not their fault: a mistake, a compromised account, blocks in bad faith by a rogue admin or another compromised account, and so on. Even if someone is blocked due to misconduct, this doesn't always mean they're thoroughly untrustworthy with all possible tools if they return. We should also remember that these tools are already disabled in the course of a block. When the reason for a block ends, the reason for removal of access levels often ends, too. szyslak (t) 04:16, 5 June 2012 (UTC)
• Leave as-is per Neil, Nikkimaria and Szyslak. -- ɑηsuмaη ^{ʈ ᶏ ɭ Ϟ} 09:11, 5 June 2012 (UTC)
• Leave as is, It only takes one admin, to set an indef block, and can happen without full understanding of the situation. Once things get figured out, there is plenty of time to remove tools, with full community involvement and well thought out rational. indefinite means for a time yet to be defined, that could be for a few minutes or forever. Jeepday (talk) 13:03, 5 June 2012 (UTC)
• Left alone per Monty. If there is a separate rationale, and very often there will be, then that is fine and it should be explained separately, and to the editor being stripped of rights. Dennis Brown - 2¢ © 13:39, 5 June 2012 (UTC)
• Left alone with the sole exception being indefs for specific abuse of the right granted and confirmed at AN/I or ArbCom. I have seen indef lasting only a day or so - and thus this position. Collect (talk) 13:53, 5 June 2012 (UTC)
• Re-evaluate on a case-by-case basis: A block is made for a breach of normative behavior. Permissions should be re-evaluated at time of block. Toddst1 (talk) 13:55, 5 June 2012 (UTC)
• Leave under admin discretion (aka, "per Toddst"). Blocked users, especially indeffed users, are often blocked because they have violated the community's trust. If they have violated the community's trust, it should be well within the discretion of any administrator to remove advanced permissions. Does this mean that every indeffed or blocked editor should have their rights removed? No, not necessarily; it would be very dependent on the reason behind their block, and it should never become a "race" to pull blocked users' permissions as quickly as possible. But it should not be deprecated to remove permissions from an indeffed user, and I would find it silly in the extreme if people fought to restore permissions to an indeffed user, who can't use them anyway because they're, you know, indeffed. If an admin or admins judged during their block that the user should not have advanced rights, then if their block is lifted some time later there is every reason for the user to re-apply for removed rights at that time, so admins can judge whether the issue that caused them to be removed has been mitigated. A fluffernutter is a sandwich! (talk) 14:08, 5 June 2012 (UTC)
• Left as is; there is no harm in leaving minor userrights (rollback, autopatrolled, etc.) on an indefinitely blocked account if the reasons for blocking were irrelevant to those rights. While it's true they don't need the tools, they are not going to abuse them either, and I see no reason for someone to "re-earn" them if they were trusted with them before and their block had nothing to do with the flags (really, is anyone going to forget how to recognize vandalism?). It goes without saying, however, that this does not apply to admin rights or anything higher, and in most cases where an admin is indefinitely blocked they normally have lost/will lose the flag. Acalamari 15:13, 5 June 2012 (UTC)

Comment: Rollback is one of those privileges that should almost always be removed from someone blocked for edit-warring - whether the privilege was used during the edit war or not. Toddst1 (talk) 18:53, 5 June 2012 (UTC)

Um...but I didn't mention anything about edit warring in my comment; besides, if a user is blocked indefinitely for being an edit warrior then that would not count as rollback being "irrelevant" to the block (although I think if someone is indefinitely blocked for being an edit warrior they likely wouldn't have rollback at the time of the block, anyway). Acalamari 22:22, 5 June 2012 (UTC)

In those circumstances, then removing rollback, with standard notification, would be warranted without much question. Removing rollback under all indefs, not so much. Dennis Brown - 2¢ © 01:24, 6 June 2012 (UTC)

• Removed An indefinite block means a block, no matter for what purpose it is applied for. Having leave user rights on blocked user rights really does not seem right and affects other user's trust in Wikipedia's community and affects it's outside image as a whole. User:Mifter is saying right It can give the wrong impression of the project if someone were to notice that an infef blocked user holds "a position of trust" in their retention of advanced user rights even while indef blocked. Any indefinite blocked user having any user right whether it be Rollback, Reviewer, Autopatrolled, Account creator, etc. or any other needs to be removed once an account is blocked indefinitely whether or not they were abusively used or not just like an Administrator, Bureaucrat, CheckUser and Oversight are always obviously removed in most cases. These user rights can always be restored within seconds after the user account is unblocked and the reviewing Administrator's are convinced. The said user does not need to go through the same process of requesting those user rights which they had before if they were not removed due to it's misuse. The Wikipedia:Database reports/Blocked users in user groups shows and update the user accounts blocked indefinitely in user groups which gets updated from time to time. This list can help all the admins in finding those users accounts and removing the user rights, as it has a purpose to be there. TheGeneralUser (talk) 20:03, 5 June 2012 (UTC)
• Leave as is indef. can be for any number of reasons, including precautionary concern over matters rapidly resolved. WP:BUREAUCRACY is that-a-way. Rich Farmbrough, 01:20, 6 June 2012 (UTC).
  
• Leave as is An indef is not infrequently a shenanigan by a single power tripping administrator, and need have nothing to do with "losing the trust of the community" --Epipelagic (talk) 01:56, 6 June 2012 (UTC)
• Leave as is unless the editor in question has actually abused the right in the course of getting him/herself blocked, with the exception of edit filter admin. I am not certain, but I believe blocked users may still be able to change the edit filter. It is, however, vanishingly rare that this userright is granted to a non-admin, and such users are generally highly trusted, very competent, technically skilled (and so unlikely to have an account compromise), and very unlikely to wind up with an indef. Seraphimblade ^{Talk to me} 02:18, 6 June 2012 (UTC)
• Remove after three months, with IAR taking care of any exceptions. If an indef block remains after three months, it is highly unlikely that it will be lifted any time soon, and retaining userrights in that case only increases clutter in, say, Special:ListUsers/rollbacker, and gives the wrong impression, per Mifter. T. Canens (talk) 04:57, 6 June 2012 (UTC)
• Leave as is - unless there is specific abuse of the userright. Indefinite is not the same as infinite, the block is there until something changes. Often, for bans or de-facto bans, this might mean loss of community trust and be appropriate, but at the same time, for other cases where the user is indefinitely blocked it is likely to be inappropriate. A quick example is a block under WP:No legal threats, if a user is removed from the community whilst proceeding with legal action they have done nothing that might require the removal of rights. I would put removal into a case by case basis, at admins discretion. Worm^TT(talk) 09:34, 6 June 2012 (UTC)
• Leave as is User rights below admin should only removed, if the indefinite block comes from the misuse of these rights. As I see it, granting users rollback, file mover, account creator, autopatrolled has nothing to do with the community's trust, as they are granted at the discretion of a single admin. Armbrust, B.Ed. ^{WrestleMania XXVIII} _{The Undertaker 20–0} 10:48, 6 June 2012 (UTC)
• Leave as is per Epipelagic. --Anthonyhcole (talk) 12:13, 6 June 2012 (UTC)
• Remove but restore them on a case-by-case basis after the block is lifted. If there is no suspicion that they will be abused restore them else not. Targaryen^{speak or forever remain silent} 23:30, 6 June 2012 (UTC)
• Admin discretion - Though honestly, if we are removing admin tools after a year of inactivity, then I don't see why we shouldn't be removing these tools after a length of time being blocked (or banned for that matter). - jc37 23:46, 16 June 2012 (UTC)
• Evaluate on a case-by-case basis; the default should be to leave as-is, for the various reasons outlined above. Even the most level-headed of us could have something happen which might cause us to "go off on one", just once, and pick up such a block, without whatever weird circumstances caused it necessarily impacting on our trustworthiness or abilities on the whole. Pesky (talk) 06:12, 23 June 2012 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Admins

Can blocked admins unblock themselves? 68.173.113.106 (talk) 00:01, 1 August 2012 (UTC)

Does the software allow it? I don't know. Is it good idea? Unless it's clearly accidental, no, they shouldn't and could easily get their admin privileges removed as a result. Nobody Ent 00:04, 1 August 2012 (UTC)

There is a relatively recent patch to prevent admin actions from blocked users. I'm not certain whether it was deployed on the MWF wikis, however. — Coren ^(talk) 00:13, 1 August 2012 (UTC)

I mean, I see admins on Uncyclopedia (a Wikia website) blocking each other just for fun, for example:

04:34, December 1, 2010 Zombiebaron (talk | contribs) resurrected Zombiebaron (talk | contribs) (SYSTEM ERROR: THIS USER CANNOT BE BANNED)

04:31, December 1, 2010 Under user (talk | contribs) blocked Zombiebaron (talk | contribs) with an expiry time of 3 weeks 4 days 5 hours 6 seconds (*looks through ban log* - dear god, I've never banned Zombiebaron, he must feel so left out! I must rectify this at once.)

13:22, October 28, 2010 Zombiebaron (talk | contribs) resurrected Zombiebaron (talk | contribs) (This user is too cool to be banned)

02:38, October 28, 2010 ChiefjusticeDS (talk | contribs) blocked Zombiebaron (talk | contribs) with an expiry time of 6 months (Criminal attentiveness and irredeemable efficiency)

16:15, September 15, 2010 Zombiebaron (talk | contribs) changed block settings for Zombiebaron (talk | contribs) with an expiry time of 11 seconds (account creation disabled) (I have to unban myself so I can ban you so I hope this does that)

16:09, September 15, 2010 ChiefjusticeDS (talk | contribs) blocked Zombiebaron (talk | contribs) with an expiry time of 666 Years (No I'M THE DEVIL!!)

12:46, December 1, 2008 RAHB (talk | contribs) blocked Zombiebaron (talk | contribs) with an expiry time of 11 minutes, 52 seconds (Being not here)

21:47, May 31, 2008 TheLedBalloon (talk | contribs) blocked Zombiebaron (talk | contribs) with an expiry time of 9000 seconds (Don't do that to TKF!)

20:10, March 31, 2008 Zombiebaron (talk | contribs) resurrected Zombiebaron (talk | contribs) (Oh, here's a Kleenex)

68.173.113.106 (talk) 22:15, 1 August 2012 (UTC)

Not particularly relevant here, as the software supports policy, it doesn't define it. Presumably technical questions can be answered somewhere on the mediawiki website. Nobody Ent 12:03, 2 August 2012 (UTC)

It's my impression that for an admin to unblock himself results in immediate de-adminning. There was a case a year or two ago, I don't remember the name, but it was technically possible then. JohnCD (talk) 20:28, 4 August 2012 (UTC)

The software does allow it - Special:ListGroupRights shows that admins have the unblockself userright. But, as others have said, it is almost never appropriate for an admin to unblock himself. --Philosopher ^{Let us reason together.} 23:42, 4 August 2012 (UTC)

User rights for the Education Program extension

The Education Program extension is going to be [re-]enabled in a few weeks, for use with courses in the United States and Canada in the coming term. After the initial version of the extension was deployed, a number of people rightly brought up the problem of building a Wikimedia Foundation staff role (the ep-staff user right) into the software. (From both a practical and philosophical standpoint, WMF doesn't want to and doesn't plan to have a direct role in the on-wiki aspects of the US and Canada education programs for much longer.) So the question is...

What is a good way to handle user rights for the Education Program extension?

The key purpose of the initial ep-staff right was simply to be the gatekeeper for granting the ep-admin right to the Regional Ambassadors and others who bring new professors and ambassadors into the education program. The rest of the ep-staff rights can be devolved to the ep-admin right. So my suggestion would be to have the ep-admin right controlled by bureaucrats, who can grant it upon request based on whatever the current process is for appointing new Education Program administrators. (Right now, that would simply be the existing Regional Ambassadors who were selected by Education Program staff, as well as the staff themselves. In the future, the selection process will be fully community run.) If that doesn't make sense, what is a good alternative configuration for the new user rights?

Note that these user rights only affect the Education Program extension, and will not have a direct impact outside of the course pages and other features of the extension. The only direct affect that the extension will have for those who aren't using the course pages or participating in the education program will be additional log entries.

We need to figure that out by Friday, 10 August 2012 so that the revised user rights can be included for deployment.--Sage Ross (WMF) (talk) 17:21, 4 August 2012 (UTC)

Draft configuration of Education Program user rights

Education Program administrators organizers

Education Program organizers are the education program participants who manage the use of the Education Program extension. At present, these would be the Regional Ambassadors and the Wikipedia Education Program staff.

Users in the ep-admin ep-organizer usergroup (not to be confused with the local admin group) have full access to the "Education Program" namespace, including removing a reviewer or student from the course, and granting (and removing) user rights for new (or former) instructors and ambassadors. EP admins may bulk-delete course pages. The ep-organizer rights are controlled by bureaucrats, and the ep-organizer usergroup can distribute the rest of the rights for the Education Program extension.

Education Program campus ambassadors

Education Program campus ambassadors is the user right for participating Wikipedia Campus Ambassadors, who guide students face-to-face in courses affiliated with the Wikipedia Education Program. At present, on English Wikipedia this only includes the United States and Canada programs.

Users in the ep-campus-ambassador usergroup may edit course pages and institution pages and may sign up on a course page to be a campus ambassador for a course.

Education Program online ambassadors

Education Program online ambassadors is the user right for participating Wikipedia Online Ambassadors, experienced Wikipedians who are selected by the community to guide students remotely in courses affiliated with the Wikipedia Education Program.

Users in the ep-online-ambassador usergroup may edit course pages and institution pages and may sign up on a course page to be an online ambassador for a course.

Education Program instructors

Education Program instructors are instructors at learning institutions who have affiliated a course they teach with the Wikipedia Education Program.

Users in the ep-instructor usergroup may create and edit course pages and institution pages and may sign up as an instructor for a course. They also may remove a student from a course they instruct.

Discussion

Thoughts? Revisions? The new wave of courses is starting within weeks, so it's important to settle on an initial configuration of user rights by 10 August.--Sage Ross (WMF) (talk) 17:21, 4 August 2012 (UTC)

Prior discussions

• Invitation to test education extension, with no indication it would result in the addition of new namespaces or user rights (note that the link to the testing site at the WMFLabs wiki does not work)
  • A new test wiki deployment with the current revised extension should be available soon, hopefully Monday 6 August. I'm not sure why the old site went down; I haven't even seen the extension in action yet myself.--Sage Ross (WMF) (talk) 20:35, 4 August 2012 (UTC)
  • UPDATE: It's now live with the new version of the extension at test2.wikipedia.org. If anyone would like to try out any or all of the flags to explore the extension, please leave me a talk page message. I'll be setting up some example content tomorrow for people to get a feel for the basics of it.--Sage Ross (WMF) (talk) 00:09, 8 August 2012 (UTC)
• Village Pump (technical) discussion for first unsuccessful application of extension
• Discussion at Bureaucrat Noticeboard that archived without receiving promised Education Program explanation and comments

Other related current discussions

• Discussion on the 'crat noticeboard

General discussion

• I have not seen any explanation of why the WMF has decided to create its own namespaces and user rights system to administer this program and then host it on this project. My first thought is that this belongs on the Outreach wiki in its entirety, with interwiki links where needed to this project. I believe it is a very bad precedent for the WMF to solve its administrative issues by arbitrarily, and without the agreement of the community, creating systems and processes that are entirely outside of the reach of the community on which they are hosted. There has been absolutely nothing from the WMF or the Education Program to demonstrate a need for this process to be hosted here. Wikipedia is not a hosting service, not even for WMF projects. Risker (talk) 04:37, 5 August 2012 (UTC)

I don't think it's a fair characterization of the Education Program as a non-community WMF project at this point. The need for a technical system, integrated with Wikipedia, to keep track of what students are doing and make it easy to set up and document course pages for new courses doing Wikipedia assignments has been obvious to most people who've been involved with the education program — especially the experienced Wikipedians who have either served as ambassadors or otherwise intersected with students at work. The process we're talking about is organizing courses, identifying (to both the students and the community) editors who've volunteered to help them, and tracking what students are doing.

Given the rights structure I proposed above, the technical aspects are clearly not outside the reach of the community. The social aspects still have some legacy elements of direct Wikimedia Foundation involvement, and there have been some hiccups in transitioning to full community control, but the latter — full community control — has always been the plan. (There are now 1.5 Wikimedia staff working directly on English Wikipedia education programs — Jami Mathewson, and me as a half time contractor — down from 7 during the Public Policy Initiative . By this time next year, there will be none.) The pattern I've seen is that when the community gets the technical keys to some aspect of the projects, the social structures for the community to control them soon follow. This would give bureaucrats the technical keys to controlling the new course features, and the community as a whole is (of course) ultimately in control of how they get used. Practically, for the time being, that would mean the status quo of some direct Wikimedia Foundation involvement with running the education program on en-wiki.

I know there have been a fair number of problems, but the basic shape of things so far is that — despite the problems, and a modest amount of tension about the level of direct WMF involvement — the community and the Wikimedia Foundation have been working together on the US and Canada education programs, on the whole in a spirit of collaboration and mutual trust. In part because of that trust (I think), the community hasn't been strongly enough motivated to build a WMF-independent governance system. (We explicitly tried to facilitate building such a system during the later stages of the PPI, but it's hard!) My expectation is that this extension will kick-start that process, and that the community will soon be able to articulate more clearly how it wants to deal systematically with supporting Wikipedia in academic courses.--Sage Ross (WMF) (talk) 11:31, 5 August 2012 (UTC)

Sage, the difficulties that the program is encountering in becoming independent may well be related to community perception of the program. Nobody's bothered to ask the community if it wants a special namespace to manage roughly 5000 new editors a year, only a few of whom are likely to stay around afterward. Nobody's asked the community if it thinks supporting this tiny number of new users is important enough to create a whole new user rights regime. Frankly, nobody's asked the community if it wants to continue with this program at all. (We both know what Diedrik's numbers show - no significant difference in the quality of work between editors in this program and other new editors, and nobody thinks we're retaining the students as editors.) I'm glad to see you back working in this program, because I know you know how to listen to the community. But I think the lack of understanding of the community demonstrated by the WMF — and yes, this is being forced on the community by the WMF, not by the volunteers who work on this program — is just as likely to backfire on the program as it is to provide support to the program. Risker (talk) 14:28, 5 August 2012 (UTC)

My perception could be off-base — I haven't seen any systematic efforts to measure community opinion about the education program — but I think on the whole the community has been and remains pretty supportive of the education program. But, if the ultimate fate of the program is that the community decides it's not worth it and wants to shut it down, then that's what will happen; we shouldn't spin our wheels anxiously avoiding that fate. At this point, I'd estimate the balance of opinion to be somewhere around "let's see if we can work out the problems and make it work better, because if we can then it has a lot of potential". When professors and classes are a good fit for the community — and figuring out how to screen for such has been a key priority of the WMF team since the end of the PPI — I'd say it's been a good experience for all involved: students, professors, Campus and Online Ambassadors, other Wikipedians, and readers.--Sage Ross (WMF) (talk) 15:32, 5 August 2012 (UTC)

I hear what you're saying. At the same time, it still doesn't explain in any way why this one little program needs its own namespace or specially designated user rights. The Military History Wikiproject has been managing equally complex project management systems for years in the regular Wikipedia namespace, and it has a demonstrated positive impact on just about every measurable aspect of project success: lots of edits, high quality work, internal leadership development, outreach and support for new users in their sphere of editing, significant editor retention. This is a classic example of an attempt to use technological solutions to manipulate social outcomes. If the community decides it doesn't want this namespace, is the WMF going to listen? Risker (talk) 16:01, 5 August 2012 (UTC)

If the community clearly decided it didn't want this namespace, then yes, I'm pretty sure WMF would listen and act accordingly. I've not seen much explicit opposition to it, though. Nor do I expect a huge amount... the extension will not have much effect at all beyond participants in the education program, and it will make it easier to follow what's going on, to stop problems before they get out of control, and to generally make it less work to help classes work successfully on Wikipedia.--Sage Ross (WMF) (talk) 16:14, 5 August 2012 (UTC)

The community has never been asked whether or not it wants this extension, this namespace and these user rights. These have all been imposed from outside. Traditionally, the community considers namespace and user rights questions. The last "newly created" user right was Researcher, and that had extensive discussion and noteworthy tweaking before it was accepted. The same for the last newly added namespace, "Book" (and its accompanying talk, which is a separate namespace). The community hasn't been consulted about this until the last 24 hours, except very very peripherally. Risker (talk) 16:53, 5 August 2012 (UTC)

Obviously the initial deployment in June was premature. The discussions preceding and following that deployment didn't get publicized as much as they should have, but here we are now with some time to discuss and tweak this before it gets deployed again (I hope!). Frank Schulenburg asked me to help figure out a satisfactory user rights configuration by Friday, 10 August; that's a short time from now, but not unreasonably so... especially since I think the main problems pointed out the first time around have been dealt with. I take your point that the community, unfortunately, wasn't explicitly asked whether it would be okay to create a new namespace well in advance. It's not too late to make tweaks, though, and if community opinion really is against starting this new namespace, it's not too late to stop it. But again, I haven't seen much indication that this is the case.--Sage Ross (WMF) (talk) 17:28, 5 August 2012 (UTC)

I have questions for both of you. Sageross, could this namespace be put on Outreach instead? Risker, could you explain more why you would prefer this be on Outreach other than saying on principle that Wikipedia isn't a hosting site? Thanks. Pine^✉ 02:47, 6 August 2012 (UTC)

Putting it on Outreach isn't feasible, as I understand it, because the extension relies on data from the same wiki to work. It's purpose is to track students' activity on the wiki where it's installed.--Sage Ross (WMF) (talk) 00:05, 8 August 2012 (UTC)

This doesn't convince me. do the developers think it impossible to design the extension to use cross-wiki data? DGG ( talk ) 04:13, 10 August 2012 (UTC)

It's not that it would be technically impossible, it's just not the way the extension has been designed. It would be a major re-write that isn't feasible within the timeframe (1-2 more months) that we have dedicated developer support from Jeroen De Dauw for working on the extension. It also would negate a lot of the point of the extension, to make it easier for the community to see what classes are doing.--Sage Ross (WMF) (talk) 13:01, 10 August 2012 (UTC)

Namespaces

I jumped in without realizing that the new namespaces issue was also a significant issue. Anyhow, I'll double-check with the developer Jeroen De Dauw, but I think the revised version of the extension would only create one new namespace, "Education Program:".--Sage Ross (WMF) (talk) 20:32, 4 August 2012 (UTC)

Yes, we have one namespace now, currently named "Education Program". Institutions are at "Education Program:Institution name" and courses are at "Education Program:Institution name/Course name". --Jeroen De Dauw (talk) 22:43, 4 August 2012 (UTC)

Good - that was my initial question after reading the above-linked logs. Is this extension already enabled at any other wikis so we can take a quick look at it in action? --Philosopher ^{Let us reason together.} 23:58, 4 August 2012 (UTC)

Not at the moment. It will be up on a test wiki soon.--Sage Ross (WMF) (talk) 00:01, 5 August 2012 (UTC)

If we're going to limit editing to people with the right "ep" flag, you also need to grant editing privileges in this namespace to oversighters at least, and preferably all admins. (Oversighters wouldn't be making many edits, but at times, it is necessary to remove information before you can oversight it.) Courcelles 00:01, 6 August 2012 (UTC)

Thanks. I'll look into where info requiring oversight might be added as soon as there's a live test install of the new version of the extension. I think the talk pages are editing by everyone, while the course pages are structured forms rather than true wiki pages. But I imagine it still might be necessary to remove and oversight info from those.--Sage Ross (WMF) (talk) 18:18, 6 August 2012 (UTC)

Entirely likely, as while if a certain user right is required to edit, the most common "oops" oversight (editing logged out) won't be possible, other ways in which people manage to innocently post things that need oversight will be. Courcelles 06:25, 7 August 2012 (UTC)

Userrights

Is there going to be a usergroup for students? Are "normal" Wikipedians going to be able to view pages and make comments without needing any special userrights or will those abilities be restricted? --Philosopher ^{Let us reason together.} 00:05, 5 August 2012 (UTC)

As I understand it, there is no "student" usergroup. Part of the purpose of the extension is to make it easy for the community to see what classes are doing and keep track of student activity, so I'm pretty sure all pages will be viewable without restriction. Individual accounts get associated as "students" with a particular course, but that's not a usergroup. From the screenshots I've seen of the previous version, I think that the course pages themselves are not actually wiki pages, and they only present structured data such as the students' accounts and the articles they are working on. I believe the associated talk pages behave as normal talk pages, editable by both students and non-students. If Jeroen gets a chance, maybe he can clarify further and correct me if I'm wrong about any of that.--Sage Ross (WMF) (talk) 00:24, 5 August 2012 (UTC)

Is there any way that the ep-admin user group be available to more people on some sort of basis. I know that about half of the RAs are not big editors. If there is an issue that needs to be resolved it would be better for quite a few people to be able to fix it. --Guerillero | My Talk 02:29, 5 August 2012 (UTC)

I think that should happen, yeah. Although it shouldn't be a big deal; as long as there are a few active RAs who can assign the other permissions when it needs to be done, it shouldn't be a problem. I don't think there would be very many urgent issues that only some with ep-admin could handle.--Sage Ross (WMF) (talk) 02:35, 5 August 2012 (UTC)

• Regular userrights are perfectly appropriate, unless that particular student or ambassador happens to pass an RfA, be granted rollback, etc. I am uncertain why there needs to be an extra special group for students. 65.96.75.57 (talk) 02:32, 5 August 2012 (UTC)
  • There isn't a separate usergroup for students, as I explained above. The other usergroups are needed to control the administrative functions of the Education Program extension, such as adding new instructors, ambassadors, students, courses, and so on.--Sage Ross (WMF) (talk) 02:37, 5 August 2012 (UTC)

The IP above is blocked, but I'd like some clarification. What Admin-only functions are you suggesting are needed by anyone else for this project? Dougweller (talk) 10:12, 5 August 2012 (UTC)

It's important not to confuse "ep-admin" (education program administrator) rights with conventional admin functions. The new rights are need for administering the features of the course pages enabled by the new extension: starting new courses, new "institution pages" for participating educational institutions, assigning Campus Ambassadors to courses, and the like. We're not talking about any traditional admin functions.--Sage Ross (WMF) (talk) 11:37, 5 August 2012 (UTC)

I think this will cause ongoing confusion, and you should find a name for this user-right that doesn't include "admin". JohnCD (talk) 12:08, 5 August 2012 (UTC)

I think you're right. Any suggestions? How about "organizer"?--Sage Ross (WMF) (talk) 12:10, 5 August 2012 (UTC)

What about ep-coordinator? Monty₈₄₅ 18:11, 6 August 2012 (UTC)

That does sound better. Thanks!--Sage Ross (WMF) (talk) 18:19, 6 August 2012 (UTC)

Ambassador permissions

Sageross, you wrote, "(Right now, that would simply be the existing Regional Ambassadors who were selected by Education Program staff, as well as the staff themselves. In the future, the selection process will be fully community run.)" How do you know that the selection process will be fully community run? The US-CAN Education Working Group is some distance away from making a lot of decisions, and to the best of my knowledge we haven't begun any discussion of how regional ambassadors will be appointed after the hand-off to the new structure. It's possible that RAs will be appointed by the new structure similar to how WMF appoints them today. Those decisions are yet to be made. Pine^✉ 07:00, 5 August 2012 (UTC)

Whatever the decisions the working group comes to about a new structure for the program, it won't give any independent group authority over how things work on Wikipedia. That is, and has been even since the beginning of the WMF's education programs, ultimately under the control of the community. The community was gracious enough to let WMF try some things out with the Public Policy Initiative and since then. Whatever comes out of the working group will have to be okay with the community too. If it's not, that's a sign that things have gone very wrong. (Note the example of the Pune Pilot, which went badly enough that it wasn't okay with the community.)--Sage Ross (WMF) (talk) 11:51, 5 August 2012 (UTC)

the Ambassadors program was not created by "the community" (which I suppose means all wiki editors) but by Wikimedia, which selected the Ambassadors from its San Francisco office. Wikimedia is now turning the US-Canada program into a new independent entity (to take effect next spring). "The community" is well represented on the planning committee (on which I serve), so I don't see any serious conflicts ahead. (The Pune Pilot fiasco happened in India and involved American misunderstanding of how India works.) Rjensen (talk) 15:41, 5 August 2012 (UTC)

I agree with Rjensen that there has been substantial WMF activity in the education programs that hasn't been directly under the control of the community, with the education namespace implementation being an example. I think a more accurate statement is that the community generally hasn't made make systematic objections to the education programs with the notable exception of the IEP problems. It would be helpful if we had something like the old Steering Committee or my proposed Board of Education to have an institutionalized on-wiki community role in the education programs. In the absence of that, it's still not clear to me how ambassadors are to be appointed after the transition, especially regional ambassadors who currently have their IRL qualifications evaluated by WMF. Pine^✉ 20:30, 5 August 2012 (UTC)

In my opinion the Wikipdia community is poorly organized except in a) dealing with crime and punishment; and b) perhaps handling military history and c) perhaps dealing with libraries and museums. Otherwise it's anarchistic and inattentive to outside forces (like higher education) and initiatives (such as those by Wikimedia. Setting up the US-Canada Education project --has the potential for getting a great deal done. Rjensen (talk) 23:57, 5 August 2012 (UTC)

RJ, I take strong exception to your comment about the enWP organization: There are many people on the enWP, including yourself, and Sage, and a number of others, who are quite aware of the requirements of higher education, and have worked very successfully with them, within the admittedly chaotic nature of the ordinary WP--a way of organization I continue to believe is our greatest strength. The people who have not been aware of the needs have been the people working on this from the Foundation--both in the wildly elaborate and unworkable first plans for what the program could rapidly accomplish, and some particularly unfortunate subprojects which it is hardly necessary to mention here. The parts that have worked well have done so because of the talents and dedication of some of the individual ambassadors and faculty. The structure that we develop for carrying this program further should be indigenous to us, and developed on-wiki. The foundation has a role in developing what the community fails to accomplish, but everything positive in this direction so far has been done by the enWP community. The structure which is being proposed that we should adopt and work with is, like all aspects of the educational program so far except for individual courses, top-heavy and over-administered. Sage says above -- and I rely on what Sage says for most of my discussion here because I know that he does understand the problems, "When professors and classes are a good fit for the community — and figuring out how to screen for such has been a key priority of the WMF team since the end of the PPI " Figuring out how to screen for this has proven to be one of the things the WMF is totally unqualified for. They are inherently as incapable of it as they would be to screen for proper article content.

The reason the community has not made systematic objections is that there has been no discussion open enough to publicly object to. Sage is certainly right that the community supports the concept-- I think the community to the extent it knows the structure, has a feeling somewhere between indifference and contempt for it. It is entirely typical of previous work on this under Foundation auspices that we should be rushed into this sort of major decision. It is absurd to establish user rights for some yet undefined purpose under some yet undefined control.

I see no need for any of the user rights. If the project is on the enWP, I do not see what harm comes from open editing--Sage, is there any indication that course pages and the like have been tampered with? Are we that sure we have the right structure for course and ambassadors that we want to enshrine it? The way for the program to go ahead within enWP, is to go ahead as a workgroup, without special privileges.

RJ assumes the final structure will be an independent organization distinct from the Foundation and the enWP. It's the typical mode of administrative thinking: structure first, people second, and content nowhere. From what I understand Sage to say, he thinks Sage agrees it's still uncertain, but from what he says above , he thinks it should be part of enWP, and hopes the community will accept it. I've heard others suggest it should be under the Chapters, but if he wants to set up an organization, it's his perfect right. If the foundation wants to recognize it in some manner which has yet to be defined, let alone accepted, they have the right to do so. It's our right to keep it separate entirely from enWP, even conceivably to the extent of having it produce material for one of the other wikiprojects. Perhaps we will have alternative programs, and instructors will follow the one that suits their needs. DGG ( talk ) 04:55, 10 August 2012 (UTC)

DGG has a much higher opinion of the links between the community and higher education than I do -- I did mention good links with the library world but there are no links I have ever seen with any dean or VP or department chairman or (almost) any scholarly organization. That's an astonishing gap. The comment that "RJ assumes the final structure will be an independent organization distinct from the Foundation and the enWP" is correct and that is how I read the current consensus of the planning committee and the Foundation. In my opinion based on running 30+ summer workshops since 1968 is that professional training programs are expensive. That means they must be funded, and an organization is necessary for that which is independent of en.Wikipedia (which is not competent to handle money and disdains $) and WMF (which has decided to work outside the US and Canada. The comment "structure first, people second, and content nowhere" is exactly the reverse order of what I have been proposing, but that is the sequence mandated by the WMF. My thinking is that the new US-Canada education organization should (in addition to the curent classroom program) start to partner with WikiProjects, such as the Military History one. I see a major role in helping the active editors making better use of the resources controlled by in higher ed (classes, journals, scholarly conventions).Rjensen (talk) 05:46, 10 August 2012 (UTC)

An update on the next steps

I noted this in the parallel discussion at the Bureaucrats Noticeboard, but the plan and timeline from the opening of this discussion is no longer current. To quote from there, "it looks provisionally like we'll push back the timeline, start a more structured and on-topic RfC to figure out whether the community wants this extension and how to configure the rights for it, and then (hopefully) deploy it with plenty of time to play with it, give feedback, and make improvements that the community wants before using it systematically at the start of the following (January 2013) term." If that's what happens, then the rights configuration will whatever the community wants it to be; my own view is that it should be open enough that it's easy for editors to use it to organize classes whether or not they are participating in the formal ambassador program. Note that the course pages themselves aren't editable wiki pages, except for the description which the instructor can edit. The talk pages are wiki pages, and there no restrictions for editing them. The userrights are for regulating creation and deletion of course pages, and for assigning users to the different roles associated with the course pages (instructor, campus ambassador, online ambassador). (There would need to be at least some limited userrights, especially for restricting the deletion of course pages. Restricting course page creation a little more as well may be a good idea just to make sure instructors come into contact with the community before they get started.)--Sage Ross (WMF) (talk) 14:07, 10 August 2012 (UTC)

I came here from the link at WP:CENT, and it looks now like there is more thought being put into the proposal, rather than a proposal for consideration now. Based upon what I've seen in the past year from student editing projects, I want to suggest that Sage Ross and the others working on the issue consider the following. I've recently seen projects where the students just weren't aware of some pretty basic things about how Wikipedia works (example: thinking that they were supposed to sign their edits to pages, in the way that talk page comments are signed), and the faculty member seemed either unaware or unconcerned about how to guide the students about it. I think that some thought should go into finding better ways to explain to school faculty how to educate students about how to edit, and making those faculty aware that they have a responsibility to orient their students about that. If there is going to be some sort of user permission for those faculty members, I think it might be worthwhile to require some sort of qualification for that permission, including understanding what the faculty member needs to teach the students about how Wikipedia works. I have the impression that a meme is spreading in academia that an easy way to teach a course is to just dump students on Wikipedia, and that's obviously not a good thing, for the students or for Wikipedia. Of course, not every instructor is like that! About two years ago, all the classes on my watchlist were really productive and worthwhile, but I've noticed a trend in the past year towards some careless faculty showing up. --Tryptofish (talk) 16:30, 10 August 2012 (UTC)

Thoughtful suggestions. (And that reminds me, I should take this of CENT now.) I'm hoping that this extension can be a starting point for that: something where a faculty member with a Wikipedia project in mind can easily sign up and try to start dumping students on Wikipedia in a built-in way (as they would otherwise in an ad hoc way), but then there's some point of contact with the community from the very beginning to make sure they are going about it in a responsible way before they get going. For example, I could imagine some process analogous to Articles for Creation where faculty go to have their planned assignments vetted a bit before they are allowed to start a course page, and they could be pointed in the right direction if they have some things they need to learn first or if their plans are simply not appropriate for Wikipedia.

I may also be working in the coming months on a basic on-wiki self-guided training for students on the basics of editing, as a counterpart for students to the training modules we've been building for professors and ambassadors in the Wikipedia Education Program. One for students, in particular, could be useful well beyond just the official Wikipedia Education Program classes.--Sage Ross (WMF) (talk) 16:49, 10 August 2012 (UTC)