Page MenuHomeMiraheze

Enable missing ManageWiki settings
Closed, DeclinedPublic

Description

The following settings originally mentioned in the description are yet to be enabled:

  • Configuration for extensions
  • Configuration for user groups
  • The ability to make one's own wiki public/private without managewiki-restricted userright

Event Timeline

DeltaQuad lowered the priority of this task from Normal to Low.

So I gather it is very behind schedule - since it is almost the end of December 2016 and nothing major has been done for it recently. Guess it has failed the first Miraheze goal.

Why can't we just assign the current "managewiki" user right that exists on Meta globally to local bureaucrats for the time being? Then we could revert this and replace it with the full new version when it is complete @John

Because currently it allows editing of every wiki if you have the permission.

Now, I would assume that the advanced configuration settings will not be added to the Meta extension, because that would allow Wiki Creators and Stewards to change other settings of a local wiki, beyond privacy and open/closed status. Is this correct?

I doubt that wiki founders/bureaucrats would be okay with wiki creators and stewards having the technical ability to change settings that involve wiki functions and operations.

There aren't separate extension really. What's available on meta will be the exact same just it can access every wikis configuration while on a local wiki, it will only allow that one wikis to be changed.

Oh, so if some more configuration settings from Extension:Configure on MediaWiki are added to the extension, that would mean that Wiki Creators and Stewards would have the technical ability to change what features, settings, cosmetics, etc. that any wiki is using? Yikes.

Yes but it doesn't change anything like now. No changes should be done without the appropriate channels being followed. If no policy currently backed by the community (dormancy policy e.g.) backs usage or an appropriate request is made (either by the community or by someone else as appropriate deemed by a steward) then no changes should occur. This adds more to change but it changes literally nothing else. You'll be surprised but some people need help using even simple interfaces so adding a barrier isn't useful to it fir people to help.

When you say "someone else as deemed appropriate by a steward", does that mean that you are implying that stewards would have the authority to go in and change features or interfaces or other advanced settings on a wiki other than Meta, even without local community/founder approval?

Well that's more for technical reasons (though system administrators would excercise the right) or anything on legal grounds if approached by someone who is legally able to make such requests with appropriate proof (so law enforcements) where it applies appropriate to a setting that's changeable.

I acknowledge the legal aspect. However, I still don't feel that it should be acceptable to have any global user group be technically able to "interfere" with local community operations. So far, I don't believe it's ever happened severely, but we should try and prevent it from ever happening.

Stewards and/or sysadmins should be required to get community/founder approval before taking any technical/config action on a local wiki, except for legal reasons.

If a extension has a technical flaw or doesn't work at all then in order to keep things working, sysadmins have to reserve this right. It is not possible for a community to have the right to veto and purposely damage the service for everyone or themselves. In fact in the last case, it would be impossible to get community approval at all as the entire site wouldn't load.

Keep in mind I say sysadmins. Realistically they're only purpose is to keep the service up and working and such they shouldn't be doing anything outside of that scope with their access.

Alright, we aren't on the same page here. I have nothing against temporarily disabling malfunctioning extensions in the GitHub repository. What I do have something against is:

  • Currently, Special:ManageWiki only has the ability to change the site name, the status of the wiki (open/closed), and the privacy of the wiki.
  • It was said above that the plan was to add more configuration settings into the page, perhaps similar to those included in the MediaWiki extension configure.
  • If bullet #2 is implemented, it would be a little scary for Wiki Creators and Stewards (the two groups with the "managewiki" permission) to be able to change the extensions, features, cosmetics, interfaces, etc. of a local wiki other than Meta. This should only be able to be done by the bureaucrats/founders of the wiki - no one else.

The idea is it will only be done by bureaucrats on local wikis however some people aren't that competent at times.

More so in order to enforce global policies, a steward may need to use MangeWiki on a wiki.

Further so if a community consensus develops but no one is able to implement it (or refuses for one reason or another) then someone else being able to implement the community consensus is also needed.

