Thread:Peteparker/@comment-1713281-20140728150738/@comment-122657-20140730193802

I've been working on a potential solution with Wikia, where any of our users could run a bot that resides on the server side of the website, but the progress is slow going. They say it's possible, but it would take some serious joined efforts between me and their programmers.

There's another potential solution I've been trying to test developed by a volunteer on another wiki. In this solution, an additional option shows on the drop-down of the page, and a little bit of javascript performs the rest of the moves/changes after using that 'rename' process instead. I've tested it twice, but it hasn't worked yet. It's difficult to say if it will work because I'm not writing the code myself, but acting as a translator/tester after someone else develops it.

For the current python bot, I have been running the bot every time I log into my computer at home for the past couple weeks. I make sure that it's the first thing I do when I open that laptop. Sometimes there have been a couple pages in the move category and sometimes there's none, but I was still going through each move and having to press yes, no, or remove to approve or reject the move. That's primarily been based on any text in the RealName or CurrentAlias fields (or their references), as well as any text in the talk page.

It would be wonderful if you guys could 'certify' the moves so I didn't have to question them. If that can be guaranteed, I'll just take out the question from the code and automatically move everything in there without making those decisions myself. Another great thing would be for admins who are 'certifying' the move to put something at the end of the talk page saying so.

For 'normal' move pages (I.E. characters/teams/items/etc.), this works great. The bot has been well developed to handle the move changes necessary to implement the work (with the exceptions of re-naming images, moving the power grid, and moving the new 'mentioned' category, which haven't been developed yet).

For most other types, I haven't developed a program that does what is necessary for each type of move. Some of them have a little pre-work done, but none of them have a specific program to run like the general move bot. To be able to have these would take several rounds of development and testing before anything would be ready to routinely use.

(I do have a bot for the 'rename' process (changing the name of an alternate reality), but it's not 100% tested. I've used it a handful of times, and have always found little pieces that it missed that I had to fix.)

The real issue with every solution is the requirement of my time. As you mentioned, I fluctuate between times I can spend a lot of time here and times I can spend none. So it's difficult to figure out when to be able to develop or test these solutions, and which solution is the right one to be putting effort into (as they all have limitations and some may not even work).

WarBlade, that's a good question. I doubt it's a manual tag removal. It's likely some weird quirk in the python script I wrote. I'll look more closely at it next time I run it, since I've reverted the tag removal at this point.

There's other ways the rest of the admins can help:
 * Category:Undecided Move is a list of all pages where a move tag has been correctly applied, but they're living in the 14 day waiting period to be hashed out. Every time I run the main move bot, these pages get updated to re-calculate the time difference and move them to the main move category if it's been more than 14 days. Admins can go through that category and alter the date that follows the name for the page to any date greater than 14 days ago if they certify the move, hence skipping the waiting period.
 * Category:Undated Move and are categories where the template has been applied incorrectly without the 'subst:' between the {{ and the Move at the beginning of the tag. Admins could routinely check those to make sure to apply the tags correctly, i.e.: {{subst:Move|Name to move to}}
 * Category:Move Comic, Category:Move Comic Volume, and Category:Move Image all need separate programs developed to effectively move them. They're put in separate categories because they have to be moved differently than main article pages. If admins want to, they can attempt to figure out how to move these correctly, write the process down, and try it. If I had processes written for these, it would be easier to code to (though still not easy).
 * Category:Rename just requires me to run a different program and has more holes/leave behinds than the main move program. So depending on if we want to pick up the scraps left by the program, or just try to move them by hand, that's up to the guys doing all the work here.

Hopefully that clarifies things a bit. I don't have definitive solutions, as I struggle to balance my time as it is, but I'm open to suggestions or solutions outside of these as well.