DDO wiki:Administrators' noticeboard/Projects

How To Use This Page
The purpose of this page is to encourage project collaboration among the wiki editors. It has been known to happen that multiple editors decide to undertake the same or similar projects and work on it separately, when it would be much more efficient to have all interested editors collaborate on the same project.

For this page, the definition of a "Project" is a relatively major change to a page or a series of pages on the wiki. Projects would include things like: adding a new series of quests, updating new focus orb images for an entire item type, beautification of pages, template construction/revamps. General edits are not considered projects and will be removed from this page. Examples include: fixing typos or grammatical errors, any thing discussion related.

Here is the preferred template to use when adding a project:

Administrative Projects
Projects listed in this heading are for major undertakings that will require administrative rights on the wiki to accomplish.

Page protection level indicators
I've started work on a new system that will automatically show anyone interested in using the script the current protection levels in place on a page. Currently, the script adds a string of text as the first &lt;li&gt; in (to the left of) the personal toolbar (the one up top with your userlink, talklink, preferences, watchlist, contributions, and logout). You can see it in action using my testcases page for it User:Technical 13/Protection tests. The script is located in MediaWiki:Gadget-protectionNotices.js. I was thinking I would like to just use a simple two icon system to show the protection level and take up as little space as possible. Wikipedia uses a colored lock system for this purpose, but we ain't Wikipedia, so what I am thinking is that we use a colored d20 image or logo image instead of padlocks. The question becomes, which colors do we want to use to mean what things? I personally like the idea of for MediaWiki: pages (which are things that most admins shouldn't even edit),  for fully protected items, and  for semi protected items. Your thoughts and ideas? (I also uploaded &&  if someone likes those colors better)... ShoeMaker (Contributions • Message) 13:50, May 26, 2014 (EDT)


 * I have enabled the gadget for testing. I assume the die's color would be based on the edit protection and not move, correct?
 * None - no edit protection
 * Blue - semi/autoconfirmed
 * Red - full/sysop
 * Black - mw
 * They do need to have alternate text as Agonshar said, so that users can see the exact combination of edit and move protection for the page when they hover over them. --Zav (Contributions • Message) 22:04, May 26, 2014 (EDT)
 * Sorry, I've been away and kind of let this project sit idle for awhile... Anyways, I was thinking there could be either two icons to indicate edit/move levels (if different, one if same level as most will be) or one split icon that shows both in one icon (top-left half would be edit and bottom-right would be move). As far as text on mouseover, that is a given as it will take users new to the icons time to learn what each color means and how to understand the icons. ShoeMaker (Contributions • Message) 13:21, October 20, 2014 (EDT)
 * I think keeping it to one icon is best and used dual coloring if move/edit is different.&thinsp;&mdash;&thinsp;Zav&thinsp; (C&middot;T&middot;E) 21:46, October 20, 2014 (EDT)

User preferences
I'd like to get some input on an idea I have to allow administrators to help assist users fix preferences they may have accidentally changed and do not know how to fix themselves. In order for me to accomplish this project correctly, it will need to be done in two stages.
 * 1) The first stage will be for me to make modifications to user right groups, which I think should have it's own discussion exactly what we want the hierarchy of user groups to be and what rights should belong in each group.  There are multiple things that need to be fixed here from the simple things like all registered editors should be able to make changes to the wiki via the API (using javascripts for certain functions for everything from tagging pages for deletion to posting PPOI notices on user talk pages or even for administrators protecting or deleting pages or making changes in users in groups) to the ability for administrators or crats to be able to promote people to superuser (which I'm wondering if we need at all or can we just roll it into another group?) etc...
 * 2) The second stage for this particular proposal will require me to write an admin-only gadget that will allow administrators to post code to users' common.js pages that will change the setting(s) in question upon a page load and then remove itself from their common.js.  I've dabbled in creating such a script before and am certain it can be done without much fuss.
 * I look forward to everyone's replies on this idea, and am creating two sub-sections to this post below for discussing the individual stages.

Preferences gadget discussion
You can have the first reply!

User Rights
The following table is a representation of what I think the data found on Special:ListGroupRights would benefit our administrators more.


 * indicates directly permitted
 * means implied based on lower groups

Change User Groups
The following table is an interpreted representation of the abilities of each group to promote and/or demote  users from groups.

