432:
or an automated tool - then maybe a certain number of experienced
Wikipedians need to sign off on that. The question was raised about how to differentiate a librarian from a bad actor. That's easy enough - someone calls the library and talks to them on the phone, or perhaps meets them in person. A lot of the infrastructure in wiki security presumes that doing things like finding a venue's IP address and posting a request through IRC is easy, but things like documenting in-person relationships and having phone conversations is hard. From an event organizer perspective, it is the other way around. Organizations like wiki user groups can maintain professional relationships with all sorts of organizations can be made to agree to sign off on some responsibility for tools. There are lots of potential compromises for giving out tools with lower barriers, but if I would propose one, it would be something like deWP's
339:
and other policies/guidelines/etc, will only be known by an experienced user. The concern that will be raised is one more of the blind leading the blind, as FastLizard4 has said. This is something which I don't feel is appropriate to discuss here though, in a discussion about user rights and security. If librarians think that they know enough about
Knowledge editing and policies to be able to guide others after only making a single edit, then they have either spent a fair amount of time reading the Knowledge namespace, or are kidding themselves. This is as much the fault of Knowledge for the huge amount of policy we somehow generate as it is the fault of the event organiser for assuming they know much more than they probably do.
1186:
of being popular and a good socializer, but might not edit wiki themselves. This happens at least 50 times a year in the US already. The user right being nominated for deprecation gave "course coordinators" the social privilege of giving these kinds of new editors account creator rights. There have been protests about this in the past where some people said that only experienced Wiki editors should get the rights, even temporarily. I do not have good advice about this! I want these events to happen, I say that I am not aware of any history of security breach, but it is correct to say that the account creator userright carries risks to pass around. What do you think about new users with the right?
278:
event on
Knowledge to have at least some basic experience with Knowledge? Saying that being a wiki editor should not be a requirement of event organizers is almost as absurd to me as saying someone teaching a driver's education course should not be required to possess a driver's license themselves or have actually ever driven a vehicle themselves. In what practical situation can someone who has had zero editing experience with Knowledge be expected to effectively lead an organized Knowledge-related event? I think most people would agree that before introducing others to some thing, the person doing the introducing should have some experience with that thing first. --
414:. In this event, Wikimedia Foundation staff ask people who have never edited Knowledge and who do not have accounts to host events to teach others to edit Knowledge. Please do not misunderstand; this is not unusual, this is the current state of Knowledge outreach, and this is how outreach projects from the WMF and from wiki community groups work. I am not endorsing this outreach strategy and I wish for more conversation, but among all the ways that outreach is done, this is one of the ways and it seems to have comparable efficacy and impact as compared to other strategies to the extent that can be determined when there is hardly data for anything. See at
410:
that whatever the case, this logic does not matter in the current practice. The
Wikimedia Foundation and other major players incentivize new users to host events for other new users. This happens on the scale of hundreds of thousands of dollars of funding. This has happened yearly since at least 2014. For various reasons, it is challenging to track outcomes and challenges with these events. Anecdotally, I can say that current policy with mass account creation is not matching current practice. I do not want anyone hunting events to criticize their management, but one outreach campaign which I think would invite a little scrutiny is
512:
nothing untoward going on and create the accounts. This closes the security gap by making it so that an account creator no longer needs to leave their login session open for anyone to use, and has added real security benefits like making it far more difficult for, say, a compromised single laptop being used for account creations keylogging the passwords of all created accounts (a security edge case definitely, but this is the sort of thing that must be considered and addressed). The virtue of knowing that the requests are being reviewed also helps to discourage nefarious use of the system by any potential unethical attendee.
418:, they recommend "Ask participants to create accounts ahead of time (preferred method), Have an account creator available, Request a temporary exception", which is the standard advice and which also makes no sense whatsoever. None of those three options are viable for the 100-200 English language events booked every year in which a new user tells other new users to do wiki. When the enwp rules say, "do things this way..." it results in an unintentional conspiracy in which many strangers all silently wonder if what they are doing is the right process, and no one speaks up even if there is a very high failure rate.
937:
programs and events. On the wiki community side there are about 10 volunteers on this page advocating for policy, most of whom have never organized an event and who have 0 budget for engaging in this policy process. The wiki community has challenges convening the right conversations about policy or even articulating needs. I am not sure how to promote a discussion which matches the impact that this policy has but I expect that what happens here will direct the near-future flow of millions of dollars for tens of thousands of people on a global scale.
1035:
archives for a few minutes trying to find the past discussion, which involved some very long-term contributors etc, but I'm blowed if I can find it and for some weird reason (perhaps related to bot activity?) the last edited dates on a lot of the archives bear no relation to the date of the thread, eg: I found a thread involving me from 2014 that was timestamped in the search results as 2017 - that makes it much harder to dig stuff out. The discussion was within the last 14 months, and probably much more recent. -
466:
similar efforts: Many (though not all) of these efforts are organized though off-wiki trusted networks; either one member of the extended network has reached out to someone to catalyze an event, or we have worked with the same person more than one year in a row with success. We know their names, locations, and most of the time we know their professional title at the institution they work for. And we have successfully organized year over year with no incidents.
849:
current rules I anticipate that this will bring a trend of easier access to account creator rates and more long-term granting of this right, even among people who are not actively using the tool. There are dozens of people like me, for example, who rarely make accounts, but who present lots of wiki workshops and serve as a backup if things go wrong and other account creators are unable to manage the registration process. Recently there was a review at "
1121:. For this a museum donated images of most of its art and supported Wiki editors in making articles for each one. The standard here was that there had to be some citations. This model for new users making new articles is expanding. This is not the usual kind of outreach, which usually asks people to add more, but it might be surprising to experienced Wikipedians because it starts off new users with an image, some sources, and an infobox.
358:
apply the extra rights bundled with the no ratelimiting. Usage by event organisers (and editnotice editors !!) has been a secondary usage of the rights provided, despite being non-ideal. So far (with the exception of
Xaosflux), everyone (that I've seen) has pushed problems without offering any reasonable suggestions for solutions that improve the current situation, rather than improving slightly in one area and degrading a lot in another.
111:
1375:
that I hear from the security side is that there should be more security sensitivity on the outreach side. Probably the cheapest and easiest path to this is to have a paid staff WMFer on a phone hotline at hand to receive calls to release blocks on events, which is an absolutely bonkers solution to this problem except for being the most practical and feasible solution I can imagine.
343:
above (and which I've started implementing), for event organisers to have a trusted way of creating accounts for attendees, with a small amount of verification from the event organiser (let's say if they're a librarian, email the ACC team from their library email address). If it can be made simple enough then I see no reason this specific case would be blocking any more.
321:
wanting to run an event, not knowing anything about
Knowledge's standard practice, and (let's say) they are granted the right, and the event proceeds as normal. Later that day, another user comes along, says they are a librarian wanting to run an event, is granted the right, and proceeds to create 100 sockpuppet accounts and cause a significant amount of damage.
379:
create the accounts quickly and easily (one button press per account to create is my plan), and also addresses most of the security concerns. The issue will be letting event organisers know this exists, and getting this up and running with an example event - but I presume that we can add this to whatever guiding information is given to event organisers.
1567:
585:, et al are distributed throughout the three floors of the building we work on, and will create accounts as needed with said permissions they have a permanent basis because of their involvement with edu programs and outreach. I hope this clarifies that an 'open terminal' is not something that has not, nor would not ever take place at an A+F event.
557:. We explicitly instruct all of our facilitators to create accounts for people one on one. Typically these events have ~20 people attending and 2 to 5 facilitators so things are very one-on-one. For large events like the one we are running at MoMA next weekend, we have a sign in desk, where one of the lead organizers with account creator status (
565:, and myself) sits and registers people for the event, creates accounts for them on our machines, and directs them to trainings, or thematic editing rooms. At the start of the event all of us will be there handling the rush of people, though by noon we only need one of us with account creator perms there. Many of our WMNYC allies like
853:" about whether I should have account creator userright long term. The soon-to-be-deprecated education module granted this to me; as we are re-writing the rules, I still want to retain long-term access to this userright, and also I want a trend of more people who routinely organize in-person wiki trainings to get access to it.
1110:. The change since about 2014 is that there is more awareness that WMF funding programs provide maybe US$ 2 million/year to encourage this kind of outreach but there is limited tracking on how well outreach works. Regardless of the problems, the WMF will continue to encourage more outreach with funding and staff support.
473:: it is quite easy for someone to create multiple accounts simply by going to a different coffee shop or library; they don't need access to special account creation tools. Furthermore, they would be downright foolish to try to do that through these tools, as these tools/permissions make it possible to
1605:
I was either unaware of or forgot about this note, and have been overriding the blacklist accordingly without those users having any apparent issues. Is anyone aware of any issues with creating accounts that only match newaccountonly entries, or do those only apply where the blacklist entry lacks the
1374:
I get the idea that all of this problem is because of a miscommunication, and actually, convening a few video chats with the right circle of people could resolve this years long, 100+ event problem. Outreach coordinators would do something to increase security but there are no clear rules. The demand
1185:
Under what circumstances can you support someone with 0-25 edits getting account creator rights for 10 days? A trend in wiki outreach has been encouraging librarians, museum staff, and subject matter experts to recruit a community base to host a wiki event. Often the event coordinator has a skill set
1101:
You are right to have concerns. In the past the wiki community has opposed the change I proposed here. I do not have complete data to show you, but I have some. In the United States maybe there are 300 wiki community events and another 400 programs for students in classes. Maybe 5000 new editors sign
1034:
Well, if newly-created accounts then run amok at an edit-a-thon then, yes, I've seen it. Obviously, actually creating an account is a purely administrative/bureaucratic thing and cannot in itself be classed as "rubbish" ... but the immediate result of doing so can be. I've just dug around VPP and ANI
997:
Purely from my own perspective, I'm not wonderfully happy about it because we've had an awful lot of rubbish - including loads of copyvio etc - when events such as Dalit
History Month have happened. They've taken masses of time to find and fix, and that despite supposedly being supposedly overseen by
894:
Account creations may create a global SUL but they're not really global. There may be a username that violates some local policy on some
Knowledge, but if it doesn't for the wiki it's going to be primarily used on, then it's not really the concern of the global community. As a global renamer we are
856:
I acknowledge that these changes can cause a range of social and security challenges. If anyone has anything to say about this, now would be a good time to speak up while paid WMF staff are overseeing the changes. Paid WMF staff set up the old wiki policy and they might be able to make commitments to
848:
Please see that the WMF is deprecating the old education module and with it the userrights which, until the change in this thread, was one of the checks on who gets account creator rights. With this change I am advocating for anyone who is hosting events to be able to get account creator rights. With
431:
The event coordination community can make all sorts of concessions to increase security, but whatever policy happens, there needs to be compromise, discussion, and advance agreement. One concession from the security side might be that if a new user gets an account creation tool - whether a user right
399:
Thanks for everything you said. To keep the conversation focused, I want to especially thank you for confirming that the sample event - a new user librarian who hosts a small wiki event - should be allowed to proceed, and that policy decisions about security should be mindful that this is the sort of
338:
It's also not a security concern that there is no relationship between an event organiser and an experienced user. This is much more one of knowledge - how do you expect a librarian to know what makes an article pass the general notability criteria (or even that it exists and where to find it)? This,
143:
There have been several conversations here lately and in the past. I see two recurring perspectives raised, which I will call "security" and "event organizers". People who are interested depend on the enforcement of a set of rules to ensure that some security goals are met. "Event organizers" wish to
1277:
event. I just don't want them given the right long-term. They should come back to the requests page every time they have an event if they don't have a record of good contributions on
Knowledge. We're happy to help them run events, but we need more checks when we don't have an on-wiki history to know
991:
I thought we had not long since had a discussion about this somewhere, perhaps at the Pump or ANI, and there was huge opposition to the idea that just because someone was running an outreach program then that did not mean they should hold the account creator right. Perhaps my memory is wrong but I'm
882:
To be clear, the WMF does not control the
English Knowledge's policies on this, the enwiki community does. With SUL in place, this does have cross-wiki implications, which could have cross-project impact. (E.g. if an local project account creator creates a bunch of accounts that violate guidelines
592:
for pursuing a technical solution you think might solve this problem. Given UX/UI best practices, I welcome the opportunity for members of our initiative, as well as other similar projects to provide feedback and guidance on use case scenarios and workflows as you develop the UX flow, to ensure that
498:
The issue here is someone being granted the account creator right then leaving their login session open on a publicly accessible computer at the event for anyone to use and create their account; this breaks the very "track every account created by said creator" link you speak of since it means there
250:
Right now, I am advocating for events in libraries. I would like to do that in a way that preserves security. If events in libraries cannot happen by the current rules, then I wish I could understand the security threat, and to the extent of my understanding of that threat I wish to advocate for the
1352:
I wanted to share a discussion about permitting account creation at an event. There is a two-day, higher profile editing event at a college. Maybe 100 people will be there including lots of school faculty. There is an IP block associated with the school. About 5 highly experienced Knowledge editors
465:
for having this discussion. As one of the organizers of Art+Feminism this is a significant hurdle we experience, though we are by no means the only organizers who experience this. May I offer one slightly different perspective about the off-network trust structures that are present in A+F and other
409:
Part of the pushback against allowing 6+ accounts to be created at events is an expectation that anyone who has the power to do this should be an experienced Wikipedian. The rationale is that successful Wiki events are presented by experienced Wikipedians. I am going to sidestep this issue, and say
387:
I hope this helps to clarify the issues at hand here from the other side of the fence so to speak, and how this issue is actually a really challenging one to solve well due to the seemingly mutually exclusive goals of stopping abusive/banned users from creating further accounts, and allowing events
924:
I do not think there is any clarity in where WMF engagement starts and stops. Yes, I confirm, nominally the wiki volunteer community establishes policy and outranks WMF decisions. In practice, the WMF allocates a US$ 100 million / year budget and that money and power comes with influence. It is a
844:
In the past you all commented here about regulating access to account creator rights. My perspective is that the infrastructure here creates a conflict between wiki event organizers, who need to create lots of accounts for new users at in-person events; and wiki security enthusiasts, who need some
523:
As for the vetting mechanism A+F uses for event organizers, that's precisely the kind of thing we're looking for to ensure that we're giving rights to people who can be trusted to not misuse them, and is exactly the kind of system we have in mind for the design of the event account creation system
515:
It is indeed quite easy, as you point out for someone to create multiple accounts simply by going to a different coffee shop or library - that's why many of those same end up getting IP blocks placed on them, necessitating assistance when creating an account in many cases and is one of the reasons
357:
No, it's not working. This is evidenced by this discussion, and many discussions in the past. This right, and the ACC tool, have never been intended for use by event organisers - the right was added for the ACC tool originally, and intended to be used by experienced users with knowledge of when to
312:
Firstly, let me clarify that your "security" perspective is for the most part inaccurately represented (in my opinion) by your wording here. Those of us concerned about security are not interested in enforcing a set of rules as much as we are interested in attempting to prevent known abusive users
1651:
only apply the restriction to new accounts (meaning that only new accounts are not allowed to contain the current entry). I'll review the note and revise if needed. Please let me know if you have any more questions or if I can help clarify anything else. Thanks for letting me know about this! ;-)
1363:
No one is doing anything wrong here. The situation is just that some people do security, and some people do events, and there is no way for effective communication between these interests. The security side cannot articulate a request for the outreach side to fulfill, and the outreach side has no
1245:
I tried out your "request an account" feature. It worked great! I can only see the new user side of this and not the interface for the event organizer to get an alert and approve new accounts, but assuming that the requests immediately go to the organizer then this is a viable system for managing
936:
to happen. The WMF probably right now has a budget allocation of US$ 100-300,000 tied up in the tools for program management and is likely to make 1-2 million dollars of investment in outreach management and grant reporting over the next 5 years, with that amount aside from the actual funding of
424:
regardless of what crazy current practices are in place, if an automated sign in dashboard is developed, and if it is freely granted to event organizers, then all these problems go away. The situation which I would not want is the development of a tool which is more complicated to access than the
369:
This is also wrong, but I understand where this is coming from. It should be, and is, the community as a whole who should be deciding this. Unfortunately, it seems a lot of event organisers don't even know the community exists, and thus aren't able to give their input. This is another way that if
320:
Looking to your sample event, it takes a very naive and innocent view on how things could run. Let's look at it from both a legitimate user and a malicious user perspective.. Our brand new librarian user who wants to run an event asks for these account creator rights. They say they're a librarian
277:
A question I have for you before replying to you more generally: Why do you say that "being a wiki editor should not be a requirement of event organizers"? This seems almost oxymoronic to me, very much "the blind leading the blind". Surely it's reasonable to expect someone organizing an editing
1370:
I am sharing this not as an off case, but as the norm for hosting events. Rarely do any complaints actually escalate to an on-wiki report. More commonly, event coordinators have the event disturbed because of a block and no one ever reports the situation. I am going to make an estimate that this
1067:
I remember that, and was a general opposer as well (to non-experience editors being account creators, especially indefinitely) - but assuming there is actually an edit-a-thon, they can edit without logging in, so have you seen any specific problem that only came across because the editors had an
511:
and I are working on aims to address this directly by making the practice no longer necessary, by providing a place for all attendees of an event to easily request an account be created, from which the authorized account creator(s) for the event can quickly and easily vet to ensure that there is
378:
It should be usable in your sample case, if that librarian registers a tool account and creates an event entry on the tool, then gives us a ping from their official email address so we know it's legit. This is the lowest-yet barrier to entry, and from that point the librarian can use the tool to
342:
The security needs are definitely known and certain, there is no mistake here. As I've mentioned above, the issue is one of implementing the needs versus their side effects, not one of defining them. I think that if we can provide a way, such as the extention to the ACC tool proposed by Xaosflux
316:
The methods we have of combatting this abuse themselves fall along a trade-off between really effective at combatting the abuse while really intrusive to legitimate users, all the way down to being transparent and non-intrusive while also being completely ineffective. We, as the entire Wikimedia
1113:
You asked about the benefit of anyone having an account made for them - the benefit is so that the event organizers can track them for reporting to sponsors and also so that the wiki community and WMF get research data about who has the most effective outreach and training. Most programs in the
1079:
No, except for what I consider to be a fact: that AGF or no AGF, people tend to trust named accounts rather more than anons and so things slip through. Turning this on its head: what benefit is there to them having a named account created for them? I'm not familiar with the ins and outs of the
928:
Yes, I agree, I would very much like for account creation to be bundled with the P&E dashboard. There would be many obvious benefits of that, including being able to identify which new user registered in association with which event, and creating a communication channel and chain of
180:
The first six attendees at the event will be able to register Knowledge accounts. All attendees after that will be unable to register. Attendees who come to edit Knowledge but find themselves unable to register an account. The event will be sad because some attendees cannot participate
157:
A librarian is interested in presenting a Knowledge event. This person has edited Knowledge 1 time, so while they have an account, they are a new user, and in the current system cannot make a successful bid for account creator rights. Still, they hear of an outreach program, like
1371:
repeating conflict causes ~US$ 200,000+ / year to evaporate or at least lose impact, give negative experiences, lose a recurring partnership, etc. Much of this money is donations to the WMF which goes in the form of grants and even WMF staff outreach and then gets smashed.
370:
event organisers were more involved in the community, things would be better all-round. As a community, we should be taking this into account, but the balancing act I mentioned above is a very hard one to get a good answer to, and probably impossible to get correct.
1301:
Okay, thanks for that. There has been some ambiguity in the past and I would like to firm up the practice of routinely giving new users account creator rights when they can verify that they are hosting an event in any of the usual ways. What you describe works.
883:
on other projects -and- then the accounts are used on those projects). I think where WMF can be of great use would be in getting account creation bundled in to the PEM Dashboard, having the event dashboard do the creations (completing avoiding IP throttles). —
723:
I updated the link to the archived discussion. Also, I do not remember what I was thinking when I posted this, but obviously paid WMF staff were highly engaged in the establishment of this wiki community policy. I hardly understand what was requested here.
400:
activity that should be expected. We could set baseline expectations anywhere, but as start to discussion, I think that expecting this sort of event to happen is a good starting explanation. Previously, some policies have discouraged these kinds of events.
593:
the end result is something that will work in the environment in which it is deployed. We are working actively with the Dashboard team, and have already provided feedback they have integrated into the product prior to its beta rollout for AF 2017.
170:
and they wish to give it a try. They advertise an event expecting about 15 attendees. The intent is that at the event, over a two-hour period, attendees will register a Knowledge account and add a sentence and citation to a Knowledge article.
1080:
outreach programs, except in so far as they seem to cause a lot of problems. Of course, perhaps it is only that they appear to cause problems because when they are running ok there is rarely a mention of them, so perception is biassed. -
210:
Security needs are uncertain and not defined. There is respect for security, but it is not easy to understand why a professional event coordinator working for a library should be restricted from making wiki accounts. Surely this is some
147:
I wish to present an example situation which describes the typical sort of event in wiki outreach. I wish that there could be some kind of middleground or mutual understanding between the security side and event organizer side.
1278:
they're trustworthy. (To be clear, I'm not saying anything about the value these editors add to the project; conducting in-person events is incredibly impactful. It's just harder to judge trust/competence in these cases.) ~
1382:. I have no good ideas regarding the technical side of this, but I know how outreach works and I see regular disturbance of highly funded outreach! This is a financial and reputation liability for the WMF and all partners!
711:
It's community driven. ACTTRIAL is supported by some foundation resources, but is not driven by them, nor are how we define who may grant this flag. This is however a useful RfC for people watching this page. —
1223:. There is now a request an account button, I think it is still using the address of the user clicking it though - I saw WikiEdu recently got a permanent exemption for their dashboard (dashboard.wikiedu.org) in
361:
Not off-topic per se, but anything that lowers the current levels security should be well-thought and considered given the extra workload and likely extra damage it will give. Solutions that lower the security
766:
that the rule be to routinely grant account creator userrights to anyone engaged in a Knowledge outreach program. This would change the text about granting the userright to anyone engaged specifically in the
805:
I'm in general support of letting people that regularly run events to hold on to account creator access. I don't think we need to be too formal about it either. The way I see it is, put in a request at
204:
There is no great risk for a librarian to organize an event for 15 people in a library. "Account creator" rights, or some way for event organizers to provide accounts to new users, should be easy to get.
1158:
editors having this right long-term. I'm not fine with outreach folk who do not have on-wiki experience being granted this long-term. As long as such a distinction is drawn, I support this change. ~
1492:
Natural cleanup. There are only a few admins who regularly patrol that PERM page, and they are all semi-reasonable people. ;) No need for an RfC for basic stuff, especially if no objections here.
439:
Thanks for anything you can do. I think we understand each other, and I really appreciate that you have enough insight and ability to outline what would need to be done to address this challenge.
1432:
With the pending creation of the event coordinator user right, do we want to update this page to shift individuals who are currently granted account creator to request that right? It will have
317:
community, have the ability to customise how intrusive and effective we want the anti-abuse measures to be, and at the moment I feel they are striking a decent balance between the two extremes.
1102:
up and actually edit through outreach in a year in the US, but I do not have good data. Any kind of event - whether community event or class program - gets tracked in something called the "
1379:
335:
or other event organiser the ability to bypass the account creation ratelimit, and I doubt anyone would if we knew it was the event organiser and not an imposter (yes, this has happened).
191:
There is some reasonable method endorsed by event organizers which allows the librarian to provide accounts to their guests. Everyone present at this event is able to register an account.
313:
from continuing to abuse. Sockpuppetry is a real problem on Knowledge, and some sockpuppets and sockmasters can go undetected for a long time, causing all sorts of long-lasting damage.
1575:
233:
It is okay for the level of wiki-security to be decided without input from event organizers. The event organizers can find a way to both have their event and follow the rules.
1478:
I'm happy to remove the outreach provisions and turn this into a mainly ACC-only thing. Do we need additional community consensus around this, or is it just natural cleanup?
1353:
who also have organized 100+ in-person events are trying to anticipate for account creation and remove the school's IP block. There is no obvious path for us to do this. See
810:- if you find you are coming back regularly ask for it to not expire - if you don't use it for a year or so then someone will probably remove it. General comments anyone? —
1215:
shows that most anyone asking for this access related to events has been getting it without much issue (and almost all of the denies are either obvious denial reasons or
102:
246:
If someone feels that the example event in the library should not be allowed to happen as described above, could someone speak up and say so to advance the conversation?
39:
436:, where an offline relationship goes through some kind of multi-user confirmation process in order to have greater access to specialized tools for special situations.
503:
granted the Account Creator permission is actually the person who pressed the button to create the account. The new Editathon/Events augmentation to the existing
1050:
648:
207:
There is no particular relationship between being an event organizer and being a wiki editor. Being a wiki editor should not be a requirement of event organizers.
1053:. It is actually about a slightly different issue but given the concerns raised there regarding who was granted thr AC right, it may still bear noting. -
1212:
74:
786:
to support this policy change because that user is facilitating some changes to the policy about the education userrights which this policy references.
1332:: Could the proposer or anyone else compare and contrast the proposal to the current way of doing things? Is gaining ACC a burdensome process now? ☆
1402:
850:
98:
1367:
The block is inexplicable - maybe something happened at the school years ago, but getting any explanation of why the block exists is not possible.
895:
mostly concerned if the requested username violates the home wiki's username policy. We also of course use common sense when evaluating requests.—
778:
The archives of this talk page have records of discussion about all the challenges associated with granting this user right for events. I asked
144:
host Wiki outreach events, and encounter the barrier that any event which registers more than 6 new users will be stopped by security measures.
415:
243:
If someone is putting time into a solution to develop account creator tools, please confirm that tool offerings will apply in the above example
1114:
United States work fine but here also there are a lot of highly trained wiki outreach people providing support. For other places I cannot say.
80:
1118:
403:
The conversation could continue in lots of directions but I wish to briefly address only a few points, then if useful, more could be said.
1625:
1559:
1451:
I'd think so, in general if they are here because they are "coordinating an event" they should go to a new EC intake instead of AC. —
1219:). Also, on follow up to PEM improvements - I think the request an account process is working a lot better now. See my example event
537:
291:
1594:
Note 2 to this page is currently written such that it seems to apply to all title blacklist entries. However, basically all of the
331:
You are correct that a librarian organising an event for 15 people is low risk, and I personally don't have a problem granting a
221:
Anyone without an established relationship to wiki projects is too much of a security liability to have "account creator" rights.
759:
755:
992:
pretty sure it is not. The problem is, I cannot remember the details. Maybe advertise this in some more well-trafficked forum?
1107:
20:
227:
The current system is working. People who want to host events manage to get account creator rights to to the right people.
69:
845:
standard of quality control which is not currently defined and which frequently is counter to the needs of doing events.
1103:
933:
772:
1533:
1426:
768:
555:
Let me offer a further clarification that an open terminal is something that never happens at A+F or other such events
167:
60:
1220:
110:
93:
1602:, meaning that account creation requires the tboverride right, but page creation should be completely unaffected.
1139:
Yes, that old discussion is relevant because during wiki events often the goal is for people to make new articles.
163:
24:
121:
771:, which starting from about 2014 has transformed into all the activities which anyone can now track with the
1483:
976:
905:
598:
482:
1621:
1547:
1497:
1467:
1441:
1415:
1390:
1310:
1254:
1194:
1129:
945:
865:
794:
732:
701:
660:
618:
447:
259:
433:
1246:
events. You have demonstrated that you understand the challenge to address and yes, this is a solution.
533:
287:
1117:
To see an example of the simplest kind of new article that a new user might make at an event check out
1571:
1578:
until a consensus is reached, and readers of this page are welcome to contribute to the discussion.
857:
smooth over aspects of the transition if anyone had any development requests. Thoughts from anyone?
562:
50:
1479:
1357:
1268:
967:
896:
839:
807:
594:
493:
478:
126:
65:
1636:
1617:
1540:
1493:
1463:
1437:
1408:
1383:
1303:
1247:
1206:
1187:
1122:
938:
877:
858:
835:
787:
725:
694:
673:
653:
611:
589:
570:
508:
469:
I also want to ask whether the discussion of the potential for sockpuppetry from this process
462:
458:
440:
396:
305:
272:
252:
46:
1085:
1058:
1040:
1003:
831:
607:
548:
525:
279:
123:
1579:
558:
1378:
Alternatively, maybe there could be some miracle solution to this incorporated into the
425:
current paths for mass account creation. The tool has to have totally new users in mind.
1598:
requests I see requesting override of the blacklist match only an entry that is marked
582:
1660:
1629:
1584:
1552:
1521:
1501:
1487:
1471:
1457:
1445:
1420:
1395:
1341:
1315:
1289:
1259:
1233:
1199:
1169:
1134:
1089:
1074:
1062:
1044:
1029:
1007:
983:
950:
912:
889:
870:
816:
799:
737:
718:
706:
688:
665:
649:
Allow users in the Account Creator user group to add users to the Confirmed user group
623:
602:
541:
486:
452:
391:
295:
264:
230:
Anything that lowers the current level of security should be off-topic for discussion.
224:
It is risky for there to be an event without experienced Wiki people closely involved.
1595:
1511:
1452:
1337:
1296:
1279:
1240:
1228:
1180:
1159:
1069:
1024:
919:
884:
827:
811:
781:
713:
683:
682:, but by community volunteers. Please let me know if I'm missing something there. —
517:
504:
159:
125:
823:
578:
574:
1436:, but without the ability to override the blacklist or the anti-spoof mechanisms.
1224:
351:
As the account creator group currently exists and is used, yes, I agree with this.
925:
statement of fact that WMF staff are a major drivers in developing ENWP policies.
1653:
1612:
1096:
1081:
1054:
1036:
1014:
999:
566:
325:
in such a way before they're given the permissions needed to do a lot of damage?
388:
such the library to create accounts for all their participants without issues.
1403:
Wikipedia_talk:How_to_run_an_edit-a-thon#Blocked_editing_at_high_profile_event
553:
Ah! Thank you for that clarification re: the fear of an open login terminal.
411:
520:
project, and thus the Account Creator user right, exists in the first place.
1462:
My thoughts as well, but I did want to raise it before making any changes.
1639:! As far as I know, the option to override the title blacklist applies to
1333:
647:
The Wikimedia Foundation is proposing policy change at this discussion -
1566:
1019:
new accounts can't really do much more then IP editors - has any of the
328:
Let me also go through your points about what you assume people think:
1358:
User_talk:Graham87#Please_allow_my_students_to_register_their_accounts
1023:
you've seen been related to the actual creating of accounts though? —
1576:
Knowledge:Redirects for discussion/Log/2021 April 14#Account creators
477:
thus it would leave their digital fingerprints all over their socks.
1211:
I think you are worrying a bit more than needed, a recent review of
929:
responsibility between any given program and the team organizing it.
153:
Sample event - meetup in the community center of a public library
127:
15:
199:
Event organizations think, but security enthusiasts doubt...'
678:
this does not appear to be a policy change being requested
366:
having a plan to deal with this are not complete solutions.
1273:
I'm always fine with such editors getting the right for a
375:
With regards to the extension to the tool I'm working on:
216:
Security enthusiasts think, but event organizers doubt...'
1380:
Knowledge:Requests for comment/Event coordinator proposal
1364:
path to make an event safe enough to remove an IP block.
610:
Thanks for the feedback and setting clear expectations.
763:
756:
NOTICE:_EducationProgram_extension_is_being_deprecated
750:
Propose change to give access to anyone doing outreach
1570:
A discussion is taking place to address the redirect
1433:
1348:
Typical problem case - IP block at school for event
251:rules to change to permit these sorts of events.
1217:come back when your event is going to take place
1227:- perhaps it can be replicated by outreach? —
416:meta:The_Wikipedia_Library/1Lib1Ref/Coffee_Kit
8:
932:I want the development you describe for the
354:As mentioned, not a security concern at all.
475:track every account created by said creator
1213:Knowledge:Requests_for_permissions/Archive
1643:that are saved to the blacklist. Entries
348:...and from the security perspective...
851:Can bluerasberry be an account creator?
1020:
693:Perhaps I am mistaken. I am not sure.
323:How do you tell these two users apart
7:
1119:Quail and Millet (Kiyohara Yukinobu)
1108:like for this physical therapy class
382:It's more than welcome to go ahead.
176:Under the present security practice
23:for discussing improvements to the
1104:meta:Programs and Events Dashboard
934:meta:Programs and Events Dashboard
773:meta:Programs and events dashboard
499:is no longer a guarantee that the
14:
1565:
109:
40:Click here to start a new topic.
1574:. The discussion will occur at
760:Knowledge:Education_noticeboard
1539:Thanks TonyBallioni + others.
1:
1558:"Account creators" listed at
1106:" and would produce a report
37:Put new text under old text.
588:Additionally, thank you and
453:15:00, 30 January 2017 (UTC)
392:13:40, 18 January 2017 (UTC)
296:11:48, 18 January 2017 (UTC)
265:23:29, 17 January 2017 (UTC)
187:What event organizers desire
1661:01:03, 14 August 2024 (UTC)
1534:Knowledge:Event coordinator
1427:Knowledge:Event coordinator
998:experienced Wikipedians. -
769:Knowledge:Education program
434:meta:Personal acquaintances
45:New to Knowledge? Welcome!
1677:
1645:within the title blacklist
1630:00:47, 4 August 2024 (UTC)
1616:as writer of this note. —
1606:newaccountonly attribute?
1585:16:55, 14 April 2021 (UTC)
1421:18:12, 20 April 2018 (UTC)
1396:17:33, 20 April 2018 (UTC)
1342:19:58, 20 April 2018 (UTC)
1316:14:28, 19 March 2018 (UTC)
1290:14:17, 13 March 2018 (UTC)
1260:14:28, 19 March 2018 (UTC)
1234:14:16, 13 March 2018 (UTC)
1200:13:36, 13 March 2018 (UTC)
1170:01:18, 13 March 2018 (UTC)
1135:13:32, 13 March 2018 (UTC)
1090:00:48, 13 March 2018 (UTC)
1075:00:29, 13 March 2018 (UTC)
1063:00:22, 13 March 2018 (UTC)
1045:00:13, 13 March 2018 (UTC)
1030:00:00, 13 March 2018 (UTC)
1008:23:26, 12 March 2018 (UTC)
984:13:44, 12 March 2018 (UTC)
951:14:33, 12 March 2018 (UTC)
913:14:15, 12 March 2018 (UTC)
890:14:11, 12 March 2018 (UTC)
871:13:35, 12 March 2018 (UTC)
738:13:39, 12 March 2018 (UTC)
719:03:46, 8 August 2017 (UTC)
707:02:57, 8 August 2017 (UTC)
689:02:24, 8 August 2017 (UTC)
666:21:16, 7 August 2017 (UTC)
139:My wish - the example case
817:22:47, 8 March 2018 (UTC)
800:22:14, 8 March 2018 (UTC)
624:16:15, 2 March 2017 (UTC)
603:16:13, 2 March 2017 (UTC)
542:12:32, 2 March 2017 (UTC)
487:19:01, 1 March 2017 (UTC)
164:Knowledge:Year of Science
75:Be welcoming to newcomers
1560:Redirects for discussion
1553:16:35, 14 May 2018 (UTC)
1522:14:15, 12 May 2018 (UTC)
1502:03:19, 12 May 2018 (UTC)
1488:03:04, 12 May 2018 (UTC)
1649:<newaccountonly: -->
1600:<newaccountonly: -->
1472:20:49, 8 May 2018 (UTC)
1458:20:19, 8 May 2018 (UTC)
1446:18:44, 8 May 2018 (UTC)
407:Blind leading the blind
643:proposed policy change
70:avoid personal attacks
1647:that are tagged with
1528:Userright established
524:we're working on. --
103:Auto-archiving period
471:may be a red herring
168:WP:Education program
764:proposing a change
238:My request for now
81:dispute resolution
42:
1519:
1287:
1272:
1167:
680:by the foundation
422:Automated sign in
134:
133:
61:Assume good faith
38:
1668:
1657:
1650:
1615:
1601:
1582:
1572:Account creators
1569:
1550:
1545:
1515:
1455:
1435:
1418:
1413:
1393:
1388:
1313:
1308:
1300:
1283:
1266:
1257:
1252:
1244:
1231:
1210:
1197:
1192:
1184:
1163:
1132:
1127:
1100:
1072:
1027:
1018:
982:
979:
971:
948:
943:
923:
911:
908:
900:
887:
881:
868:
863:
843:
814:
797:
792:
785:
735:
730:
716:
704:
699:
686:
677:
663:
658:
621:
616:
552:
530:
497:
450:
445:
309:
284:
276:
262:
257:
128:
114:
113:
104:
16:
1676:
1675:
1671:
1670:
1669:
1667:
1666:
1665:
1655:
1648:
1610:
1599:
1592:
1580:
1563:
1548:
1541:
1530:
1518:
1453:
1430:
1416:
1409:
1401:similar case -
1391:
1384:
1350:
1311:
1304:
1294:
1286:
1255:
1248:
1238:
1229:
1204:
1195:
1188:
1178:
1166:
1130:
1123:
1094:
1070:
1025:
1012:
977:
974:
969:
946:
939:
917:
906:
903:
898:
885:
875:
866:
859:
821:
812:
795:
788:
779:
754:In response to
752:
733:
726:
714:
702:
695:
684:
671:
661:
654:
645:
619:
612:
546:
526:
491:
448:
441:
303:
280:
270:
260:
253:
141:
130:
129:
124:
101:
87:
86:
56:
25:Account creator
12:
11:
5:
1674:
1672:
1664:
1663:
1591:
1588:
1562:
1556:
1543:Blue Rasberry
1537:
1536:
1529:
1526:
1525:
1524:
1516:
1507:
1506:
1505:
1504:
1476:
1475:
1474:
1429:
1424:
1411:Blue Rasberry
1406:
1405:
1386:Blue Rasberry
1361:
1360:
1349:
1346:
1345:
1344:
1325:
1324:
1323:
1322:
1321:
1320:
1319:
1318:
1306:Blue Rasberry
1284:
1264:
1263:
1262:
1250:Blue Rasberry
1190:Blue Rasberry
1173:
1172:
1164:
1154:I'm fine with
1151:
1150:
1149:
1148:
1147:
1146:
1145:
1144:
1143:
1142:
1141:
1140:
1137:
1125:Blue Rasberry
1115:
1111:
1047:
994:
993:
986:
960:
959:
958:
957:
956:
955:
954:
953:
941:Blue Rasberry
930:
926:
915:
861:Blue Rasberry
854:
846:
790:Blue Rasberry
751:
748:
747:
746:
745:
744:
743:
742:
741:
740:
728:Blue Rasberry
697:Blue Rasberry
656:Blue Rasberry
644:
638:
637:
636:
635:
634:
633:
632:
631:
630:
629:
628:
627:
626:
614:Blue Rasberry
586:
563:Failedprojects
521:
513:
467:
443:Blue Rasberry
437:
426:
419:
404:
401:
385:
384:
383:
380:
373:
372:
371:
367:
359:
355:
352:
346:
345:
344:
340:
336:
326:
318:
314:
310:
299:
298:
255:Blue Rasberry
248:
247:
244:
240:
239:
235:
234:
231:
228:
225:
222:
213:
212:
208:
205:
196:
195:
194:
193:
192:
184:
183:
182:
155:
154:
150:
140:
137:
132:
131:
122:
120:
119:
116:
115:
89:
88:
85:
84:
77:
72:
63:
57:
55:
54:
43:
34:
33:
30:
29:
28:
13:
10:
9:
6:
4:
3:
2:
1673:
1662:
1659:
1658:
1646:
1642:
1638:
1634:
1633:
1632:
1631:
1627:
1623:
1619:
1614:
1607:
1603:
1597:
1589:
1587:
1586:
1583:
1577:
1573:
1568:
1561:
1557:
1555:
1554:
1551:
1546:
1544:
1535:
1532:
1531:
1527:
1523:
1520:
1514:
1509:
1508:
1503:
1499:
1495:
1491:
1490:
1489:
1485:
1481:
1480:TheDragonFire
1477:
1473:
1469:
1465:
1461:
1460:
1459:
1456:
1450:
1449:
1448:
1447:
1443:
1439:
1434:(noratelimit)
1428:
1425:
1423:
1422:
1419:
1414:
1412:
1404:
1400:
1399:
1398:
1397:
1394:
1389:
1387:
1381:
1376:
1372:
1368:
1365:
1359:
1356:
1355:
1354:
1347:
1343:
1339:
1335:
1331:
1327:
1326:
1317:
1314:
1309:
1307:
1298:
1293:
1292:
1291:
1288:
1282:
1276:
1270:
1269:edit conflict
1265:
1261:
1258:
1253:
1251:
1242:
1237:
1236:
1235:
1232:
1226:
1222:
1218:
1214:
1208:
1203:
1202:
1201:
1198:
1193:
1191:
1182:
1177:
1176:
1175:
1174:
1171:
1168:
1162:
1157:
1153:
1152:
1138:
1136:
1133:
1128:
1126:
1120:
1116:
1112:
1109:
1105:
1098:
1093:
1092:
1091:
1087:
1083:
1078:
1077:
1076:
1073:
1066:
1065:
1064:
1060:
1056:
1052:
1048:
1046:
1042:
1038:
1033:
1032:
1031:
1028:
1022:
1016:
1011:
1010:
1009:
1005:
1001:
996:
995:
990:
987:
985:
980:
973:
972:
965:
962:
961:
952:
949:
944:
942:
935:
931:
927:
921:
916:
914:
909:
902:
901:
893:
892:
891:
888:
879:
874:
873:
872:
869:
864:
862:
855:
852:
847:
841:
840:Cyberpower678
837:
833:
829:
825:
820:
819:
818:
815:
809:
804:
803:
802:
801:
798:
793:
791:
783:
776:
774:
770:
765:
761:
757:
749:
739:
736:
731:
729:
722:
721:
720:
717:
710:
709:
708:
705:
700:
698:
692:
691:
690:
687:
681:
675:
670:
669:
668:
667:
664:
659:
657:
651:
650:
642:
639:
625:
622:
617:
615:
609:
606:
605:
604:
600:
596:
595:Theredproject
591:
587:
584:
580:
576:
572:
568:
564:
560:
556:
550:
545:
544:
543:
539:
535:
531:
529:
522:
519:
514:
510:
506:
502:
495:
494:Theredproject
490:
489:
488:
484:
480:
479:Theredproject
476:
472:
468:
464:
460:
456:
455:
454:
451:
446:
444:
438:
435:
430:
427:
423:
420:
417:
413:
412:meta:1lib1ref
408:
405:
402:
398:
395:
394:
393:
390:
386:
381:
377:
376:
374:
368:
365:
360:
356:
353:
350:
349:
347:
341:
337:
334:
330:
329:
327:
324:
319:
315:
311:
307:
301:
300:
297:
293:
289:
285:
283:
274:
269:
268:
267:
266:
263:
258:
256:
245:
242:
241:
237:
236:
232:
229:
226:
223:
220:
219:
218:
217:
209:
206:
203:
202:
201:
200:
190:
189:
188:
185:
179:
178:
177:
174:
173:
172:
169:
165:
161:
152:
151:
149:
145:
138:
136:
118:
117:
112:
108:
100:
97:
95:
91:
90:
82:
78:
76:
73:
71:
67:
64:
62:
59:
58:
52:
48:
47:Learn to edit
44:
41:
36:
35:
32:
31:
26:
22:
18:
17:
1654:
1644:
1640:
1637:Mdaniels5757
1618:Mdaniels5757
1608:
1604:
1593:
1564:
1542:
1538:
1512:
1494:TonyBallioni
1464:TonyBallioni
1438:TonyBallioni
1431:
1410:
1407:
1385:
1377:
1373:
1369:
1366:
1362:
1351:
1329:
1305:
1280:
1274:
1249:
1225:phab:T126541
1216:
1207:Bluerasberry
1189:
1160:
1155:
1124:
988:
968:
963:
940:
897:
878:Bluerasberry
860:
836:Stwalkerster
789:
777:
753:
727:
696:
679:
674:Bluerasberry
655:
652:
646:
640:
613:
590:stwalkerster
571:Bluerasberry
554:
527:
509:stwalkerster
500:
474:
470:
463:Bluerasberry
459:Stwalkerster
442:
428:
421:
406:
397:Stwalkerster
389:
363:
332:
322:
306:Bluerasberry
281:
273:Bluerasberry
254:
249:
215:
214:
198:
197:
186:
175:
160:Art+Feminism
156:
146:
142:
135:
106:
92:
19:This is the
1641:all entries
1581:TAXIDICAE💰
1068:account? —
832:FastLizard4
808:WP:PERM/ACC
608:FastLizard4
549:FastLizard4
528:FastLizard4
282:FastLizard4
1275:verifiable
970:CYBERPOWER
899:CYBERPOWER
559:Siankevans
501:individual
457:Thank you
1510:Agree. ~
1049:Found it
1021:"rubbish"
966:Why not?—
583:Doctorxgc
333:librarian
83:if needed
66:Be polite
21:talk page
1656:~Oshwah~
1626:contribs
1454:xaosflux
1297:BU Rob13
1241:Xaosflux
1230:xaosflux
1181:BU Rob13
1071:xaosflux
1026:xaosflux
920:Xaosflux
886:xaosflux
828:BU Rob13
813:xaosflux
782:Xaosflux
715:xaosflux
685:xaosflux
538:contribs
516:why the
292:contribs
211:mistake.
181:on-wiki.
94:Archives
51:get help
1330:Comment
1156:trusted
989:Comment
838:, and
824:Mlpearc
579:Mozucat
575:Aliceba
507:system
429:Vetting
364:without
166:or the
107:31 days
1613:Oshwah
1590:Note 2
1549:(talk)
1417:(talk)
1392:(talk)
1312:(talk)
1256:(talk)
1196:(talk)
1131:(talk)
1097:Sitush
1082:Sitush
1055:Sitush
1037:Sitush
1015:Sitush
1000:Sitush
947:(talk)
867:(talk)
796:(talk)
734:(talk)
703:(talk)
662:(talk)
620:(talk)
567:Pharos
449:(talk)
261:(talk)
762:I am
79:Seek
27:page.
1622:talk
1609:Cc.
1498:talk
1484:talk
1468:talk
1442:talk
1338:talk
1221:here
1086:talk
1059:talk
1051:here
1041:talk
1004:talk
978:Chat
964:Sure
907:Chat
599:talk
534:talk
483:talk
461:and
302:Hey
288:talk
68:and
1635:Hi
1596:ACC
1513:Rob
1334:Bri
1281:Rob
1161:Rob
758:at
641:WMF
518:ACC
505:ACC
162:or
1628:)
1624:•
1517:13
1500:)
1486:)
1470:)
1444:)
1340:)
1285:13
1165:13
1088:)
1061:)
1043:)
1006:)
834:,
830:,
826:,
775:.
601:)
581:,
577:,
573:,
569:,
561:,
540:)
485:)
294:)
105::
49:;
1620:(
1611:@
1496:(
1482:(
1466:(
1440:(
1336:(
1328:'
1299::
1295:@
1271:)
1267:(
1243::
1239:@
1209::
1205:@
1183::
1179:@
1099::
1095:@
1084:(
1057:(
1039:(
1017::
1013:@
1002:(
981:)
975:(
922::
918:@
910:)
904:(
880::
876:@
842::
822:@
784::
780:@
676::
672:@
597:(
551::
547:@
536:•
532:(
496::
492:@
481:(
308::
304:@
290:•
286:(
275::
271:@
99:1
96::
53:.
Text is available under the Creative Commons Attribution-ShareAlike License. Additional terms may apply.
