Last modified: 2014-08-11 13:13:20 UTC
Admins schould be able to edit & delete pages in the GWToolset namespace on commons.
Is there a link to local community consensus?
minor change, not needed.
Note that they wouldn't just be getting the ability to edit the namespace; they would get full usage of GWToolset, just like any member of the GWToolset group would have.
(In reply to Steinsplitter from comment #2) > minor change, not needed. Hmm, is "minor change" in this case defined somewhere, or is this "unwritten common sense"?
(In reply to Andre Klapper from comment #4) > (In reply to Steinsplitter from comment #2) > > minor change, not needed. > > Hmm, is "minor change" in this case defined somewhere, or is this "unwritten > common sense"? GWT is in beta, some thing need to be fixed. We have noticed that admins can't delete and edit the GWT namespace. (In reply to Jackmcbarn from comment #3) > Note that they wouldn't just be getting the ability to edit the namespace; > they would get full usage of GWToolset, just like any member of the > GWToolset group would have. They schould be able only to edit & delete in the namespace, not to do other GWT things. (Pinging DanNL)
May I quote; "Local on-wiki community consensus is needed for a configuration variable or setting change, to confirm that the request is supported by the community. This keyword is set when no link to such a discussion/decision has been provided." Therefore; any change requires a discussions a discussion. Be it an extension, a wg/wmg* setting or a right change. This has been the standard for a long time now. A feature being 'beta' does not change norms.
> (In reply to Jackmcbarn from comment #3) > > Note that they wouldn't just be getting the ability to edit the namespace; > > they would get full usage of GWToolset, just like any member of the > > GWToolset group would have. > > They schould be able only to edit & delete in the namespace, not to do other > GWT things. (Pinging DanNL) I guess we could add a new userright and make it responsible for the namespace, and give it to both admins and GWToolset users. I'll upload a patch that does that.
Commons sense pls. This is a verry verry new beta tool. @ John F. Lewis: Stop this nonsese.
(In reply to Jackmcbarn from comment #7) > > (In reply to Jackmcbarn from comment #3) > > > Note that they wouldn't just be getting the ability to edit the namespace; > > > they would get full usage of GWToolset, just like any member of the > > > GWToolset group would have. > > > > They schould be able only to edit & delete in the namespace, not to do other > > GWT things. (Pinging DanNL) > > I guess we could add a new userright and make it responsible for the > namespace, and give it to both admins and GWToolset users. I'll upload a > patch that does that. No. We have a GWT userrigt. Can you pls stop commenting if you dont know zero about this commons project?
(In reply to Steinsplitter from comment #9) > (In reply to Jackmcbarn from comment #7) > > > (In reply to Jackmcbarn from comment #3) > > > > Note that they wouldn't just be getting the ability to edit the namespace; > > > > they would get full usage of GWToolset, just like any member of the > > > > GWToolset group would have. > > > > > > They schould be able only to edit & delete in the namespace, not to do other > > > GWT things. (Pinging DanNL) > > > > I guess we could add a new userright and make it responsible for the > > namespace, and give it to both admins and GWToolset users. I'll upload a > > patch that does that. > > No. We have a GWT userrigt. > > Can you pls stop commenting if you dont know zero about this commons project? I know how MediaWiki's permission system works. Without doing what I said, we'd have to give admins access to all of GWToolset to do what you want.
Please ask for community consensus on Commons. Thank you!
actually, admins can create pages in the GWToolset namespace, as they can restore pages (but neither edit nor delete them)
The GWToolset namespace is mostly used for "saving" mappings of xml -> wikitext. I don't see any reason why admins shouldn't be able to edit it (Actually I'm kind of surprised that its restricted at all). Its not like the Campaign namespace where there's a real risk of good intentioned folks accidentally causing problems without it being noticed. And arguably since the extension just added the restrictions itself, its not like this would be over turning consensus. But a quick poll on COM:VP to make sure nobody objects doesn't seem that unreasonable.
Without word. To much bureaucracy. Why we need for a new beta tool communety consensus. It is _completly_ nonsense.
(In reply to Jackmcbarn from comment #10) > I know how MediaWiki's permission system works. Without doing what I said, > we'd have to give admins access to all of GWToolset to do what you want. Wouldn't you just need to set $wgNamespaceProtection[NS_GWTOOLSET] = array( 'editinterface', 'gwtoolset' ) or something like that? That would still not allow admins to start GWToolset jobs.
(In reply to Steinsplitter from comment #14) > Without word. To much bureaucracy. Why we need for a new beta tool > communety consensus. It is _completly_ nonsense. It is not completely nonsense; it is following a process which has been used for several years at the Foundation.
(In reply to Tisza Gergő from comment #15) > (In reply to Jackmcbarn from comment #10) > > I know how MediaWiki's permission system works. Without doing what I said, > > we'd have to give admins access to all of GWToolset to do what you want. > > Wouldn't you just need to set $wgNamespaceProtection[NS_GWTOOLSET] = array( > 'editinterface', 'gwtoolset' ) or something like that? That would still not > allow admins to start GWToolset jobs. No. If multiple permissions are specified there, you need all of them, not just one of them.
(In reply to Tisza Gergő from comment #15) > (In reply to Jackmcbarn from comment #10) > > I know how MediaWiki's permission system works. Without doing what I said, > > we'd have to give admins access to all of GWToolset to do what you want. > > Wouldn't you just need to set $wgNamespaceProtection[NS_GWTOOLSET] = array( > 'editinterface', 'gwtoolset' ) or something like that? That would still not > allow admins to start GWToolset jobs. Yes exactly. It is indeed a bug. Admins can restore pages, but not delete them because this setting is missing.
(In reply to Jackmcbarn from comment #17) > (In reply to Tisza Gergő from comment #15) > > (In reply to Jackmcbarn from comment #10) > > > I know how MediaWiki's permission system works. Without doing what I said, > > > we'd have to give admins access to all of GWToolset to do what you want. > > > > Wouldn't you just need to set $wgNamespaceProtection[NS_GWTOOLSET] = array( > > 'editinterface', 'gwtoolset' ) or something like that? That would still not > > allow admins to start GWToolset jobs. > > No. If multiple permissions are specified there, you need all of them, not > just one of them. This is complety nonsense. You are not involved in this poject, why you are counterproductive commenting here?
(In reply to John F. Lewis from comment #16) > (In reply to Steinsplitter from comment #14) > > Without word. To much bureaucracy. Why we need for a new beta tool > > communety consensus. It is _completly_ nonsense. > > It is not completely nonsense; it is following a process which has been used > for several years at the Foundation. It is 100% nonsese. We have changed servival GWT things on commons becaue it is a new tool. Is this now a REVANCHE because i have set a wikidata bug to "communety consensus needed"
(In reply to Steinsplitter from comment #20) > (In reply to John F. Lewis from comment #16) > > (In reply to Steinsplitter from comment #14) > > > Without word. To much bureaucracy. Why we need for a new beta tool > > > communety consensus. It is _completly_ nonsense. > > > > It is not completely nonsense; it is following a process which has been used > > for several years at the Foundation. > > It is 100% nonsese. We have changed servival GWT things on commons becaue it > is a new tool. > > Is this now a REVANCHE because i have set a wikidata bug to "communety > consensus needed" It is not.
Change 142617 had a related patch set (by Jackmcbarn) published: Let sysops edit the GWToolset namespace on Commons https://gerrit.wikimedia.org/r/142617
Steinsplitter: Read [[mw:Bug_management/Bugzilla_etiquette]], especially "Criticize ideas, not people." Some of your previous comments are crossing a line by not assuming that people mean well. That's not very acceptable behavior.
(In reply to Andre Klapper from comment #23) > Steinsplitter: Read [[mw:Bug_management/Bugzilla_etiquette]], especially > "Criticize ideas, not people." Some of your previous comments are crossing a > line by not assuming that people mean well. That's not very acceptable > behavior. I am not native speaker, pls assume good faith :)
+1 to this change from my side. > It is not completely nonsense; it is following a process which has been used > for several years at the Foundation. Maybe, if you ignore all the points listed below and brought up by other editors and MediaWiki developers here. To be frank, I am puzzled that even odder aka. Tomasz W. Kozlowski wants to see consensus proven. Any particular reason why, odder? As a commons 'crat, you know we had RfCs like [2] and they passed without a lot of attraction/ discussion. I. The extension was installed without community consensus. At least I never noticed any invitation to an RfC for enabling it. [1] Please prove it was really wanted by the community. If you can't I request the extension is removed from Commons immediately just for bureaucratic reasons. Bug 67211 for that. Sorry but you forced me to be pointy. II. Administrators must be able to administrate their wiki. This does not need consensus - and there is consensus that deletion, protection and revision deletion should be manageable by administrators has been provided often enough. Just because another extension is messing with the user rights, it is no reason to impose restrictions. I will start an explicit RfC that new extensions have to be passed by the community before they can be installed. That should lock-out such kind of issues for the future. III. We are volunteers. Don't make us unhappy for bureaucratic reasons. IV. Why did I have to write all this stuff again here? There is absolutely no learning. I feel more and more tired. Polemik heute geschenkt. V. "Community consensus" to restrict GWToolset rights (as too powerful to admins) was a bureaucrat-party on the bureaucrat's noticeboard. Why was this accepted? How can community consensus be established by a certain user group? I don't think so. But, well I didn't complain until now. [1] https://commons.wikimedia.org/w/index.php?title=Special%3ASearch&profile=advanced&search=GWToolset+prefix%3ACommons%3ARequests+for+comment&fulltext=Search&ns4=1&profile=advanced [2] https://commons.wikimedia.org/wiki/Commons:Requests_for_comment/Assign_translationadmin-right_to_admins
Forgot to prove V. which I herby do: https://commons.wikimedia.org/wiki/Commons:Bureaucrats%27_noticeboard/Archive_2#GW_Toolset_right
https://commons.wikimedia.org/wiki/Commons:Requests_for_comment/New_extensions anyone is invited to improve that page and make it known
Change 142617 abandoned by Jackmcbarn: Let sysops edit the GWToolset namespace on Commons Reason: 6 weeks with no activity on the bug. If we ever do get consensus to do this, it's still in working condition and can be restored. https://gerrit.wikimedia.org/r/142617
Funny: Admins can restore pages, but not deleting it.
(In reply to Steinsplitter from comment #29) > Funny: Admins can restore pages, but not deleting it. That is a new feature for MediaWiki and irrelevant of this bug.
(In reply to John F. Lewis from comment #30) > (In reply to Steinsplitter from comment #29) > > Funny: Admins can restore pages, but not deleting it. > > That is a new feature for MediaWiki and irrelevant of this bug. No. This is a bug :).
Closing this for now. Can be reopened when community consensus on commons exists (see comments above).