Discussion
The adjustment to the ability to assign user groups seems logical to me that anyone at a certain level should be able to promote anyone else to the same level as they are at and demote anyone at a lower level... If such a right was abused, it would be simple to have it in policy that abuse of such rights will revoke the rights immediately and a discussion about it would ensue. User privileges per each group should be explicit except in cases where one group is a prerequisite for the highest tier group. This brings us to hierarchy of groups, which should be fairly evident from the tables above. I also suggest that we hold an "election" of sorts that will result in five total stewards (can expand later if needed). The positions will consist of three static slots,, (will eventually be merged into  once the merge tool is fixed), and. Xevo is the system host, and needs full access as such; everyone is aware of my vastly technical nature of edits and my use of all of the tools and whatnot and this level is required for some of my work; Yoko is the only active founder of the wiki and although he rarely uses the permissions granted, and would surely give them up on a whim, I believe his stability on the wiki and knowledge of proper use of the rights the group offers is justification enough. The last two spots should be elected spots for balance. The two spots would be alternating two year terms (first election would be for both slots, runner up would get the shortened one year term) with an election held every year for one slot. A combination of the tallied votes along with a technical assessment of the candidate's contributions (not just edits, but also moves/deletions/blocks/renames/etc) over the previous two years would decide the victor(s) of the election. I'd love to get some feedback at this time, so I'll stop blabbing and save this edit for all to see... :) ShoeMaker (Contributions • Message) 14:18, October 20, 2014 (EDT)
 * Firstly before I make a comment on the above data table for user permissions it looks as if lots of it is displayed incorrectly, can I correct this before moving onto opening any valid arguments for and against? Example: Autopatrolled / superuser should be marked with an as implied based on lower permission user groups correct?  But it like many others is showing as directly permitted, when permissions for this exist already from lower groups - a  is for a NEWLY added permission. I am not criticizing unnecessarily, I'm being constructive and just believe the information we are basing our comments on needs to be correct first. And in true DDOwiki style I was busy editing the table to correct it and thought - whoa-there I better ASK about this first lol!! Agonshar (Contributions • Message) |  My projects  |  My ToDo list  |  My Sandbox  |  My Links  19:29, October 20, 2014 (EDT)
 * I'm glad you asked first. The only two columns that should imply anything in other groups is "ALL" and "Users".  Stewards get everything implied because they have the rights to add/remove themselves to any other group.  Other than that, everything should be explicit... That said, I do need to make a couple more minor adjustments to the crat column for implied rights. ShoeMaker (Contributions • Message) 21:10, October 20, 2014 (EDT)
 * I think you should be able to promote/demote for groups below your own except crats should be able to also to promote to crat.
 * The table is currently set up for that, the only difference is the table also suggests that people in Foo group should be able to promote others to Foo group. I suppose allowing VIPs to promote others to VIP may be zealous, and I'm certainly willing to discuss that.  Are you saying that people shouldn't be allowed to promote people to their own level group (IE admins promoting others who have succeeded their nomination to admin)? ShoeMaker (Contributions • Message) 21:58, October 20, 2014 (EDT)
 * Yes, with the exception of crat, promotion to your own group should be excluded.&thinsp;&mdash;&thinsp;Zav&thinsp; (C&middot;T&middot;E) 22:28, October 20, 2014 (EDT)
 * If we are going to exclude promotion to own group for all by crat? That doesn't make sense to me.  Steward is off the table as it's the all inclusive group assigning group, but I would think it would make sense for either all to assign to own group, all but VIP to assign to own group, or only sysop/crat to assign to own group (since they are parallel and not the same). ShoeMaker (Contributions • Message) 07:52, October 21, 2014 (EDT)
 * Shouldn't a higher group get all permissions implied from the previous group(s)? Stewards would be all implied except bot. I could fix this and reorder the rows based on increased rights requirements (two crat+ rows just above bot). No.
 * Are crats supposed to include all permissions from sysops plus two (only crat required) or have the special subset it has now (crat & sysop required)? No.
 * Are we actually going to be able to move (rename) files now?
 * Probably not, that is caused by another issue that was caused by the deprecation of where we use to store images off wiki. When all of the pages got imported in, the pages for those images did not which caused the glitch.  I believe that when someone sits down and downloads every single image off the wiki, deleted all of the malformed pages/images, then re-uploads the images one-by-one, the issue will resolve itself.  That process will take quite a long time however and it would be best if it was preformed by a bot.  I'm actually taking Java and C++ this semester, and I think I can learn to write such a bot.  Until then... Meh... ShoeMaker (Contributions • Message) 21:58, October 20, 2014 (EDT)
 * Are we just adding it for the future then?&thinsp;&mdash;&thinsp;Zav&thinsp; (C&middot;T&middot;E) 22:28, October 20, 2014 (EDT)
 * Nope, it's actually there now; we're just maintaining it for the future. :) ShoeMaker (Contributions • Message) 23:27, October 20, 2014 (EDT)
 * Ah, ok. I though it might be new since it isn't on DDO wiki:ListGroupRights.&thinsp;&mdash;&thinsp;Zav&thinsp; (C&middot;T&middot;E) 07:16, October 21, 2014 (EDT)
 * Should stewards be considered bots? I think currently they must add themselves to bot to get that right.
 * Admins and crats are parallel, steward is one step up, and bot is a different entity altogether for bot stuff. ShoeMaker (Contributions • Message) 21:58, October 20, 2014 (EDT)
 * I was referring to the bot right, not group. Should stewards have the bot right? Wouldn't that make steward edits marked as bot all the time?&thinsp;&mdash;&thinsp;Zav&thinsp; (C&middot;T&middot;E) 22:28, October 20, 2014 (EDT)
 * Then no, stewards should not have all their edits flagged as (semi-)automated bot edits. ShoeMaker (Contributions • Message) 23:27, October 20, 2014 (EDT)
 * Shouldn't all other Steward rights be implied ?
 * Implied in what? I'm confused. ShoeMaker (Contributions • Message) 21:58, October 20, 2014 (EDT)
 * Implied instead of explicit . All steward rights should be, not , with no bot right.&thinsp;&mdash;&thinsp;Zav&thinsp; (C&middot;T&middot;E) 22:28, October 20, 2014 (EDT)
 * is explicitly defined, which simply means that it doesn't rely on the other user groups. It's possible (although highly unlikely) for a VIP to jump right to steward with community vote and technical assessment. Since stewards can add remove their own usergroups at a whim, everything that isn't explicitly defined is implied by their ability to promote themselves but they wouldn't normally need those other tools.  I don't feel I'm clarifying this very well though... ShoeMaker (Contributions • Message) 23:27, October 20, 2014 (EDT)
 * Do you mean that the rights that are currently explicit are the rights of the steward group itself and the rest are implied by the ability to assign usergroups?&thinsp;&mdash;&thinsp;Zav&thinsp; (C&middot;T&middot;E) 07:16, October 21, 2014 (EDT)
 * Seems like you're getting pretty close. All of the  rights above will be (if not already) assigned directly to the group, all of the  rights are implied based on the fact that those rights were assigned in "ALL" or in "Users" or the fact that the user can assign themselves to a group that has the right.  IIRC, it is also possible to set it up so that users can only (pro/de)mote others to a group, but not themselves; if that is something we want to consider for a specific group. ShoeMaker (Contributions • Message) 07:52, October 21, 2014 (EDT)
 * Shouldn't API be implied for all groups above users?
 * It theoretically could be, however, I want to explicitly define it for admin and bot. ShoeMaker (Contributions • Message) 21:58, October 20, 2014 (EDT)
 * Should crats be able to promote and/or demote sysops? I would think they should be able to ( EN:WP:Special:ListGroupRights ).
 * Currently they are suppose to be able to, and I originally had it in the table to do so based on that, but I'm thinking it would be a better idea to make sysop and crat to be separate parallel groups. Willing to discuss. ShoeMaker (Contributions • Message) 21:58, October 20, 2014 (EDT)
 * I can see them being parallel instead of increasing hierarchy like it is now. In either case I think crats should be able to promote/demote VIP, SU, & sysop and promote to crat.&thinsp;&mdash;&thinsp;Zav&thinsp; (C&middot;T&middot;E) 22:28, October 20, 2014 (EDT)
 * That would allow them to promote themselves to administrator without community consensus, do we really want to allow that? ShoeMaker (Contributions • Message) 23:27, October 20, 2014 (EDT)
 * Yes, it would allow that; however, crats should still be following the sysop promotion/demotion rules.&thinsp;&mdash;&thinsp;Zav&thinsp; (C&middot;T&middot;E) 07:16, October 21, 2014 (EDT)
 * While I agree they "should be", do we really want to leave that door open and go down that road if they choose not to? I'm more inclined to remove the temptation and not deal with the slew of crap that comes from dealing with a disgruntled sysop/crat (like what happened last time).  ShoeMaker (Contributions • Message) 07:52, October 21, 2014 (EDT)
 * I'm sure I'll think of more.&thinsp;&mdash;&thinsp;Zav&thinsp; (C&middot;T&middot;E) 21:39, October 20, 2014 (EDT)
 * I look forward to them. :) ShoeMaker (Contributions • Message) 21:58, October 20, 2014 (EDT)

DDO Wiki Projects
Projects listed in this heading are for any planned, proposed, ongoing, or recently completed projects dealing with the upkeep and maintenance of this wiki.

Template Projects
Projects listed in this heading are for any planned, proposed, ongoing, or recently completed template projects.

Image Projects
'Projects listed in this heading are for any Image related projects. New items, updating images, etc...'

General Projects
'Projects listed in this heading are for any project that does not fall into any of the above categories. Anything from adding new quests, to updating data because of recent updates/expansions'