On 10 September 2014 19:54, Gerard Meijssen <gerard.meijssen(a)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.