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 translatewiki.net. Thanks, GerardM
On 11 September 2014 00:45, Diego Moya dialmove@gmail.com wrote:
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.
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe