Wikipedia talk:Workflow improvements

Pinging in everyone from VPIL

TheTVExpert, Tol. (Also pinging SD0001 and Sdkb because I know one of you was interested, but I couldn't remember which... sorry... I assume both of you would at least be a little bit interested in this.) Enterprisey (talk!) 10:09, 19 October 2021 (UTC)[reply]

I think having hundreds of individual, separately controlled and programmed forms would be a hassle and probably cause more headaches. What would happen if a maintainer stopped editing? Or some change in MediaWiki broke everything? Etc… If something like this was to be universally rolled out, it would almost certainly have to be in the JSON format you described. We don't want only a select amount of users to be able to create forms, it would be much better if everyone, regardless of their technical knowledge, could do so.

Of course, this also opens up the option for abuse. If anyone could create such a form (whereas now this is limited to at least a check by an iadmin), I could imagine some users using the tool malisciously, e.g. adding dangerous code to a user's common.js. Of course, this could be suppressed, but there are probably many of these edge cases. At least with preloads, a user has the option to manually review the code that will be published (unless this idea also would allow this?).

Overall I definetely agree that the current preload system is horrible, ~~and that we should burn {{subst:void}} with fire~~ — Berrely • ^Talk∕_Contribs 10:29, 19 October 2021 (UTC)[reply]

(I was the one who expressed interest, I believe) I heartily support this! Let me know if I can help with it in any non-technical way. It also relates to here. {{u|Sdkb}} ^talk 16:17, 19 October 2021 (UTC)[reply]

Thanks for starting this project page, @Enterprisey. I have recently had some experience with "generalizing" things while working on Twinkle's localisation (still an incomplete project), and I've realised it's hard. Very hard. The two projects are similar but also different – for Twinkle the work involved pouring over 23000 lines of deeply enwiki centric code and unentangling the enwiki specific stuff from the generic parts, while maintaining no loss of functionality for enwiki. What's different here is that there's no significant pre-existing codebase – which is an advantage because there are no existing functionalities that must be retained, and a disadvantage because we don't what we're dealing with :)

I think defining the configurations in JSON format is going to be hard. To begin with, we should think of JS configurations – containing as little functional components and as close to JSON as possible – but pure JSON may make it impossible to handle the eccentricities that would be required for many venues.

I'd suggest restricting the scope for now to request-filing scripts. Response-filing scripts are different beasts altogether as they usually also automate the associated actions - such as userRightsManager changing user rights and RFUD-helper undeleting pages.

We have already created a handful of functional scripts for many venues, as an initial step we could abstract out the common logic (first draft of the list of such features is in Special:Diff/1050754292) into a library loaded as a hidden gadget. – SD0001 (talk) 18:20, 19 October 2021 (UTC)[reply]

I agree that creating request-filing scripts would be the best place to start, since those would benefit more editors. Some possible venues that could use these would be WP:Edit requests, WP:RM/TR, and WP:XfD, just to name a few. Then after that, eventually moving on to response scripts. All in all, I think this would a great improvement on the current systems. TheTVExpert (talk) 22:14, 19 October 2021 (UTC)[reply]

For edit requests, it would be great if this could be implemented. ― Qwerfjkl talk 11:38, 26 October 2021 (UTC)[reply]

WP:ITNC submission and related actions

Hello @Enterprisey:. Following up from our conversation at Village Pump Technical here.

As an user

be able to nominate articles (ITN, ITNRD) without having to make a template substitution or manually cut copy text from prior nominations

Template details

Template:ITN candidate

Current ITN Candidates (nomination) page

WP:ITNC

Adding some of our regular admins who might be able to chime in as well. I have not checked this post with them prior to posting. So, pardon me if the ping is spammy in nature. @Spencer, MSGJ, Stephen, Amakuru, PFHLai, Masem, and Bagumba:.

Please let know if you'd want any additional details.

Thanks for your consideration. Ktin (talk) 03:15, 20 October 2021 (UTC)[reply]

Yup, looks like a form would be a lot nicer. That process doesn't even look like it has a preload set up! Enterprisey (talk!) 08:10, 20 October 2021 (UTC)[reply]

Greetings Enterprisey, please let us know if you'd need any additional inputs from my end? If you'd want me to test something, please feel free to let know. Thanks. Ktin (talk) 04:35, 9 November 2021 (UTC)[reply]

@Ktin, nothing to test yet, but I can think of something to do, which is thinking of how an editor would go about setting up a new process using whatever we come up with. What data should they have to provide? The name, of course, and what page new requests go on, but what else? The fields of the form? How should those be specified? And more importantly, how do we allow them to be specified in a way that as many people as possible, technical or not, can do it? I've been thinking a bit but don't have anything cohesive yet. Enterprisey (talk!) 08:18, 9 November 2021 (UTC)[reply]

Greetings. I realized that I did not get back here. Also, tagging @SD0001: who recently implemented something like this for WP:DYK. Regarding the fields, Template:ITN_candidate can be a good starting point. The key thing is that there are two categories of nominations -- Blurb news, and Recent deaths. Within Blurb news there is ITNR which is a recurring nomination (e.g. Super Bowl) and all other news. No other major customizations are required. Thanks again. Ktin (talk) 22:30, 1 December 2021 (UTC)[reply]

Greetings Enterprisey wanted to follow-up to see if I could help anyway possible. Ktin (talk) 02:23, 7 January 2022 (UTC)[reply]

One of the main things right now is clarifying what exactly needs to be built for this. I listed several questions above. It would be nice to hear what you and others who work at these processes today would need, in terms of features. Ideally we target the areas of greatest need first. Enterprisey (talk!) 04:10, 7 January 2022 (UTC)[reply]

Subclassing

@SD0001 and I were talking about whether an OOP model would be good for these request scripts (scripts that show a form for making requests in these processes). The idea is you have a base class with some common methods, and then presumably a subclass per process. It sounds interesting. I would personally prefer just exposing a pile of functions (as is currently proposed) to authors of request scripts because that's conceptually simpler. Anyone else have a preference? (SD0001, I'm sure I didn't do the idea justice, feel free to correct me.) Enterprisey (talk!) 05:28, 27 October 2021 (UTC)[reply]

The OOP model isn't much different from exposing some functions. The difference is that these functions would instead be exposed as part of a class. Why? Because this means we can do things like:

class GenericForm {
  readUserInputs() {
    // ... some complicated logic  
    this.readUserInputsFromTextareas();
    // ... some more complicated logic 
  }
  readUserInputsFromTextareas() {
     return [ ... ];
  }

  addRequest() {
     this.readUserInputs();
     // ... even more logic
  }
}

class FancyProcessRequestForm extends GenericForm {
  // ugh, this is a fancy process. The usual readUserInputsFromTextareas() doesn't work for this process due to some reason. 
  // So override just the part where special handling is needed
   readUserInputsFromTextareas() {
      ...
   }

  // Now this.readUserInputs() can be used directly
}

Here's where things become interesting. FancyProcessRequestForm is exceptional in that it can use most of the logic from the "upstream" readUserInputs(), but the textarea inputs need special handling. If we just exposed the functions, this form would have no choice but to define its own readUserInputs() because it can't change the upstream behaviour. But if readUserInputs() was a part of a class, it becomes possible for subclasses to "hook into" its behaviour.

The above is probably a pathetic example, but you get the point :) So I'm in favour of this, because this increases the flexibility by quite a lot, and as far as I see, there's no disadvantage. – SD0001 (talk) 13:51, 27 October 2021 (UTC)[reply]

Wishlist Proposal

See meta:Community Wishlist Survey 2022/Editing#Make the edit request process easier. ― Qwerfjkl talk 22:23, 28 January 2022 (UTC)[reply]