Author: vitomedia
Description:
Hello,
Please move the right "createpage" from All (*) to User at tr.wikipedia. Here is the link to the discussion:
I'd be delighted if this could be taken care of rather swiftly, since we are understaffed as sysops these days.
Version: wmf-deployment
Severity: enhancement
URL: https://tr.wikipedia.org/w/index.php?title=Vikipedi:K%C3%B6y_%C3%A7e%C5%9Fmesi_%28teklifler%29&oldid=12797562#Teklif
The createpage right affects all namespaces, I believe, and if so, disallowing the creation of pages in mainspace is already a fairly extreme measure, but disallowing the creation by non-logged in contributors of talk page and user talk pages is not appropriate imo. It goes against the spirit of the encyclopedia that anybody can edit and against our encouragement that substantial and controversial changes be discussed on talk pages first. Forcing users to create an account so they can edit the talk pages (in the cases where nobody has had a reason to create the talk page before) would be counterproductive and rather unwikimedian.
vitomedia wrote:
Creating talk pages is handled by the "createtalk" right, Snowolf. The request is concerned with the "createpage" right.
vitomedia wrote:
I'd also like to point out to the fact that what we are asking is exactly what en.wiki and fa.wiki already have. In case someone has questions in mind.
Please see:
https://en.wikipedia.org/wiki/Special:ListGroupRights
https://fa.wikipedia.org/wiki/Special:ListGroupRights
Indeed, I had forgotten about createtalk; I wasn't 100% sure which is why I stated "if so" :)
vitomedia wrote:
Folks, could we speed this up by any chance? There is clear consensus, it has precedent, and we really need this at the moment.
This request was filed two workdays ago. Please be patient - handling shell requests depends mostly on volunteers and can take some time.
vitomedia wrote:
Thank you, Andre. Of course, I know all this. I appreciate the work you guys do, and the workload that comes with the job.
I'd wait happily and patiently had it been a mundane change. But speeding things up in this isolated case would help things change dramatically at tr.wiki. That's why I'm trying to do something about it. Sorry if I appear to be agog.
We allow that, without a prior demonstration it's impossible to fight vandalisms otherwise?
vitomedia wrote:
Hello Sébastien,
Tr.wiki has always been one of the most vandalized wikis of the WMF, but in times like winter breaks it just goes haywire. A couple of dedicated patrollers are handling the heavy workload at the moment, and only one third of our sysops (including me) can be considered fully active. Our version of CAT:CSD can be populated with a hundred pages in the blink of an eye, and almost all we do is deleting nowadays. In fact I had to delete approximately 800 pages on Sunday (which means I probably reviewed more than a thousand CSD-tagged pages). Effective tools such as Twinkle (which is maintained solely by me, and is not working due to an upgrade from 1.0 to 2.0) fall short.
Let me also tell you this: A major part of my proposal (of which you only see the server-related aspect) is the creation of the Article Wizard and the Articles for Creation process. This way we'll provide much better orientation for newcomers, and not lose their new article contributions. I am working on the pages at the moment, and I'll be done in a day or two.
Therefore I consider this change to be urgent, because we are wasting valuable man-hours. A simple change of code will allow us to save on that. We'll be able to focus on other things, and it will directly reflect on the quality of our project.
eldarionviki wrote:
More than 20 days past since this request, but we still didn't get any solution. Active sysops using their efforts only for deleting hundreds of pages everyday.
Dereckson: I didn't understand your comment 8, could you elaborate / clarify what you'd like to see / which concerns you expressed?
Dereckson: I didn't understand your comment 8, could you elaborate / clarify
what you'd like to see / which concerns you expressed?
vitomedia wrote:
Andre: Why exactly are we waiting? This is a triage situation, and delays are wasting more and more valuable time of our frustrated userbase.
Vito; can you demonstrate any local consensus (in other words, any agreement amongst the tr community) for this change?
Vito: Somebody has to create a patch for the configuration, and that patch has to get merged into the codebase.
Probably something like "'createpage' => false" somewhere around
https://gerrit.wikimedia.org/r/gitweb?p=operations/mediawiki-config.git;a=blob;f=wmf-config/InitialiseSettings.php#l7382 (that's only my uneducated guess, but if you know what to do and feel like cooking up a patch and put it into gerrit for review, it will definitely help to speed up the process).
vitomedia wrote:
Thank you, Andre. Unfortunately I don't know how to use Gerrit, but I do know (by example) that the required code is as follows:
'*' => array( 'createpage' => false ),
This line of code could be added between these two lines:
'trwiki' => array(
'autoreview' => array(
(In reply to comment #18)
Unfortunately I don't know how to use Gerrit
In case you're interested:
As already said elsewhere, per https://meta.wikimedia.org/wiki/Limits_to_configuration_changes etc., it's now an established praxis that we're not going to further restrict page creation on any project.
I see that the discussion has had very limited participation and length, so I also suggest you to look into other options for patrolling that don't make tr.wiki more sclerotic, like for instance extending patrolling right/usage (currently very limited compared to e.g. it.wiki or fr.wiki).
We can also working on an internationalisation for [[mw:Extension:PageTriage]] which was made to address similar issues on en.wiki.
The WMF may be more or less interested in making PageTriage a proper localisable extension but finding out what are the needs for it is a first start (which we can all help with, by studying it); accidents like current development deficiencies must not force you in permanent and actual evils that can kill your wiki.
Agreed with everything Nemo said. In addition; how is tr.wiki using the abusefilter and spam blacklist extensions? They're eminently helpful for this kind of thing, if you have users who can write regular expressions.
tr.wiki is already using extremely restrictive AbuseFilters; I don't know about SpamBlackList. They've also just enabled/expanded FlaggedRevisions (bug 44587), so the project surely needs more time to assess the results of the recent initiatives.
Makes sense! Perhaps indirect mechanisms would help as well; localising GuidedTours so that newcomers can be directed to activities like anti-vandalism work and patrolling.
vitomedia wrote:
*sigh*
If you were going to reject this outright, then why the heck did you waste our time with "gerrit this, and gerrit that" non-sense?
What we are asking is exactly what ckb.wiki, en.wiki, es.wikibooks, fa.wiki, id.wiki, and ta.wiki have (not to mention a few wikimania wikis). This is not unprecedented. This is *not* "createpage", and it certainly does not conflict with our philosophy. You are obligated to provide something that has precedent to a community that has reached a clear consensus.
As I've mentioned before, Turkish Wikipedia is one of the most vandalized wikis of the WMF. Its established users to all users ratio is incredibly low, and frankly, all we do sometimes is to deal with the FlaggedRevs reviews. For a wiki that has such a ratio, the job becomes instantly overwhelming, and most of the problematic edits that is reverted / has to be fixed are the kind that could not be prevented with abuse filters (By the way we have no filter-savvy users who can write one from scratch). We are understaffed, frustrated, and working quite unefficiently, which is a notion that is supported by the whole community.
By the way, if you do not believe any of this, just check out the internet usage statistics in Turkey.
You seem to ignore the fact that cultural differences and societal habits tend to influence the editing behavior, and the anonymous userbase of one wiki may be constructive, while in another wiki they may resort to vandalism way too often. I did not ask you to ban IP editing altogether, I merely asked you to disallow article creation, and I clearly explained that due processes such as Articles for Creation, and Article Wizard were to be implemented with crystal clear instructions, which would improve the quality of the prospective content.
If you require more support and opinions from the community, fine, I'll try to make it happen; but just don't waste our time.
(In reply to comment #26)
If you were going to reject this outright, then why the heck did you waste
our
time with "gerrit this, and gerrit that" non-sense?
Not my fault.
If you require more support and opinions from the community, fine, I'll try
to
make it happen; but just don't waste our time.
My suggestion to avoid wasting time was closing this bug; if you want to continue wasting your time, fine with me; I'm just a volunteer and nobody forced me to help you (removing myself from cc).
Nemo is right and we warned you about community objection to this kind of requests before a "Gerrit" mention in comments 1, 8 for example.
You can't hide yourself behind the fact Andre didn't see this is a blur policy issue, and offered a technical track with Gerrit explanations: you are as an experienced member involved in meta stuff and so had all the capabilities to see this were a social problem too. When Snowolf, Nemo and me raise questions about the sanity of your proposals, maybe it's because your proposal is a bit extreme. Sure, you gave good arguments to justify them. But this need further discussion.
If you want to further advance on this request, I guess you should initiate a new debate on meta. to get a policy about "How projects can request to restrict page creation".
With no such community éclairage, I don't think we could go further. If you don't want to start such a discussion, I offer you resolve again this bug back to the WONTFIX.
vitomedia wrote:
Could you please tell me, Sébastien, how Comment 2 is related to what we are discussing right now?
(In reply to comment #12)
Dereckson: I didn't understand your comment 8, could you elaborate / clarify
what you'd like to see / which concerns you expressed?
The logical steps to allow a very restrictive editing measure is:
(1) try with existing installed tools to fight vandalism
(2) if that doesn't work, see if we can't use a combo of the existing tools to fight against vandalism (extensions like AbuseFilter, bots like Salebot on fr. or Cluebot on en.)
(3) if that doesn't work, see if there are possibilities to develop or adapt something new (as we're neither on fr. or en., ask the bots owner if it's possible to port them for a new wiki for example)
(4) if that doesn't work, restrict editing more.
These steps are needed because the natural wiki way is to let anyone make contributions. Each time we restrict that, we go against this natural way. So we've to be very careful and evaluate cost/benefits of such measures.
My comment were a question to get more community feedback to determine if we were in such a situation. Vito replied with an explanation some steps from 2 were tried and 3 pending.
vitomedia wrote:
Would you like me to invite the community to add comments here? I barely have time to edit my own wiki these days (I will remain so at least until the end of June), and there are brilliant users who'd be willing to provide assurance for your concerns. My current frustration (which has occurred not more than once or twice until today; ask anyone!) could be irritating for some, and perhaps I should withdraw from discussions.
vitomedia wrote:
Could we make things a bit clearer?
Is this something that would never be done, or does it simply require more support from the community? I should also stress that what we are talking about is "createpage", i.e. the ability of anonymous users to create pages (not talk pages). Their ability to edit remains as-is. I am going over that, since I see (or I think I see) a hint of confusion here.
If this is something that would never be done, I'm going to ask someone to provide a community decision for this, since it is a precedented request with implementation in major wikis. I think the burden (as in the burden of proof) should be on those who intend to change an ongoing practice.
After reading the comments above, especially comment 22, comment 28 and comment 30, it is my understanding that there is a strong opposition among Bugzilla lurkers and the sysadmin community to impose further restrictions on anonymous editors on any WMF wiki.
Instead, it is preferred to use other existing ways of combating vandalism; here (repeated) are some suggestions:
Since Bugzilla does not use precedents, and decisions are made on a case-by-case basis, I suggest that you try out some (or all) of these tools, and if this doesn't work, then:
page creation") that was suggested in comment 28.
Having written all that, I am now closing this bug as RESOLVED WONTFIX. Please feel free to reopen it when there is either (1) overwhelming tr.wikipedia community consensus or (2) global consensus that wikis are allowed to restrict edit rights for anonymous users. As I understand, it would be preferable to have both (1) and (2).
Vito: you should be able to restrict page creation immediately using the title blacklist. The relevant documentation is here: [[mw:Extension:TitleBlacklist]].
The most basic example would be:
.+ <autoconfirmed>
The ".+" part is a regular expression that applies to any page title. "autoconfirmed" restricts the rule to anonymous users (by default the blacklist entries apply to all users who don't have the "tboverride" user right).
If you want to test the title blacklist at test.wikipedia.org, let me know and I'd be happy to make you an administrator there.
Of course that change would be immediately reverted by a steward or anyone with editinterface rights. :)
(In reply to comment #35)
Of course that change would be immediately reverted by a steward or anyone
with
editinterface rights. :)
When in fact they should be doing the exact opposite. I would support removing the flags of anyone caught reverting such local consensus-supported actions. Remember that stewards "are tasked with technical implementation of community consensus, and dealing with emergencies (for example, cross-wiki vandalism)".
People with global editinterface can just be blocked.