This user replies where he likes, and is inconsistent in that respect.
I have a limited amount of time to spend on Wikipedia. If you have a message that requires my attention, let me know by email.
I cannot help with issues about archiving your own talk page. If you have read the documentation carefully and are still having problems, a prompt and friendly answer can usually be found by asking at the teahouse.
Hi Σ. Assuming you've seen your notifications/email and are onboard, I guess we'll be working together. I'm gonna take my time assimilating/absorbing the procedures before even thinking about the technicals, but off the bat I'm envisaging a single modular tool utilising a custom library and GUI, with each task being handled by its own script (requested as needed) within that framework. That said, I haven't even read the procedures page from top to bottom yet! ;-)
If we are literally going to work together, as opposed to side by side (which IMO is more efficient), communication will be key; any immediate thoughts? Fred Gandt · talk · contribs 23:45, 7 July 2016 (UTC)
Yes, I've just read the email. And yes, it would be wise for us both to review the Arbcom clerk procedures.
From reading "a single modular tool utilising a custom library and GUI", the first thing that pops into my own mind is page curation. Did you have something else in mind?
If we are literally going to work together, as opposed to side by side (which IMO is more efficient) Not sure what you mean by "side by side", and why it's better. Could you elaborate?
GUI wise, the page curation tools look to me like the right kinda thing, but I'm unfamiliar with them, and can't judge how well they flow in use. Assuming each possible stage in the described ArbCom procedures can only be preceded and followed by other specific procedures, we can establish a use flow that reduces the GUI and required resources to a minimum i.e.
Start procedure a
Only next steps b and d possible
Select next step d
Only next step f possible
This reduces the technical, visual and cognitive noise; we only need to have certain resources available for presentation and display, and the user has less to process. It might be nice to reduce as many paths as possible to single operations, but complex paths might be better left dynamic within possible ranges. We can make each stage/step a stand-alone JS script to call as/when needed, which all use a single library. I think that provides ease for future maintenance and development by whomever follows us.
The side by side vs. together thing:
Grammatical error: My bad; side by side is IMO less efficient.
The difference between, being somewhat subtle: Talk a lot first, then work vs. work a bit, then talk a bit, then rework a bit, then talk some more...
I dunno about you, but I'd like to see the procedures first hand before trying to semi-automate them. I thought about asking Kevin to screen capture performing the actual tasks, or maybe have a sandbox to play in (dunno); I don't fancy working on a thing I can't test. Fred Gandt · talk · contribs 04:49, 8 July 2016 (UTC)
That sounds like a reasonable vision. Thanks for the clarifications, what you said about "Side by side" makes sense now.
I'd like to see the procedures first hand before trying to semi-automate them as well. Screen-capturing might be a bit overkill, but if he could annotate what he's doing as he does each task for us, that would be valuable.
Would you be able to use Git (no preference regarding where to host it) and some form of instant messaging (Google Chat, IRC, or whatever works (I don't mind back-and-forth emailing while we're at it)) for when we actually begin development? If so that would smooth things out greatly.
I'm open to suggestions for collaborative environmentals; this was just to say "hi" really, and I interpret Kevin's email as being where we're supposed to be talking. Since we're both gmailers, hangouts would be simplest for chat and all the useful extras like screensharing etc. I have a github account, but haven't actually used it for anything, so that'll be a new experience! At this precise moment, I'm tired and sleepy; glad to make your acquaintance and we can pick this up later by some kind of Google powered magic whenever suits :-) Fred Gandt · talk · contribs 10:16, 8 July 2016 (UTC)
Well, I'll be happy to work with you on this. Email me and we can start figuring out the specifics. →Σσς. (Sigma) 04:20, 9 July 2016 (UTC)
Hey folks! Fred, we got your email (as you could tell by Dave's response). In response to your request for an annotated example of the clerks' procedures:
As you can tell, for almost every case, there are subtle changes. For example, this case involved a custom, arbitrator-directed notice at the top of every case page as well as added to the editnotices. While it'd be great if you could automate such changes as part of a script, for example by having a UI option for custom notices to be added at the top of pages, it's fine if any script doesn't handle such custom details.
You may notice I have a habit of combining multiple steps into a single edit or "queueing" up several edits to be made (in seperate tabs) close to each other. For example, I made 12 edits the minute of 13:31, 18 April 2016. I'm sorry if that makes it much harder to see what I'm doing; as a general rule throughout this entire process, if you have any questions, please let me know.
Unfortunately, the written procedure may not always line up with current practice. For example, the procedures for opening a case §B1 bullet 3 mention copying statements to special sections of evidence, which is not the current practice. (I'll fix that, but not now since I'm supposedly on vacation.) This was a change introduced in June 2015, but by a clerks-l thread a few months back, it was reversed. Therefore, the controlling procedure for handling preliminary statements not made by parties is at Special:Permalink/667577303#Opening_arbitration_cases§B5. (The other procedure may also be used by discretion of the drafting arbitrator, but that is not the norm.) That's the first one of procedures not lining up that I could think of off the top of my head, but it's just something to keep in mind.
These 12 edits and these two log entries are the close of that case. There is much less variation in the close of an ArbCom case, and should be overall easier to code than a case opening.
These 10 edits are the closing of an WP:ARCA with a passing motion. Simpler still than closing a case, but involves editing a case page.
On occasion, an arbitrator will authorize a summary dismissal of a case request or ARCA request on clerks-l. These are handled in much the same way but require custom messages. This is an example.
You may notice that the WP:ACN notices and talk page notices vary somewhat. That is inconsequential, and to keep things simple, we will provide a standard form for announcements of certain types. For example, motions of whatever origin (WP:ARC, WP:ARCA, WP:A/R/M, and motions proposed on case subpages) can all use the same announcement format, similar to this.
To help you get a feel of how the procedures work, and if you request, we may (I haven't asked the other clerks yet) ask/authorize you to try actioning a simple ARCA or A/R/C.
Thanks for that detailed set of references Kevin; that really helps. Speaking purely for myself, this isn't going to happen over night. As Dave indicated, there's a lot to plough through, and again, speaking only for myself, there's a lot to think about in terms of converting unfamiliar practices to a mental overview of the control flow before even starting to write stuff.
I figure to keep things relatively simple (the reason for the modular idea), we can quite easily establish a list of every actual action that results in an edit, and use that list to build a set of scripts that perform those actions, without being too concerned with the whys and wherefores. We can then build a kind of meta script that populates the GUI and requests the modules as needed according to the control flow (the whys and wheres). My thinking is that by this methodology, we don't need to be expert with ArbCom-ing - like parts of the brain take care of breathing and regulating the heartbeat without our conscious input or awareness, we can cobble the tool (singular) together from tools (plural) which are in themselves far simpler to comprehend. This also results in something much easier to maintain for down the road IMO. Fred Gandt · talk · contribs 00:30, 11 July 2016 (UTC)
Fred: Not an option! This must be completed and in final working order in 12 hours!! Or six if you want that raise!
Don't worry, we will try not to be fascist overlords. We trust whatever method you choose will be the most convenient for you. Let us know if there's anything we can do. Thanks! Kevin (aka L235·t·c) 17:35, 12 July 2016 (UTC)
Just popping by to say that I haven't forgotten, I'm just busy, but will have time soon (but don't feel any duty to wait for me). Fred Gandt · talk · contribs 00:45, 21 July 2016 (UTC)
I've been busy too. Don't feel rushed. →Σσς. (Sigma) 04:39, 21 July 2016 (UTC)
It's not a big issue, but here an IP removed the header, then Cyberbot cleared the sandbox, restoring the header, and shortly after your bot inserted another header. Not sure if there's a way to prevent that. nyuszika7h (talk) 09:59, 18 July 2016 (UTC)
Thanks for the message. If you notice the revision numbers, my bot edited right after Cyberbot did; it was very close, and the MediaWiki documentation doesn't seem to say whether edit conflict handling can be any more precise than seconds. But I'm not sure why my bot doesn't detect that the template is on the sandbox when Cyberbot cleans it. In the meantime, though, I'm ignoring Cyberbot's edits, which should probably take care of 99% of this event's occurences. →Σσς. (Sigma) 04:39, 21 July 2016 (UTC)
Hi -- an editor at this discussion suggested that a tool for FAC stats that was similar to the AFDstats page would be useful. I wasn't familiar with the tool, but I'm impressed. Would something similar be possible for FAC reviewing stats? Details are at the linked discussion. I see from the tool's contact info that there are two contact talk pages for the tool, so I've posted this note in both places. I don't know how much work this would be, so I don't know how much of a favour I'm asking; I'll certainly understand if this isn't something y'all are interested in. Thanks -- Mike Christie (talk - contribs - library) 15:14, 20 July 2016 (UTC)
Yes, it, and more, is possible. I see Enterprisey has beaten me to the punch; I'll leave further negotiations to him. →Σσς. (Sigma) 04:39, 21 July 2016 (UTC)