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 <[email protected]> wrote:
> On 10 September 2014 19:54, Gerard Meijssen <[email protected]>
> 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
> [email protected]
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:[email protected]?subject=unsubscribe>
>
_______________________________________________
Wikimedia-l mailing list, guidelines at:
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
[email protected]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
<mailto:[email protected]?subject=unsubscribe>
