Hoi,
What should be known in advance are the features that are important and how
those features function in a workflow. During the development of software
we work towards implementing such features and corresponding functionality.
We may allow for partial implementation when it fulfills a need that is
well isolated, in this way familiarity is developed in the community.
Ultimately the point when the whole is assessed for usability is when the
software is considered ready. At that time a history for instance should be
available that allows for understanding a conversation in a step by step
way. It should allow admins to do their admin thing by
removing/hiding/protecting content where applicable.
It should be obvious that when we do nothing the project is destroyed by
its own inaction It is equally obvious that when the change process is not
carefully managed, we may lose some people. Ultimately this is the lesser
of two evils. The challenge is to move deliberately, be clear that not
moving forward is no option and continuously invite comments from all our
communities, particularly our communities where English is not well
understood.
In this way we find show stoppers where they occur and work towards fixing
them or circumventing the negative impact. Personally I find the challenge
of moving the "other" languages the greatest risc. For many languages there
will be no localisation of this functionality when the software is deemed
ready. It is imho why the conversion script for LQT is vitally important;
it will enable the use of Flow in
.
Thanks,
GerardM
On 11 September 2014 00:45, Diego Moya <dialmove(a)gmail.com> wrote:
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.
_______________________________________________
Wikimedia-l mailing list, guidelines at:
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l(a)lists.wikimedia.org
Unsubscribe:
https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
<mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>