Fixed the echo in the room in https://github.com/miraheze/CreateWiki/commit/6ef766794d222b5bf78a8f7bf1a5bcb7ac385e27 (it’s always the small things)

Noting that this is currently stuck on the new needs more details status Echo notifications not working.

Order up, one miraheze-loadouts swift container, made to go. See creation logs here

Briefly discussed the implementation of this a couple of weeks ago and we decided that something like a Swift Container would be appropriate for this. So if someone with Swift access could create a container, "miraheze-loadouts" or something like that then that would be grand.

In T11735#240733, @Reception123 wrote:

Based on the conversation we had in the wiki creator channel a while back, my understanding was the new workflow would be:
"Needs more details" (new status) - used when there's not enough details to decline/approve
"On hold" - only used in cases where there are enough details but the wiki creator isn't sure whether it will comply with the CP and needs a second opinion or a WC chat

So indeed, on hold is not to be used whenever.

As for the 72 hours, we can probably try 120 instead (5 days) to avoid the weekend problem that you cite.

Done in https://github.com/miraheze/CreateWiki/commit/001c5a422feab8c0afa116ca90cbad16b4beb393, with some required follow-up fixes at https://github.com/miraheze/CreateWiki/commit/fa9cd74a0ce5a979ee822d03c8208f5282a9bc77, https://github.com/miraheze/CreateWiki/commit/d4ddc2ff2b96224c455e27d39ef24beb6d0046a7 and https://github.com/miraheze/CreateWiki/commit/45b622d624fff8f15303e68a51020f393118ec77 required in order for it to fully work.

In T11735#240732, @Rodejong wrote:

In T11735#235314, @Redmin wrote:

Something to keep in mind is that sometimes it may be the case that a request is put on hold by a WC for review by another WC/Steward and then nobody gets to it within 72 hours; the request should not be declined in that case.

I want to add that we should avoid the attitude of "putting on hold just to clear the "In review" list, which I have seen happen.
Then we would avoid that from happening to easy.

We also need to consider that some organisations often only work Monday to Friday. If a Request is made on Thursday, we decline it on Sunday. I don't think that is right either. One way to avoid that is to not allow automated deletion in the weekend. For me it sounds unfair to come on monday and see a declined wiki, because you didn't reply sooner.

Another thought is, that when a person requests a wiki, to notify for how long a request will be open for, urging them to take action.

Just a few of my thoughts. Kind regards

In T11735#235314, @Redmin wrote:

Something to keep in mind is that sometimes it may be the case that a request is put on hold by a WC for review by another WC/Steward and then nobody gets to it within 72 hours; the request should not be declined in that case.

https://github.com/miraheze/CreateWiki/pull/503

Lowered to 1 week due to changes making deletion quicker for never edited wikis.

https://github.com/miraheze/CreateWiki/security/advisories/GHSA-4rcf-3cj2-46mq

GHSA published, CVE ID CVE-2024-29883 has been assigned to it.

Available since commit 675caeb is the REST endpoint createwiki/v0/query_wiki_request/{id}. You can see it in action at https://meta.mirabeta.org/w/rest.php/createwiki/v0/query_wiki_request/5. Keep in mind the following:

In T10683#240144, @Void wrote:

I'm wondering if we could just make canned responses a MediaWiki interface page similar to MediaWiki:Deletereason-dropdown. Alternately, changing the form field from selectorother to combobox may work to make the canned responses editable in the form itself.

I'm wondering if we could just make canned responses a MediaWiki interface page similar to MediaWiki:Deletereason-dropdown. Alternately, changing the form field from selectorother to combobox may work to make the canned responses editable in the form itself.

Part of this task is done: the canned responses are now available to JavaScript code on subpages of Special:RequestWikiQueue. However, I'm stalling the rest of this task on T11931 because my original idea of hacking the form in order to allow for canned responses to be edited is too hacky even for me. Having an API will allow for this to be done more cleanly.

If used in the same method as ImportDump using no-dismiss for certain events, etc.. with the fixing of our actual email system, which was the core cause of this and the issue no longer happens.

https://github.com/miraheze/CreateWiki/pull/487

In T11901#239052, @OrangeStar wrote:

In T11901#238730, @Original_Authority wrote:

1. Storing the dumps: this relies on the idea that the dumps are exported as XML files from an actual wiki. My thought was that we could create a loadout wiki for each language, and periodically export that to a folder in Swift, and then the script would use the correct dump for the correct language variant of that wiki. I'm not sure if this would work, though, and would be a lot of wikis? But it is the idea I envisioned and is also how it is done on Fandom and previously Gamepedia. We could run a cron or something to automatically export the dump or something stupid like that.
2. The Mainpage: this would also mean that we didn't have to use the maintenance script to create the main page, because it can be created by the loadout. Is this a good idea? I'd say so, since it would mean one less thing to have a script for.

