Community Wishlist Survey 2022/Make wiki requesting process automatic
You are viewing a proposal made for the Community Wishlist Survey for 2022. |
- The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.
- Proposal fails in the public voting stage and is thusly declined. Agent Isai Talk to me! 04:13, 24 April 2022 (UTC)
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[edit | edit source]
- Support not only as proposer, but also because of the rationale I have put forward. Tali64³ (talk) 05:47, 1 January 2022 (UTC)
- Support per discussions below Anpang📨 02:54, 2 January 2022 (UTC)
Neutral[edit | edit source]
Oppose[edit | edit source]
- Strong oppose 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). --Raidarr (talk) 20:51, 1 January 2022 (UTC)
- Oppose According to Raidar above also. Unfortunately, that would be hard to control, everything would be messed up. --YellowFrogger • (Talk — ✐) 23:19, 1 January 2022 (UTC)
- Oppose Good-faith idea in theory, but in practice, this is not doable. Some level of human interaction, by wiki creators, on many wiki requests—especially edge cases. That being said, work is underway to improve wiki creator workflow with the introduction of the CreateWiki artificial intelligence (AI) algorithm that would score wiki requests, and, eventually, decline the most problematic or malformed requests or approve the most obvious, well formulated, and incredibly clear wiki requests. Dmehus (talk) 23:25, 1 January 2022 (UTC)
- We certainly do not need "AI" in wiki requests or anywhere on Miraheze. People hate websites that do and robots are taking away human jobs every day. This especially applies to making it entirely automatic as there is no longer a wiki request, just at the mercy of a robot. What now. Keyword optimization? No. Either allow free creating of wikis or have a real REQUEST like MANUAL APPROVAL, everywhere else there is on Miraheze. No AI on wikis. Naleksuh (talk) 03:03, 2 January 2022 (UTC)
Discussion[edit | edit source]
- @Universal Omega: can you review? ~ RhinosF1 - (chat)· acc· c - (on) 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?
- 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)
- 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):
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"] 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. Anpang📨 12:24, 21 December 2021 (UTC)
- Just as a general note: even if this CWS entry fails to pass a vote, this does not preclude the addition of a CreateWiki AI in some way, shape or form. As previously stated, the CreateWiki AI will only approve requests that reach a certain threshold or auto decline malformed requests. Keep in mind that CWS entries advisory in nature and not binding like a Request for Comments would be. Agent Isai Talk to me! 03:15, 2 January 2022 (UTC)
- @Agent Isai: I saw that you didn't like the reaction of users about automatic wiki creation process (I'm totally against this, with that, the Wiki Creator group probably wouldn't exist and that's terrible. Unless this bot only approves or decline some requests). Nobody likes that. About your talk about voting style, comparing it to "RfCs", but there is nothing wrong in my opinion, because there is no rule about voting exactly about that. --YellowFrogger • (Talk — ✐) 18:11, 2 January 2022 (UTC)
- The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section