Community Wishlist Survey 2022/Make wiki requesting process automatic

Proposed by Tali64³

Proposal summary: Make CreateWiki extension able to detect problematic requests.

Full proposal: In 2021, the CreateWiki extension made the wiki process almost automatic. The problem is it's only almost automatic. A wiki creator still needs to approve the request before the wiki can be created. The CreateWiki extension should be able to detect wiki requests that are problematic (for example, hate-based requests, ones that aren't descriptive enough, and ones that copy other wikis) and decline them. Likewise, it should approve requests that aren't. Then, the wiki creation process will be fully automatic. No user involvement!

Here are some criteria requests must follow to be approved (suggested by Anpang):
 * Requests must be at least 100 characters long.
 * Requests may not contain words that suggest the request is likely to violate the Content Policy (such as "criticize" or "advertise")

Support
not only as proposer, but also because of the rationale I have put forward. Tali64³ (talk) 05:47, 1 January 2022 (UTC)

Oppose

 * 1) Per my previous statements, I disagree that Miraheze is technically 'mature' enough to make the process automatic. Amount of words and not hitting overly restrictive keyword clauses do not make a request inherently good, and measuring by presence of strings is problematic. Scanning for certain words is infeasible; the words could well be used in a multitude of contexts to demonstrate how the wiki will not attack people, how it may tangentially permit constructive criticism, documents advertising practices in aggregate, and any number of acceptable contexts. Requests can potentially be accepted with 1-2 sentences if they are sufficient in all ancillary aspects of the request + a concise description that does not cause concern. The only point where I see this being helpful is to automatically decline certain scenarios where a request only contains a few words, has an invalid domain name (WCs aren't even allowed to hit create for a wiki that is not technically possible to create, yet people can request them anyway), various keywords in domain name that we simply wouldn't accept, and requests with essentially nonexistent attention to the non-description elements or which neglect the description entirely. Such would somewhat help reduce turnaround time for acceptable wiki creations. Otherwise you can make a sweeping, 'perfect' criterium for acceptance and it would not be universally acceptable. The point of the process as it is, is to solicit a human effort in making request, and have a human respond to it. In the future perhaps this will not be needed, but I certainly do not see that future as appropriate for a wishlist of this year. My rationale does not include more periphery considerations, like the 'job' of wiki creator (if a sufficient mechanism can make the process more efficient, perfect, it's volunteering time to other things).

Discussion
 Anpang 📨 01:16, 21 December 2021 (UTC)
 * can you review? ~ RhinosF1 - (chat)· acc· c -  14:51, 20 December 2021 (UTC)
 * But I don't understand "automatic", won't you need a Wiki creator to create the wiki? Would be an interesting idea and even better in theory, but this will let multiple people create multiple wikis without enough scope and will clutter up the Miraheze servers, which needs a donation for maintenance and may end up in debt. YellowFrogger (✉ Talk  ✐ Edits ) 18:15, 20 December 2021 (UTC)
 * No, you won't need a wiki creator if this passes. The CreateWiki extension will be modified to detect requests with not enough description and those that are likely to cause problems (hate-based or advertising wikis, for example). Tali64³ (talk) 18:33, 20 December 2021 (UTC)
 * Maybe some criteria like this?
 * Request description must be atleast 100 chars long
 * Request description must contain a comma, "and", or "or"
 * Wiki subdomain must end with .miraheze.org
 * Request must not contain words that likely causes content policy violations
 * Anpang: This will be handcrafted by an AI bot, actually YellowFrogger (✉ Talk  ✐ Edits )</b> 02:07, 21 December 2021 (UTC)
 * I think AI isn't required for that, just a bot checking strings <span style="display:inline-block;border:2px solid #bfff00;border-radius:8px;background-image:linear-gradient(to bottom right, #75ff75, #ffff80)"> Anpang 📨 02:08, 21 December 2021 (UTC)

cp_violate = ["attack", "delete", "critic", "criticize", "advertise", "criticizing", "advertising", "kill", "hack", "defeat", "business", "sell"] wikis_already_hosted = ["meta", "login", "like a list of all 4800 wikis miraheze is hosting"]
 * I'm avoiding direct comments because the voting period isn't until next year, but this is one of the ideas I think is not mature enough (in execution) to be anything more than a long term consideration. If anything, we simply aren't near full autonomy at all. It's just a reasonably convenient manual process, but even that process warrants improvement, and that should be considered before then transitioning to full autonomy. --Raidarr (talk) 10:07, 21 December 2021 (UTC)
 * What would this mean for us wiki creators? --DarkMatterMan4500 (talk) (contribs) 10:46, 21 December 2021 (UTC)
 * Here's a rough idea (coded in python):

def check_request(ent,subd): if ent in cp_violate: return("Bad request - violates content policy") elif len(ent) < 101: return("Bad request - too short") elif subd in wikis_already_hosted: return("Bad request - wiki with subdomain already exists") else: return("Accept")

print(check_request("Request description","Subdomain (not including .miraheze.org)")) Well there's a flaw to that, it only checks if the content is a word that violates content policy not it contains a word that violates content policy. <span style="display:inline-block;border:2px solid #bfff00;border-radius:8px;background-image:linear-gradient(to bottom right, #75ff75, #ffff80)"> Anpang 📨 12:24, 21 December 2021 (UTC)