Tech:Noticeboard/Request for Feedback: RequestWiki redesign

__NEWSECTIONLINK__The Technology Team is working on a redesign of the RequestWiki interface to make the wiki request process clearer, easier to follow, and more user-friendly.

A demo of the proposed new RequestWiki wizard is available at:

https://meta.mirabeta.org/wiki/Special:RequestWiki

We would like to hear feedback from the community on the proposed design. In particular, we would appreciate feedback on the usability, clarity, navigation, and overall experience of the new wizard.

Please note that submissions on Beta will not actually work. The page is provided solely as a demo of the new wizard design and is not connected to the production RequestWiki request process.

Please provide any feedback you have on the discussion. The Technology Team will review the feedback and use it to refine the redesign before it is deployed to production.

Thank you,

Universal Omega (Miraheze) (talk) 20:03, 12 September 2026 (UTC)

Comments#

Please provide any feedback, comments, or suggestions below. Universal Omega (Miraheze) (talk) 20:15, 12 September 2026 (UTC)

I’d live for this to actually work better on mobile, thats all I got to say. JoeAlunEvans (talk) 20:33, 12 September 2026 (UTC) I really don’t understand what you mean here. The design does work on mobile. Universal Omega (Miraheze) (talk) 20:51, 12 September 2026 (UTC) Are the Miraheze Developers Wiki and Public Test Wiki links supposed to be linking to broken / missing pages on this demo? Regalia (talk) 20:35, 12 September 2026 (UTC) Also the Please give us more details about the type of NSFW content that your wiki will contain text field should probably require an input, similar to the request reason text field? Regalia (talk) 20:40, 12 September 2026 (UTC) That is a good point. Thanks for pointing that out. Universal Omega (Miraheze) (talk) 20:41, 12 September 2026 (UTC) Perhaps also linking to that section in the CP would be useful. … Kind regards, ✍️ Rodejong ⁝ 💬{{int:talkpagelinktext}} ⁝ ☑️Account Info ⁝ 🔑rights ⁝ 🗄️{{int:contribslink}} ⁝ 📑{{int:sp-contributions-logs}} ⁝ (✍️guestbook) ⁝ 📆⏱️ … 10:01, 22 October 2026 (UTC) That’s just an issue on beta. It won’t be an issue once deployed. I will look into fixing it on the demo though. Universal Omega (Miraheze) (talk) 20:41, 12 September 2026 (UTC) I wouldn’t say “supposed to be” but it seems to be behaving differently to what it would be on this wiki. TheWWRNerdGuy (talk) 20:41, 12 September 2026 (UTC) I think that this new design is incredibly easy to understand and is an upgrade from before, However, I think it can be improved better if there was an option to select the skin you want in RequestWiki before submitting Parts 3 and 4 feel like it can be merged imo Splatched (talk) 20:37, 12 September 2026 (UTC) Appreciate the feedback. Allowing to add more fields, is one of the primary drivers of this redesign, and things like default skin is eventually planned either here or in some other way. Parts 3 and 4 will indeed likely end up merged in the end result. Universal Omega (Miraheze) (talk) 20:44, 12 September 2026 (UTC) Aside from my nitpicks, this looks pretty nice and should help segment things. It reminds me a little of beginner-centric help flows from enwiki like w:Help:Introduction_to_editing_with_Wiki_Markup or w:Help:Introduction_to_images_with_Wiki_Markup where it feels less intimidating because you approach it step by step. The overview at the end that you can go back and edit without going back through all the steps is very appreciated. Regalia (talk) 20:51, 12 September 2026 (UTC) I’m curious about the “The purpose of this wiki is…” dropdown. Especially confused about the meaning of some of them, like the encyclopedia ones, and about how the options are chosen, since some of them are really specific. Voxel (talk) 22:28, 12 September 2026 (UTC) I like it. Just one thing—this is out of curiosity; it probably doesn’t need to be implemented. In Step 6, the prompt asks for at least 350 characters. Do you think it might be possible to add a filter or block if the user types randomly, writes gibberish, or copies and pastes the same paragraph of about 100 characters three times? I’m not sure if I’m making myself clear. –Ucronista (talk) 04:24, 13 September 2026 (UTC) This might be possible eventually though quite complex and the AI will typically automatically decline that after request is made also. Universal Omega (Miraheze) (talk) 04:27, 13 September 2026 (UTC) If you are making a wiki about a general topic, see if a wiki already exists for it on Miraheze! We prefer existing wikis be developed rather than creating multiple wikis for the same purpose. Maybe should add Special:WikiDiscover somewhere above so the new users can search for the topic before requesting. I feel like some of the current requests might be duplicates. Elisapoly (talk) 05:18, 13 September 2026 (UTC) That is a very good idea, I think, though I would like to hear more from Stewards and other Wiki reviewers before making that change. The responsablity of the Technology Team was the design, the responsibility of how it is worded will more be up to others, as that can be fully customized by other groups by changing the interface messages on-wiki. Universal Omega (Miraheze) (talk) 05:23, 13 September 2026 (UTC) i really really like this redesign/set-up!! i never went through a request for a wiki (as much like a nepo baby i inherited the wikis i have control over), but going through it here i feel like it’s really good. i noticed when it comes to the part to describe the scope of your wiki, it doesn’t tell you the character limit until you hover over the box with your mouse. i think there should be a clearer character requirement, probably either in the corner of the text box or along the small disclaimer after the box saying there’s no formatting. this would help to be more clear with the user but also because i don’t think the character requirement is visible on mobile. outside of that, no notes!! amazing SuperKirbylover (talk) 14:43, 14 September 2026 (UTC) You do have a very good point about the character requirement. I will try and make that change before this is fully deployed. Universal Omega (Miraheze) (talk) 17:10, 14 September 2026 (UTC) I think this looks really great!! I only saw a couple of things: On Step 4 of 6, there is a typo in the second option (the one that appears when you select that the wiki contains NSFW content) - “not safe to work” instead of " for," and there seems to be some text duplication in the description of the second option :

