In my case, improvements should come from the side of collaborative editing, not conversation. The possibility that Tim introduced to have long-term embedded comments and real-time collaboration at articles and talk-page scratchboards would be - almost a killer app, as those are clearly impossible with plain mediawiki.
Structured conversations is not particularly appealing to us because we already have those in the current platform, and have mastered them; and having the software forcing the structure is actually limiting to us, not really something that we would crave for. The end of edit conflicts would be nice to have, but I've seen suggestions that could it make reasonably viable at mediawiki for most situations, so it's not a huge advantage either.
On 10 September 2014 22:40, Wil Sinclair wllm@wllm.com wrote:
David's really on to something here. What is the "killer app" of the platform? If we think through requirements some, we might identify just one or two features of Flow that almost all editors would find compelling. This may be enough to shift lots of criticism from "I don't want Flow because of this use case" to "I want Flow because of this killer feature, but what can we do about this use case I'm concerned about?"
It may not be apparent on first glance. Candidates for me would include well structured threaded discussions and no edit conflicts, but these don't seem to be enough for a lot of editors- particularly if they have to give up some other features that current talk pages have to offer that they find more compelling.
For those of you who are holding out on support for Flow because there isn't anything that you feel provides enough value to tip the scales in favor of Flow vs. current talk pages, can you think of any one feature- or maybe a small collection of features- that would?
,Wil
On Wed, Sep 10, 2014 at 11:00 AM, David Gerard dgerard@gmail.com wrote:
On 10 September 2014 18:54, Gerard Meijssen gerard.meijssen@gmail.com wrote:
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.
You are entirely correct. Nevertheless, the change still needs to be accepted by the crusty old editors who are used to the old ways. So we're now at the stage of: "how do we make experienced editors want and demand this?"
- d.
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
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