LGTM. Aditionally, one thing that comes to mind is that this would make it easier for anyone to edit the default main page. I remember that @Raidarr on Discord mentioned wanting to edit the default main page, which is not currently an easy task since the message is very hard to edit since currently it is in a one line interface message.

We should look at how we approach allowing contributions in this hypothetical wiki. While it may be a bit too risky to allow anyone to edit, we could allow trusted users outside of SRE to also have edit rights on the loadout wiki, makes it easier for non-techies to contribute to especially the default main page.

In T11901#238730, @Original_Authority wrote:

1. Storing the dumps: this relies on the idea that the dumps are exported as XML files from an actual wiki. My thought was that we could create a loadout wiki for each language, and periodically export that to a folder in Swift, and then the script would use the correct dump for the correct language variant of that wiki. I'm not sure if this would work, though, and would be a lot of wikis? But it is the idea I envisioned and is also how it is done on Fandom and previously Gamepedia. We could run a cron or something to automatically export the dump or something stupid like that.
2. The Mainpage: this would also mean that we didn't have to use the maintenance script to create the main page, because it can be created by the loadout. Is this a good idea? I'd say so, since it would mean one less thing to have a script for.

As a wiki creator: yes please. We just have to expose the canned responses to JavaScript, then add some JavaScript on our RL modules that adds the canned response to a textarea for editing by the wiki creator.

In T11901#238745, @PixDeVl wrote:

Also- down the line, would it be possible to allow for selection groups of templates? Say, I want to include standard MBox notices and the hatnote collection but I don't want infoboxes cluttering my wiki. If we go with the XML route this seems like it may be easy enough:tm:. For a loadout.miraheze.org wiki maybe could use categories or namespaces.

Also- down the line, would it be possible to allow for selection groups of templates? Say, I want to include standard MBox notices and the hatnote collection but I don't want infoboxes cluttering my wiki. If we go with the XML route this seems like it may be easy enough:tm:. For a loadout.miraheze.org wiki maybe could use categories or namespaces.

I have a working copy of this now, which is good progress. But before refining it, I'd like to get some opinions on the best way that this should be approached (cc. @Universal_Omega, @OrangeStar). The existing version I have has been tested with S3 (because I don't have access to a Swift instance, but will test with Swift before completion), and works on the basis that an XML dump is stored in Swift, which is downloaded as a stream, saved to the filesystem temporarily, and then imported and deleted.

This is mostly fixed, the only thing is that it "inactive" mode redirects to an empty subdomain when there are no inactive wikis... which we is currently true due to unrelated issues with the wiki deletion script.

In T10844#235251, @Original_Authority wrote:

@Agent_Isai is there plans to bring over the changes WikiTide made to S:RW for this?

Resolved by @OrangeStar. Thank you!

To give everyone an update, I'm going to be rewriting this part of RequestWiki so that it does not use upserts and behaves more like ImportDump. I believe that may fix the issue, or at least give us a different error :p.

@Agent_Isai shared this stacktrace on #miraheze:

@Original_Authority For what it's worth I think that'd be a good idea, as long as it works with emails too as Echo does.

In T11735#235314, @Redmin wrote:

Something to keep in mind is that sometimes it may be the case that a request is put on hold by a WC for review by another WC/Steward and then nobody gets to it within 72 hours; the request should not be declined in that case.

Something to keep in mind is that sometimes it may be the case that a request is put on hold by a WC for review by another WC/Steward and then nobody gets to it within 72 hours; the request should not be declined in that case.

Similarly to T11634, another thing this task could help achieve would be requiring at least two wiki creators for approvals and declines. That way, wiki requests won't depend on a single person but instead will have the advantage of being reviewed by two people

@Agent_Isai is there plans to bring over the changes WikiTide made to S:RW for this?

Closing as resolved as there have been no reported issues since then to my knowledge and given the time that has passed it would be difficult to get logs now to investigate. If this happens again please reopen

I have a somewhat bizzare idea, but one that I think would be beneficial in the longer run. Since we will potentially be overhauling the notification system, I think this is a good time to potentially split a bit of it off from MediaWiki as its own service.

Pull request in https://github.com/miraheze/WikiDiscover/pull/107

Wikis that are marked as deleted always retain their database until they're permanently deleted so I'm not sure why the cross reference would be needed.