Page MenuHomeMiraheze

Introduce CreateWiki "Processes"
Open, LowPublic


When considering T11466, I had an idea that would potentially not only minimise this problem, but be a step in the right direction for introducing easier resolutions, better monitoring and a more robust/fail-safe solution that can be expanded to other areas of the CreateWiki & ManageWiki architecture and potentially be reused across MirahezeMagic for misc stuff.

CreateWiki Processes

A CreateWiki Process ("process") is a single object of individual tasks that are associated with a common objective/action. A process could be a super process which co-ordinates the execution of multiple individual process steps, or a process could be an individual action that should be executed asynchronously. Processes will operate by triggering jobs in the MediaWiki job queue. What makes a process unique is that it is persistent, while a job isn't. A process will exist and remain an interactive object before, during and after its considered "ran". A process will manage the queuing of jobs into the jobqueue and will be responsible for recording failures and managing retries - either on an automatic or on-going basis.

An example of a "Super Process" is wiki creation - there are numerous steps involved in the creation of a wiki. Some steps are non-negotiable and must be done in specific orders such as creating the database and triggering the basic install process - while other steps are negotiable and the order they are ran in or whether they succeed is irrelevant. Examples of these are rights assignment, email notifications, creating a basic main page.

An advantage of a process is the could be elements on the wiki which control retry attempts - for example if the process to assign rights fails, it should be possible for someone on the wiki to "re-trigger" this process to run. This would cut down on the number of technical and steward requests as it will devolve the power to "fix the problem by pressing a button anyone with authority" can press.

Processes should be interlinked - so for example if we wanted to make sure all jobs were "successful" before an email notification was sent out, we should be able to define in the email notification process that step x, y, z must be "successful" before that process can be triggered.

We should also create a easy to use on-wiki page where processes can be monitored, viewed, interacted with and reported on.

Event Timeline

Owen triaged this task as Normal priority.Dec 13 2023, 21:34
Owen created this task.

I mentioned on IRC that an early step failing (Swift) would block the others and that's mostly not needed. This would be as far as I can tell the gold standard of how to actually manage these tasks.

This task could further be extended to achieve things like T11634#233262 as well.

A general option could exist on Special:ManageWiki called "Start Deletion Process" - this would generate a task that has an "approval" step where all/a pre-determined number of local bureaucrats/users with "managewiki" permissions are required to "Approve" deletion - before a final deletion workflow gets triggered. A steward could be a backdoor whereby anyone with "managewiki-restricted" rights can approve all deletion steps (it would show someone else approved it).

Theoretically, we could also use this to extend ManageWiki even further by allowing certain "restricted" settings to be requested - generating a flow requiring someone with managewiki-restricted to approve changing these settings.

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

Universal_Omega lowered the priority of this task from Normal to Low.Mar 23 2024, 07:00