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
The following settings originally mentioned in the description are yet to be enabled:
Status | Assigned | Task | ||
---|---|---|---|---|
Resolved | John | T194 [TRACKING] Add a special page that allows bureaucrats to manage some wiki settings | ||
Declined | John | T1213 Enable missing ManageWiki settings |
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
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:
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:
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 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."
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.
"Enable missing ManageWiki settings" They don't exist.
Keep the discussion of public/private in the main task please.