Project for issues affecting the CreateWiki extension.
Wed, Sep 9
Tue, Sep 8
Mon, Aug 24
Per a discussion with John, this will already be integrated in T5548 so there's no need to have an extra task.
Sun, Aug 23
I definitely think this is needed as well. It does get annoying to receive duplicate wiki requests. But I think a better solution would be to tell users who are trying to create a new one that they already have one and may want to edit it instead. Or block them from creating another request for an already requested DB/subdomain name.
(for whenever this is implemented, FYI the i18n message still exists as requestwiki-error-patient)
I definitely support a cooldown, perhaps no more than one wiki request in 15 minutes and no more than two in the initial 30 minutes. There shouldn't be any need for a user to submit requests for two separate wikis in 30 minutes.
Aug 19 2020
Jul 28 2020
The table needs to structured the same way, so implementing this change means we list the newest unreviewed requests first, not the oldest which is more logical.
While it could be useful to default it to that, I would like to point out that clicking on "Requested At" manually will allow you to view the most recent requests instead of the oldest.
Jul 27 2020
That would make tasks such as checking for duplicate requests easier.
Jul 24 2020
Jul 20 2020
Easy fix, use —wiki otherwise an error is expected.
Jul 16 2020
Well, why not make this a normal priority task?
All extension development tasks are low. This is towards the top of the low tasks.
I've looked in the logs and I can't see any evidence of an exception occurring around the time being reported. Without the "random hash" this is impossible to debug.
I know this doesn't follow our normal bug report format, but hopefully there's enough detail in here to trace it down and what, if any, action needs to be taken.
Jul 14 2020
Jul 12 2020
Basic plan and potential workflow for the end product shall be;
Jul 11 2020
It was UBN! Bad deploy, triaging.
Jul 10 2020
Increased further with https://github.com/miraheze/CreateWiki/commit/96dd9173c27d9582f4385a2d58706491c31d8f77
Fixed with https://github.com/miraheze/CreateWiki/commit/35b3b814810511c25ecf89be3c993b900204a4ab. Though do we want to convert this to a text column (increasing the characters to 65,535)?
Jul 7 2020
Something that could/would really help with this process is exposing the RequestWikiQueue to the api so that requests could be fetched by an external process in a programmatic fashion without having to parse raw HTML. With that alone, I'm fairly sure I could build and test a dataset and implement this in a python-based bot/script.