On 10 September 2014 19:54, Gerard Meijssen gerard.meijssen@gmail.com wrote:
I want us to cut the crap. Absolutely get rid of talk pages and understand what it is EXACTLY what the cost benefit is of such a change.
That should be known in advance, before removing the old mechanisms, not as a consequence of removing the tools that editors use. Those tools are in active use for a reason - if you remove the previous tools without a replacement in place, the tasks that depend upon them would cease to be performed.
When you talk about "detailed watchlists" in the context of Talk pages I have no clue what you are on about. It does not make sense to me at all.
If you don't understand what you're trying to get rid of, please don't be so eager to remove it. Detailed diffs at watchlists and wiki history are what allow experienced editors to keep track of changes to a huge volume of talk pages. They include: * edit summaries for each change that users make to the page * a quick link to the exact content of one edit (that can be set up to be read with a mouse hover, without having to navigate away from the list of changes) * summary of changes from the last visit, showing the exact changes that happened between two revisions - and nothing else.
Finding out quickly what exactly has been changed since the last time you visited a thread was a nightmare with LiquidThreads, and outright impossible with the current Flow design, yet it's an essential feature for reviewers and patrollers that have a huge number of watched pages - i.e. those editors that perform upkeep tasks and keep it reasonably clean of vandals and trolls. If we pulled the rug out and removed the tools they need to keep an eye upon destructive changes, those vital tasks to the project would be severely hurt.
When a specific way of working insists on talk pages, it means that the associated workflow has to be revisited and changed with urgency. It cannot be permitted that special interests take the whole of the much needed change hostage. "Leaving this material unchecked ..." is FUD. It is not an argument that prevents change, at most it means that a different mechanism has to be designed for that special interest.
For the record, I don't oppose replacing the old ways of working with some other mechanism to achieve the same goal that would require retraining the users. I'm opposed to replacing those *before* the new software is able to support them, as it would disrupt the project in the meantime, and there's a very real possibility that the new software could happen to not be up to the task, and that we would find it out only after the fact. "There's a chance the project may be destroyed" is not a threat that old-time editors make, it's a natural consequence of what would happen if you restrict their ability to keep the project afloat.