How to gracefully future-proof the formalised discussions? Our processes change, and the technology should change with us.

Workflow systems would do a lot for simplifying formalized discussions, at least for those discussions which are required for a process to go forward. Basically, it should be based on rules, states, tags, queues, requests, and actions.

• Actions would be things that actually affect the wiki - end results of processes. They would be able to be "gated" through not only permissions, but also on on rules.
• A request is a means of starting a "gated" process, presumably to accomplish a given action. Requests would themselves have states and would be filed into queues corresponding to their state.
• Rules define how requests, actions, tags, queues, states, permissions, and actions interact. For example, a rule defining deletion processes would:

  Offer an administrator a set of actions corresponding to speedy deletion criteria.

  Offer non-administrators the ability to start a request for speedy deletion:

  Request for speedy deletion has a state deletion = requested, denied, approved

  Request for speedy deletion has a state review = requested, upheld, overturned (for deletion review tracking)

  Request for speedy deletion has fields for the rationale.

  Request for speedy deletion has the ability for comments to be made upon the request by any user.

  Request for speedy deletion has a state holdon = no, yes, denied - non administrators can change to yes to stop the deletion, but an admin can change to denied to be allowed to proceed.

  Request for speedy deletion has a trigger, which notifies article creators upon the filing of a request.

  Request for speedy deletion has actions defined for combinations of the deletion, holdon, and review states. The administrator changes the action to approved to delete the article, then the holdon state is checked. If it is no, or denied, the article is then deleted. If it is yes, the administrator is prompted to examine further as a safety measure. Non-administrators can only make a change from a holdon state of no to a holdon state of yes by making a comment with the "holdon" checkbox ticked, or reverse their own holdon, by unchecking the tickbox on their own prior comment, which only takes effect if noone else ticks holdon for their own comment.

This is all really complex, but it gives an idea how rules based processes can work in software. The end result of all this, all users (or at least all established ones) see a delete tab on articles which gives the options for deletion that are accessible to them. For administrators, that would be performing a speedy deletion, requesting a speedy deletion (in case they want a second opinion), requesting proposed deletion, or requesting XFD. A non-admin user would have requests for speedy deletion, request for prod (if it hadn't previously been denied), and request for XFD. All of these options would be very transparent. Click the button, answer a question or two, and the process is on it's way, and the user is back to editing.

Making all this work well would also need "dashboards" for users and admins. Dashboards would show your own requests so that you could follow them to completion, queues you belonged to or were watching (so the inclusionists and deletionists can still fight over XFD), certain system notifications, and would probably merge in information from watchlists for good measure.

Defining processes with rules like this has the distinct advantage that they can be changed relatively easily. While it's not as easy to alter these processes as a wiki page, its easy enough that it's not impractical. That said, it should also be difficult enough to do that change for the sake of change is inherently frustrated and undesirable, thus making the cost of instruction creep high enough that processes don't bloat out of proportion. Triona 09:29, 31 August 2010 (UTC)