Nothing should be done without a consensus or a strong reason. If someone does so, then they a violting policies and general trust and can be sanctioned by the community or otherwise. Being able to change a wikis config doesn't means someone WILL do it for fun or that they will abuse it. I find it interesting as well that you don't dispute the current circumstances where even in future, closing a wiki is the most disruptive thing that can happen now and in future.

I disagree. Closing a wiki without reason is bad, but being able to change the things I noted in bullet #3 of my previous comment is just as bad if not worse. With the exception of legal circumstances, no one (even sysadmins) should have the ability to change the extensions, features, interfaces, etc. of a local wiki other than Meta. We should leave this task 100% to the local bureaucrats and founders. If a community doesn't know how to change something, than in theory they wouldn't attempt to develop a consensus to do something that they don't know.

But you havent addressed the cases I listed above where:

  • there are no bureaucrats able to implement a feature;
  • there is overwhelming consensus to do something but the only bureaucrat says "I wont"

Under these two circumstances, is implementing the consensus of the community something that shouldn't be done?

Also some extensions won't be able to be enabled by bureaucrats and protected under a "managewiki-restricted" right such as VisualEditor, Flow, SocialProfile. The view here is that these extensions can't be kept on Miraheze because no one can therefore enable them. There are reasons things are as they are. It's not for control, it's tradtionally for technical reasons.

Again, unfortunately the access to this tool won't change - at least for sysadmins. They require the right to their job. The alternative is using the database that leaves 0% accountability at all.

Acknowledged the first point. For the second point, if that only bureaucrat is the original founder of the wiki, technically they have the authority to decline a configuration change for their wiki, unless, of course, it has to be done for legal or other serious reasons.

And would that restricted right protect all MediaWiki extensions or just certain sensitive ones?

Well, thars where things get fuzzy.

There are no founders. People have different views but the view of Miraheze is the community are in charge. If there is a consensus by the community, then that should be implemented. Different wikis have different structures and to make things easier then we adapt to what the relevant policies on the wiki are but if there are none regarding consensus or decisions and we are presented with a community vote then we implement that.

That restricted right would restrict only ones that need additional steps to be added, so as far as I aware only those three I listed.

So basically, Miraheze community can discuss and establish a consensus for a change on a local wiki regardless. However, the local community can veto if they have a policy to back up that action. If they don't, it will be implemented by the community (sysadmin/steward).

The local community decide how their wiki is ran. The Miraheze community (as a whole, the global community) can decide how the global aspects of Miraheze are ran.

So would this scenario be accurate?

  • The global community develops a strong consensus for a configuration change on a wiki
  • That wiki has a policy which states "all global community discussions that would involve something being changed for our wiki must be backed up and supported by us".
  • The local community of that wiki now can deny any changes being made, citing that policy, with the exception of legal reasons.

The global community can only develop a consensus for global policy. They can't develop a consensus for a change on a wiki.

Okay - that means that stewards and sysadmins can't change any configuration on a local wiki without local community consensus, except for legal reasons, correct? If they do, they would be abusing their technical rights?

Stewards can't act outside of what is supported by community consensus.

Sysadmins can't act out of anything that they can prove is required for technical reasons. By required, it is currently accepted that "unless this was done, it would cause damage or danger to any or all wikis either for privacy, resource usage, accessibility or uptime."

DeltaQuad closed this task as Resolved.EditedDec 28 2016, 21:25
DeltaQuad claimed this task.

Okay, that clears everything up.

On a completely different note, while I've got your attention, what you told me to do here didn't work - the extra group still exists on the wiki.

Also, do you have any clue how to fix this issue?

Theyre both MediaWiki stuff which isn't predomindately my area (hell there's 5 others with shell who are purposely better than me at this stuff) and I don't have time to look into issues currently.

Amanda edited subscribers, added: Amanda; removed: DeltaQuad.
Amanda renamed this task from Expand ManageWiki page to include more settings to Enable missing ManageWiki settings.May 2 2017, 22:20
Amanda reopened this task as Open.
Amanda raised the priority of this task from Low to Normal.
Amanda updated the task description. (Show Details)
John claimed this task.

"Enable missing ManageWiki settings" They don't exist.

Keep the discussion of public/private in the main task please.