Last modified: 2013-03-28 13:26:13 UTC
(I've been approached [1] at Meta by a swwiki bureaucrat who asked me if I could pass his request there [2], so here I am). The sw.wikipedia folks kindly requests you to please disable anonymous users from creating content over there. I think removing 'createpage' and 'createtalk' permissions from the '*' group would do it. The also asked me if they could disable anonymous editting entirely, which I told that I thought it'd not be possible in principle. They have voted for this change. The poll is linked in the URL field of this bug. Thanks in advance. Refs.: [1]: <http://meta.wikimedia.org/w/index.php?title=User_talk:MarcoAurelio&oldid=4776427#Advice_on_change_of_settings_in sw-wikipedia> [2]: <https://sw.wikipedia.org/w/index.php?title=Majadiliano_ya_mtumiaji:Kipala&oldid=833720#Reply_from_Meta>
Disabling anonymous editing is indeed out of the question as it goes against a long-established Foundation principle. Can you ask them if they really want to disable talk page creation cause that's the only way anons can communicate about article problems? I know there's a precedent for eswikibooks, but that's really creepy.
Disabling anonymous editing entirely is absolutely out of the question, disabling createtalk should be out of the question too. While disabling the creation of pages by anonymous users might be a required as useful thing, undesirable as it anyway is, disabling the ability of anonymous users to comment on articles, discuss them and so on is unacceptable imo. We encourage users to use talk page to discuss changes, and we block them if they repeatedly try to shove their changes without engaging in discussion. It is ridiculous to forbid them from engaging in discussions unless somebody has created a talk page too. This also applies to COI issues, where it is desirable that the subject of an article not edit said article directly but comment on inaccuracies on the talk page. I suggest that the createtalk request be rejected and not implemented. It is, I believe, unprecedented, and shows a very distressing attitude towards our valued anonymous contributors. It should also be noted that there are plenty of reasons why you'd want abusive users on IPs and not on accounts.
There is precedent for disabling page creation in the main namespace for anonymous users (the English Wikipedia does this) when it is shown that the volume of bad-faith articles created by anonymous users overwhelms the community's ability to curate them. That is, however, the only restriction. I concur with Snowolf: the createtalk request must be rejected and not implemented. It stands directly in opposition of the values held by the movement.
I'm doing best guess from a quick glance at the logs but it looks to me like there are three active admins, maybe only two on a daily basis, and in the last two weeks 10 articles were deleted from the main namespace that had been created by anonymous users. If this is right, I'd much rather work with the local community to figure out how we can make cleanup of junk pages less painful than turn off page creation for anons. As far as page talk creation, or disabling anon edits completely, we can't go there. Like many hundreds of thousands of other users on these projects, I got my start by an anonymous edit, and that is in huge part what makes these projects successful. Welcoming anonymous contributions is a core Wikimedia principle that would take major discussion at community, board and foundation levels to walk away from.
I am the admin who asked MarcAurelio to bring the request here. MaxSemenik: We had not thought through the aspect of talk pages.I agree that this extent is not desirable. If wikipedia has no technique to differentiate - I think I can speak for the users that we pull back on that aspect. Brandon Harris: You hit the point on "overwhelming"; in our language culture the problem is less "bad faith" but unexperienced casual users who do not think much about (western style) rules and hve bad command of written language; by our scale we have a flood of East Africans who write faulty language (having had all or higher education in English while speaking Swahili slang) or take the shortcut via google-translated when they lack the words to translate themselves (and have no dictionary); we also have lots of google-translated stuff from people who do not know the language at all and just want to spread their pet topic.. Google translate does not work for Swahili, we still have lots and lots of unrevised ugly entries from the google-sponsored sw-wikipedia competition which a naive wellwisher from the foundation agreed on with the google people (some laptops to win..) Ariel T Glenn: We are at the moment not 2 on a daily basis. I myself had been practically out for some months with only few visits. The number of deletes does not reflect what we should have deleted. It is only 2 of us - not daily present- who have this year worked on delete proposals and carried out deletes. At the moment we are too few and not daily present. There is a backlog for the potential of our input. (and we prefer to work forward towards article cration) There is other aspect we discussed in Swahili: many casual visitors do not have own computer but come from internet cafes, thus with always changing IPs. this makes it very difficult communicating with them what we have tried for a long time. Any limitation you can give us will be a great help. Please do not treat us worse than en.wikipedia.
It might be worth pointing out to the reasons and context of what lead enwiki to prevent mainpage creations: https://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/2005-12-05/Page_creation_restrictions especially With the number of articles on the English Wikipedia approaching one million, Vibber commented that creation of new articles "is less of a priority than it was two or three years ago, while tuning up existing articles is quite important."
Who is going to take some action? I retracted on edits only, we talk about disabling page creation in the main namespace for anonymous users. Please help us with this.
You could launch a discussion on meta. to get more community feedback on what is acceptable as edit restriction practices.
Kindly help me with some information about the rules. Who is in charge to take a decision on this matter? Is this the right place or not? Is this a panel or more of an discussion group? With or without competence to decide ? If Meta: where??? With whom?
(In reply to comment #9) > Who is in charge to take a decision on this matter? The local wiki community first. The whole Wikimedia community then. > Is this the right place or not? No, Bugzilla is only for *technical* requests. > Is this a panel or more of an discussion group? With or without competence to decide ? > If Meta: where??? With whom? Open a new entry http://meta.wikimedia.org/wiki/Requests_for_comment I would suggest a broader issue (e.g. "Conditions to restrict anonymous users edition") rather than a sw.wikipedia specific one. Every Wikimedia project member will so be able to comment this issue. When the discussion leads to a consensus, you can compare your proposal to this consensus, and if needed, rediscuss the matter on sw.wikipedia. [ Notes ] (1) Ariel Glenn notes the matter should be discussed with the foundation and with the board. I beg to differ, the Foundation and the Board can make some recommendations, but this kind of issues (the balance between accessibility and protection) is clearly a community one; The Wikipedia principles are a community matter. Even if my opinion isn't shared by some, I would strongly recommend to start to focus on the community one. Even in the case someone thinks other levels have to be implied, a community discussion would still be necessary. (2) You could, in parallel with your meta discussion, and as already suggested, collaborate with technical persons to explain your needs to fight vandalisms and explore other possibilities.
Sorry if I ask again. Why is sw.wikipedia to be subjected to such a lenghty procedure as other wikipedia obviously have not had to undergo this? I quote: >>>>>>> http://meta.wikimedia.org/wiki/Newly_registered_user Moreover, a very small minority of wikis requires autoconfirmed to create new pages: en.wiki, id.wiki, fa.wiki, ta.wiki and es.books as of 2011. <<<<<< We have taken a vote and decision to join them. (i.e. i am not sure if we want "autoconfirmed" - we want registered users so that we can communicate with them) So who is the none who can give this to us ?
So, to summarize, if I well understand, you settle to only restrict the createpage right. This possibility has been commented, and you didn't address the two following comments concerns: (In reply to comment #3) > There is precedent for disabling page creation in the main namespace for > anonymous users (the English Wikipedia does this) when it is shown that the > volume of bad-faith articles created by anonymous users overwhelms the > community's ability to curate them. Brandon Harris seems to answer your question, suggesting they've demonstrated the community weren't able to cope with page creation vandalism. Could you explain what kind of vandalism you would be able to avoid and can't currently manage? (In reply to comment #4) > If this is right, I'd much rather work with the local community to figure out > how we can make cleanup of junk pages less painful than turn off page > creation > for anons. Ariel T. Glenn offers you to work with you on an alternative solution. Could you see if you can collaborate together on this matter? If you wish to bypass these two technical/community objection arguments, it seems to me you then need a broader community approval.
(after edit conflict!) (In reply to comment #10) "...major discussion at community, board and foundation levels " meaning that even were the Wikimedia community to decide for example that we should disable page creation by anons on all projects, that by itself would not be sufficient to get the policy implemented, since we are taking about a core principle of the Wikimedia projects. But by the same token the WMF could not decide by itself to make such a move either. (In reply to comment 5) I don't think ease of communication is a substantial reason to exclude anonymous article creation. I am sympathetic about the workload, but it still seems to me that we should check with the countervandalism unit for small wikis to see if something could be worked out as an alternative. If you want broader input meta is the place for that; here at bugzilla you'll get about 5 sets of eyeballs, not exactly a large sample.
(In reply to comment #12) > This possibility has been commented, and you didn't address the two following > comments concerns: I had replied to #3 / Brandon Harris! (see above #5) > Could you explain what kind of vandalism you would be able to avoid and can't > currently manage? Our Problem is the a) the small number of presently 5 constantly active wikipedians (NOT daily) b) amount of bad quality articles and contributions stemming from faulty language either by East Africans (used to slang) or by foreigners who do a lot of edits without knowing the language. c) edits by local users who do not know, understand or care about formats and rules for relevant content. Our Problem is rarely malevolent entries. d) And we have a considerable backlog from that google competition I mentioned with lots of bad google-translation stuff. We see a chance to go for the anonymous c)people because on the way we had again and again people who came on board for months and years after we had taken the chance to write them notices to their IP. Which we do not do any more because of volume. Please try to imagine that in Esat African environment it is much more difficult becasue so few people have access to own internet so they go by cafes or Uni but always changing IPs. And more change because life is harder and less people with time AND access > (In reply to comment #4) > > If this is right, I'd much rather work with the local community to figure out > > how we can make cleanup of junk pages less painful than turn off page > > creation > > for anons. > > Ariel T. Glenn offers you to work with you on an alternative solution. > Could you see if you can collaborate together on this matter? Sorry I did not answer this. Gladly - he can spend his next weeks with us clearing up and checking and correcting faulty language and formats. > If you wish to bypass these two technical/community objection arguments, it > seems to me you then need a broader community approval. No I do not want to bypass anything! I gladly explain whatever question you have and take your advice. Unless rules have changed i would just like to get the same chance as the people at Farsi, Tamil and Indonesian who may have had similar experiences (I just guess).
My biggest concern with turning off anonymous page creation for sw.wiki is that sw.wiki is still in its infancy. It only has 25,000 articles. At this stage you shouldn't be worried about articles having correct grammar. The main focus should be on getting more information on the wiki. Disallowing anonymous page creation at this early stage would be shooting the project in the foot. I would not support disabling anon page creation for any wiki with less than 100,000 articles.
I'm sorry that this request has not received a clear answer in more than three months... As a volunteer, in my full capacity as Nobody, I assure you that this won't be done: we're not going to further restrict page creation on any project. See <https://meta.wikimedia.org/wiki/Limits_to_configuration_changes> for background and feel free to complain on talk page there. As for sw.wiki, I suggest you to explore the solution that was developed for this sort of problem: https://www.mediawiki.org/wiki/Extension:PageTriage It's used only on en.wiki (because they made a similar request a few months ago), but if you want to get it enabled I'll be happy to help reporting any internationalisation issue etc. so that it can work for you too.
PageTriage as it's constructed now is pretty much impossible to internationalise, although we're working on building a schema that'll let us internationalise workflow-based extensions more easily.