This wiki primarily focuses on content that is not safe to work (NSFW) A wiki primarily focuses on NSFW content if its main scope covers material usually marked as NSFW (a book, movies, games, etc), is a wiki where most content itself is NSFW, or otherwise focuses on content which would typically fall under an age confirmation or separation in casual settings. It does not mean cases where the wiki occasionally covers NSFW material as part of a larger work or subject.

Also not sure if you want the field for “Please give us more details about the type of NSFW content that your wiki will contain” to be required on that page if the user has selected the NSFW checkbox.

On step 5 of 6, in the Description box, the instructions at the bottom contain a tiny little comma splice: “Unfortunately, there is no fancy formatting here, such as bold text, clickable links, etc.” (Don’t need a comma after “here”). Additional one in the fourth bullet point “If the wiki is personal (your work, vs documenting something else),” - don’t need one after “work."

Overall, I really love this! My favorite bit is the little counter dots at the top that tell you what step you’re on (genuinely). It looks good in Dark and Light modes and the icons in the header have - I believe - null alt text, which is correct since they’re decorative. I think this is a wonderful improvement and it makes me excited to request a wiki! - JaneBuzJane (talk) 22:29, 15 September 2026 (UTC) Really appreciate the feedback and for catching those typos/grammatical errors. Universal Omega (Miraheze) (talk) 22:58, 15 September 2026 (UTC) The “not safe to work” error is also present in the description of the NSFW setting in ManageWiki/core. OBSIDIANGUY (T| C| G) 14:51, 29 September 2026 (UTC) The “Category” field in step 2 is not marked as required via a “*” icon, but attempting to go to the next step results in an “This value is required.” error box being shown. The field should probably be marked as required. SomeRandomDeveloper (talk) 00:21, 16 September 2026 (UTC) It actually is marked as required, I think that might be an issue with MediaWiki and select fields. Universal Omega (Miraheze) (talk) 00:23, 16 September 2026 (UTC) {{ {{outdent}} }} This started as a direct reply to Universal Omega ^ on a change and went to getting all my thoughts out in one go, bear with me.

I think high-fidelity options to figure out if something existing is available would be great, and ideally something easier than WikiDiscover, perhaps in the vein of a cache of names/databases (and managewiki descriptions?) to run a quick ‘does this greatly overlap with something else’ check. But that’s a fairly big ask so if making WD prominent is a start and/or recommending a search, that’s still good.

— {{ {{Collapse top|1=Lengthy broader tangent on the queue}} }} There are a few things here which are probably suited to split into different channels or discussions depending on interest.

