User:Jamesmontalvo3/Approved Revs v1.0/Design Discussions

This page includes topical discussions between Yaron Koren and James Montalvo regarding the design changes for Approved Revs v1.0. Portions of emails were broken out to put each topic under separate headers.

Yaron
Speaking of reviewing, I just skimmed through your changes - I'm assuming most of your additions came to the ApprovedRevs_body.php file. Overall it looks good; one thing I noted and disagree with, though, is that a user now has, or can have, ownership of both the pages "User:Joe" and "Joe". This seems like a bad idea - first, it's unnecessary, because I haven't seen the case where such a page in the main namespace has any significance, unless the person's username is their exact real name, and second, it could lead to mischief, like a person creating an account called "Main Page" or something. I would get rid of any arbitrary-namespace stuff.

James
Good point about the User:Main Page. I'll add that to the list of things to fix.

Current Status
I don't believe this has been fixed yet.

Yaron
...which reminds me that we had a disagreement about the "Self" keyword too, when we were discussing this on the talk page, that I don't think was resolved. I think it's unnecessary, because users should always have ownership over their own user page; in other words, you should assume that "Self" line is always there. This might be related to the topic above, though.

James
Unfortunately we're still in disagreement about "Self"...not to be confused with Self-disagreement... I agree that **if** ApprovedRevs is turned on for NS_USER, then users should always have ability to approve their own pages (and subpages). But in our case, we only want to turn ApprovedRevs on where it's absolutely required, and we don't think it's required for user pages at this time. That's not to say we won't turn it on later, but I'd like to keep the choice.

Yaron
Okay - this is basically where we were in the talk page discussion, when it got sidetracked. I guess the idea is that this framework will also define which namespaces will get covered by Approved Revs. So let's say you have this line at the top:

Then, you want to set it so that only sysops can edit pages in the main namespace - i.e., the default. Would you have something like the following?

That doesn't make sense - it's redundant information. What should presumably be entered instead is just:

Similarly, for the "User" namespace, just having "User" on a line by itself should indicate that it's part of Approved Revs, and that users can approve their own user pages - it's an implicit permission.

James
I can agree that all of the following should be made to work:

However, I disagree that the first doesn't make sense. It's redundant, but still valid. In fact, the following is valid:

By allowing "Main = Group:sysop", "Main =" and just "Main" it's the most flexible and will hopefully result in the fewest questions on the ApprovedRevs talk page. Personally I like "Main = Group:sysop" because, while it is redundant, it is abundantly clear. "Main =" and "Main" kind of look like someone just forgot to finish typing.

For NS_USER, doing simply:

doesn't seem to me to satisfy the principle of least astonishment. To the new user, why should

behave any differently than

for NS_MAIN? When a newbie comes along and sees "User = Self" as the default settings, they can Google "approved revs user = self" and will probably find their answer. Also, I was just thinking that there may be cases where you'd want to disable the User=Self functionality, but allow others to approve User pages. I teach a robotics class to 4th and 5th graders, and I could see having a wiki for them with settings like:

This would allow teachers to have control over what kids displayed. I'm not saying I'm the kind of teacher who wants that...but some are.

Yaron
I think there was just a misunderstanding on that first point - I agree that all of those variations should be handled by the software; I just meant that it doesn't make sense to *require* specifying "Group:Sysop".

As for the "Self" thing - you make two valid points for keeping it, but I still disagree with the idea. Let me go through both points:

1) Minimizing confusion/astonishment - it's true that the "User" namespace would be handled differently from than any other, but I don't think the wording of that line makes a difference as far as user comprehension. That's because most regular users are simply never going to see that settings page. For most wikis, the page won't be linked to from anywhere, and users won't even know that it exists. So in either case, the Approved Revs extension page would have to be the source to explain the behavior - though, again, the vast majority of users aren't going to look at the extension page either. Regular users will figure out the software's behavior only through direct experience - that's just how it goes.

2) Having child users - this is an interesting one. Child users can fall in between productive users and vandals - they can make malicious edits without needing to be blocked, which means that they require supervision in their editing. So it makes sense to give them as little power as possible. On the other hand, I don't know how much power is really involved in being able to approve one's own user page. If some child wants to write something, say, malicious about another student in the class, they have any number of places to do it in the wiki - including their own user page; even if they can't approve their latest edit, it will still show up in "recent changes", and will be viewable at its own revision URL. And they can put it on a talk page, and so on. The real enforcement of good behavior on the wiki would have to come outside the wiki, in the real world, anyway. So I don't see this reason as that compelling, all in all - especially given that this is a fairly rare case anyway.

