Page MenuHomeMiraheze

Enhancements to RequestWiki workflow for both requestors and creators
Closed, ResolvedPublic

Description

The following are some internally discussed ideas I had to improve and enhance the workflow of the CreateWiki extension, for both requestor and creator, each of which is itemized in turn.

Note: The following was previously discussed with @John and @Reception123, both of whom encouraged this task's creation.

Improvements for Wiki Requestors...

  1. Add additional fields to the RequestWiki form to improve standardization, completeness, and overall output for creators to review, which, ideally, should necessitate fewer follow-ups
    1. Purpose field (select from a drop-down list, which would be pulled from a json file in a CreateWiki repo for easy changes and additions) (mandatory field)
    2. Biographical information on real people (Yes/No drop-down options; if answer is "Yes" future AI automatically to refer request to wiki creator rather than automatically approving to programmed guidelines) (mandatory field)
  2. Change existing fields
    1. Scope and description of content (2-3 sentences or so) (freeform text entry field) (now a mandatory field)
    2. Category (select from drop-down list; currently defined in LocalSettings.php, but consider moving to a json file in the CreateWiki repo maybe?) (now a mandatory field)
    3. Eliminate "Uncategorised" as a selectable category option now that the field is mandatory. Will still have to retain, likely, this is as a grandfathered option for existing wikis given the number of wikis categorized as "uncategorised," but going forward, this should be a great improvement

Improvement(s) for Wiki Creators:

  1. Implement canned decline reasons, pulled from a json file so it can be amended easily

We can potentially add other ideas to improvement(s) for wiki creators.

Event Timeline

Dmehus triaged this task as Normal priority.Sat, Jan 30, 06:59
Dmehus created this task.
Dmehus updated the task description. (Show Details)
Dmehus updated the task description. (Show Details)
Dmehus updated the task description. (Show Details)
Reception123 lowered the priority of this task from Normal to Low.Sat, Jan 30, 07:06
Reception123 raised the priority of this task from Low to Normal.Sat, Jan 30, 07:11
Dmehus lowered the priority of this task from Normal to Low.Sat, Jan 30, 07:18

Meh, after some discussion with Reception123 on Discord, I think his low priority was probably best, but hopefully John will claim this task fairly quickly, regardless of its priority. :D

For the uncategorized suggested change, I think that we should still keep some sort of "Other", "null" or custom option, as it's always possible a specific wiki might simply not find an appropriate category.

My only question at this stage is why a json file inside the extension instead of configuration? That seems odd and would make it harder to make changes to these options and would go against MediaWiki practice for customisation

Something I would like to see is disallowing request creation when a wiki has been categorised as Private but the "Private wiki (not readable by everyone)" checkbox is unchecked or vice versa (where the checkbox is checked but the wiki has been categorised as Private).

Eliminate "Uncategorised" as a selectable category option now that the field is mandatory.

But why? It is impossible to have all the categories that wikis will need. More categories can always be added as needed but I do not think removing "Uncategorised" is or ever will be a good idea.

John claimed this task.

@John Noting https://phabricator.miraheze.org/T6788#135875, which commits resolved this, and when they be deployed?