From the community end I have been chewing on User:Raidarr/Wiki request primer because there is really no way to efficiently stick what people need to know into a small box, nor does linking all the policies bode well for giving people an abridged easy understanding of what they’re getting into. This is something I’d actually like to frontload before the queue even, once the body matures. The lower section for example also contains information of niche importance but what would be better is if there was some way easier than a really long TOC for people to skim for common factors they should know a little more information about like a mini FAQ.

Some form of this would deliver necessary information and yet not oblige people to read a full half dozen policies in one sitting for which retention is very poor I am sure, things like Dormancy Policy come as a surprise and wiki governance policy remains an opaque thing to many and aren’t even in the top 3 as far as platform crucial readings. I’ve come to prioritize working out this initial information delivery.

Probably the ‘at least two sentences’ will need a wording adjustment because its rather impractical for two sentences to hit 350 characters and is a point where we could abridge essentially the top 3 things. Different wiki creators phrase it differently but my top 3 wants are what is it, how will you cover it, and risk (what are they and how will you handle them). That’s what I personally want, sometimes this is easier to convey than others and if I am reasonably confident on all 3 I am prone to say why not, which might be part of why some wiki creators have a reputation for strictness and I am considered generally quite lenient. It is tangents that draw out my stricter eye for which the primer stage I think could be helpful so people in good faith can minimize delays. If people skip that well-curated step that’s on them. If they skip ‘please read every global policy outright’ plus our less prominent reference material we hope they might know and just don’t come back after we didn’t really sell sticking around, well to fix that you’re asking for defiance of human nature and tbh we have done that for a while as a platform. “I have read and accept Content Policy, Dormancy Policy, Wiki Governance Policy and Global Conduct Policy, and by requesting a wiki, I agree to all our global policies.” is a compromise of when the process became stricter and we started wanting that; wherever you put it, if its part of the oh btw read all of this approach, I think it just won’t sink in the way we want.

“The purpose of this wiki is…” could probably resurrect the long bounced around tag cloud idea since it pretty much is just category with a mild twist. And/or something explicitly governance related since that is not always clear and I have long wanted this aspect to be more clear to users. If you’re asking for something community scoped then I treat it as a community wiki and any designation like ‘owner’ is a vanity that does not override how we treat typical public community wikis, and I would put something otherwise under quite high scrutiny. But there is good cause for more restrictive management setups. Maybe this is a step for when we are more into preloaded templates, config etc. I remain an advocate of a broad-ranging community survey as our best precedented way to ask on these matters and reduce how many RfFs will be needed to get a vibe check on what to prioritize and where to take things. I would very much enjoy seeing it later this month or in next month and would be willing to offer an eye for setting it up.

I’m not certain how it currently works but as a final post-submission step perhaps people can be redirected to view their request, its status be prominent, and an echo notification made as a ‘ding! here’s the wiki’ with a highly visible link both there and following approval. The link might even be part of ’this request has been approved:’. At the risk of an impossibly wishy detour I think this would over time mesh well with a rethink of the queue screen to obsolete the need of the third party wrangler for reviewers and to better support post-submission change like if the domain later adjusts over Phorge so the request can better serve as the canonical source of truth (not great for ancient wikis but might help the new generation). I’ve also tried intermittently to integrate scope changes into requests since there is no intuitive central process to know this and we’re not going to search Phorge or all SR history unless we have extremely specific reason to.

Coming back around it may be interesting to have the form itself offer aspects of the primer as a more eloquent integrated reference, but this seems like a lot to do upfront and might be something we need to roadmap out rather than delay progress. But it would be good imo to separate the ‘what are you doing’ from the ‘how will it be realized’ elements so people have every opportunity to come across dealbreakers and ask questions before they worry about preloaded templates if that is not meant to be. At this stage being able to save progress and encourage consultation would be nice. I would very much like to support and encourage more ‘intentional’ requests. This may also address the intermittent occasion of ‘how do I do this’ or ‘I would like to do…’ sorts of questions that are easily lost and can be hard to follow up.

All of this came out in a stream of thought so let me make this a pitch to consider if we want to more broadly solicit input in where to go, perhaps put these thoughts on staff wiki, and work them into a roadmap or just abstract goals to work to which broader survey can help us refine. Some of this is just tweaks or separate discussion but I’m really just putting a whole approach upfront here. Apologies for train-of-thought delivery. {{ {{Collapse bottom}} }}#

And now why not, where I am on the redesign itself.