James
Permissions via "Main = Group:sysop" and "Main = " are no problem since they are parsed naturally by PHP's INI-parsing functions. Doing just "Main" seems too difficult to implement, so I have no intention of doing that.

I've removed the "Self" permission and replaced it with automatic self-approvability via "User = ". I still don't totally agree with you, but understand your position and don't think my objections matter that much, so I've moved on.

James
Once I have the files thing done I'm sure there will be some things to discuss. I'm sure you'll have some good ideas on how to handle the approve-file versus approve-file-page user interface. I feel like it might be confusing to some users.

Yaron
That's a tricky one... I would think the two should always go together, but maybe not. We can talk about that too. Good luck!

James
File approvals are fully functional on my "fileapproval" branch. It did not seem right to bind file-page-approvals and file-upload-approvals. The reason for this is it's very difficult to look at the history page (i.e. action=history) and determine which file you are approving. There's nowhere on that page that you can view a file and confirm that you are approving the correct revision. Instead, it makes more sense to approve files via the file history directly on the file page...so that's what I've done. To avoid confusion, and due to some conflicts I haven't addressed yet, for now I've made it so you *cannot* have approvals on the file-pages themselves. I don't think this is a big deal.

Misc things required for release
In an old email I listed the following as things that needed to be completed.

1) Fix the "Unapproved Pages" page (Special:ApprovedRevs&show=unapproved). Currently this shows all unapproved pages in the main namespace (I think) because that was the default behavior in the previous version (I think). I need to make this get its list of approvable pages from approvedrevs-permissions.


 * This is fixed. Special:ApprovedRevs "unapproved pages" displays properly.

2) What pages are approvable could be a lot more dynamic now. As such, handling of pages that have approved revisions, but are not approvable according to mediawiki:approvedrevs-permissions, needs more consideration. I think the way it should work is any page that has an approved rev should continue to be approvable and act like any approvable page. However, if it gets unapproved it will not be re-approvable (without changing something so it satisfies mediawiki:approvedrevs-permissions). I also think that I should make another special page view showing all pages that have approved revs, but that aren't technically approvable. That way the pages can easily be found and unapproved or otherwise handled.


 * On Special:ApprovedRevs there is a fourth list called "Grandfathered Pages" which lists pages which do not currently require approval but have an approved rev and thus continue to remain approvable. Additionally, since this list could be confusing to users, there is an i18n message associated with that list with an explanation of what it is for.

3) When uploading a file to mediawiki, it checks to see if there are any files with the same sha1. However, it only checks the latest version of the files. At a minimum, it should check the approved revisions as well, but I think ideally should check all pending revisions.


 * I have not addressed this issue and don't expect to have the opportunity to do so right now. I've added it as an issue on github.

James
The __APPROVEDREVS__ magic word doesn't seem necessary anymore. Using the approvedrevs-permissions scheme, it seems like using categories is more appropriate. I recommend keeping __APPROVEDREVS__ for backwards compatibility, but discouraging its use. Perhaps on the special page adding a list of pages using __APPROVEDREVS__, and suggest using your Replace Text extension to replace it with.

Yaron
We should talk about backwards compatibility in general - there's quite a bit of the current setup that might become deprecated if/when this new system goes into effect...ideally, the new setup can go in and the old settings can all remain, though eventually become deprecated. If it's difficult to maintain any part of the old settings, though, please let me know - we should talk about it.

James
For current setup all global variables perform the same way in the new revision except for the following:
 * 1) The 'approverevisions' right no longer has any effect since this should be managed in MediaWiki:Approvedrevs-permissions. The default setting for the permissions page is identical to the default settings for pre-v1.0 Approved Revs. Having 'approverevisions' rights set in LocalSettings.php won't hurt anything, though.
 * 2)   also has no effect since it is also handled in MediaWiki:Approvedrevs-permissions.
 * 3)   is now handled by using either the "Creator" permission, or by simply turning approvals on for the NS_USER (users get self-approvals by default).