I just like the incumbent approach of having one screen more as a matter of taste, I don’t like breaking things into tiny click and move on steps. An overview at the end is useful for this approach but feels broadly less useful than the overall ‘fill it then look it over where I can edit on the spot’ approach. If nobody else cares about this then I guess I defer. The funny thing about the ‘work on mobile’ comment is this approach is pretty much optimal for mobile.

“Wiki options” and “Additional information” imo are both too limited to be single screens and would be more useful in a single one. Only if we better carve out wiki options with preloads and things of that nature would both steps be useful.

Perhaps it would be worth considering more flexible ability to bounce between screens in case you just want to pop back to step 1 real quick from step 4 or 5 without needing to be at the end (which is great in offering this with edit buttons; perhaps it might benefit from ‘return to review’ merging with this function).

–raidarr ( 💬 ) 15:45, 13 September 2026 (UTC)

I really appreciate all your thoughts here. I agree, that something easier than WikiDiscover would be very ideal though perhaps very difficult to implement. As for merging Wiki options and additional information, I would like to make that clear: those were never really meant to be two separate steps in the end result. Additional information is by default all fields with no defined section. They are added via hooks in MirahezeMagic and thus we can’t set a section until the initial version is deployed and so at current they are split. Though your other point about it being useful if we added more things like loadouts got me thinking perhaps it is useful to keep seperate since things like Template loadouts, as well as perhaps default skin and other things are coming soon to it. As for your idea about making it easier to return to a previous step, that is really not a bad idea and I will see what I can do about that. Universal Omega (Miraheze) (talk) 16:04, 13 September 2026 (UTC) I think improvements to/a replacement for WikiDiscover would be easier to make if the wiki categories were to be overhauled - there seems to be quite a bit of crossover between categories (looking at you, “Entertainment”) right now, making it unclear which category many wikis should belong in. Adding descriptions to the categories could help with that too. OBSIDIANGUY (T| C| G) 14:47, 29 September 2026 (UTC) I agree the categories are not very good right now but one issue that makes any changes much harder to consider is, we can’t exactly go back to every wiki and re-categorize them. Some AI sorting solution not withstanding, we can’t really make any changes to categories that don’t at least move all the legacy existing wikis in an existing category to one other category. — PixDeVl (T|C|G) 04:41, 30 September 2026 (UTC) Realistically I think we should probably use something like Jev and just try to do it the AI way, its the only feasible path short of globally notifying every wiki to go into managewiki and change their tags. And really the optimal approach is something like both, ‘hey the system changed, check up on if the settings make sense’. –raidarr ( 💬 ) 12:32, 30 September 2026 (UTC) When I suggested redoing the categories, I was thinking globally notifying wiki owners the way you mentioned would be the most plausible way to do so. I feel like using AI to modify wikis might be a bad look for Miraheze. Sending out the notification a significant amount of time in advance of the AI changes, and only using AI if the ‘crats didn’t change it themselves, could work. OBSIDIANGUY (T| C| G) 12:58, 30 September 2026 (UTC) Then with this model even necessarily ‘didn’t change it themselves’ might not be the best line and it is done more based on general inactivity; if the bureaucrat both ignored it and was active that might be a case against automatic action, unless there is an option to ‘defer to ai’ or there was nobody who could have responded, at which point there is an automatic queue that goes through things later. All a rough spitball idea of course. –raidarr ( 💬 ) 14:15, 30 September 2026 (UTC) I like the new design, it doesn’t overwhelm users with options unlike the current redesign. ForbiddenBuild (talk) 18:27, 19 September 2026 (UTC) Just checked out the newly redesigned RequestWiki special page and it looks fantastic! Looks more on-brand with the how the newly remade welcome page when a wiki’s request is approved and the wiki has been created. — 🧺 Wicker basket · 📝 Talk · 🗄️ Edits · 📑 Logs · ✅ Verify 📆 06:02, 5 October 2026 (UTC) Just went through it, and I really like it. So I will say Chapeau! … Kind regards, ✍️ Rodejong ⁝ 💬{{int:talkpagelinktext}} ⁝ ☑️Account Info ⁝ 🔑rights ⁝ 🗄️{{int:contribslink}} ⁝ 📑{{int:sp-contributions-logs}} ⁝ (✍️guestbook) ⁝ 📆⏱️ … 10:05, 22 October 2026 (UTC)

Go to Source →