Re: [Wikimedia-l] To Flow: on featured article discussions

[Diego Moya]

On 17 September 2014 12:46, Amir E. Aharoni
 wrote:
> Nitpick: If watchlist and notifications remain separated, it makes more
> sense to me to call the operation that adds something to watchlist "watch"
> rather than ''subscribe".

Good catch, that makes sense for me too.

That would make "subscribe" a high level concept, easier to explain to
newcomers, that is composed of both "watched threads" and
"notifications" that expert editors could handle in more fine-grained
detail.

___
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, 

Re: [Wikimedia-l] To Flow: on featured article discussions

[Diego Moya]

On 16 September 2014 21:32, Danny Horn  wrote:
> Diego, that is definitely what we're thinking about for the subscriptions
> options -- giving users the ability to choose whether they want to
> subscribe to every new thread, or just get a notification that a new thread
> has been created.

Danny, that is definitely *not* what I'm thinking about, :-(  and
there are nuances that are not getting through the conversation noise
- or at least I've been so far unable to explain myself as to what
those nuances are.

Can you at least acknowledge that you understand the difference
between "subscription" (with respect to items appearing at the
Watchlist) and "notifications" (with respect to Echo)? I haven't seen
that difference tackled in any of the communications from the
development team, although several editors have recognized it as
significant.


>The balance that we have to figure out is how to provide
> options on that page-by-page level without forcing people to go through two
> clicks every time.

I'd go with the route of allowing users to select the default value
for both subscriptions and notifications (with new users subscribed
and notified of all conversations they post to, and experienced
editors with lots of pages changing the default to "don't subscribe").
The current subscription check can be set up that way (in
Preferences->Watchlist->Advanced options), and it works very well.

If those options were available, I would configure mine to "subscribe
to all topics" and "don't notify me about any topic" as the default.



> We'll probably be tackling the subscription/notifications question in more
> detail in a few weeks. Right now, we're working on Hide, the Table of
> Contents, Search and the LiquidThreads transition. There's a lot to do! But
> we'll definitely be getting back to notification options before too long.
>

That's great, there's a time for tackling each problem in a long term
project. When the time comes, I hope you gather a sample of desired
workflows and needs (including mine), *before* you start analyzing
possible designs that solve them. ;-)

___
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, 

Re: [Wikimedia-l] To Flow: on featured article discussions

[Diego Moya]

On 15 September 2014 19:24, Danny Horn  wrote:
> Some people are seeing Flow messages as really important, something that
> they want to get updates on right away -- and "right away" can mean either
> in their watchlist where they go all the time, or in Echo where they'll see
> the notification. Other people see Flow messages as something they'll get
> to later, and they want to see more of a message inbox.

And then you have people like me who see them as *both*, just not for
the same pages. I've suggested that some topics and boards should
raise notifications and not others, depending on how important each
topic is for the user.

At least one other editor suggested that this could be done with a
check ("notify me of updates for this board") to be selected on the
pop-up that appears when you add a topic to your watchlist. Is there
someone taking note of all these scattered suggestions in a central
place where they can be discussed?

___
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, 

Re: [Wikimedia-l] To Flow: on featured article discussions

[Diego Moya]

On 15 September 2014 15:24, Amir E. Aharoni
 wrote:
> That is quite true. A deep modernization of the Watchlist should be coupled
> with the Flow poject somehow. Either Special:Watchlist itself should be
> profoundly redesigned and upgraded, or the Flow+Echo notifications should
> become so good that they can replace it.
>

Whatever you do, please don't try to replace the Watchlist with Echo
notifications; they serve quite different roles and are complementary,
not a surrogate.

The recent backlash that Echo received when it was updated last week
was in part because of that, as it included as notifications all the
updates that would normally be seek out at the watchlist and therefore
shouldn't generate an alert.

I agree that the Watchlist could be enhanced with more granular
filters, groupings and search functions. A lot of user workflows are
based on personal usages of the watchlist, which work as the de-facto
coordination tool between editors participating in the same projects.

___
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, 

Re: [Wikimedia-l] To Flow or not to Flow

[Diego Moya]

On 10 September 2014 19:54, Gerard Meijssen  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, 

Re: [Wikimedia-l] To Flow or not to Flow

[Diego Moya]

On 10 September 2014 22:49, Martijn Hoekstra  wrote:
>> That doesn't make any difference, Martijn. I ''want'' to be subscribed
>> to all the topics at my 3000 pages, I just don't want to get a
>> notification for all them; I want to actively seek most of those at
>> the watchlist in an opportunistic way.
>>
>
> A single thread is a single topic.

Sorry, I was referring to an encyclopedic topic (i.e. what's covered
by an article), not a conversation topic. In this context, we editors
call "the topic" or "the article's topic" to what's discussed about
the article, which is covered by all the conversations at an article's
Talk page, that corresponds to a Flow Board. And a Board (i.e. what I
called a page above) can contain hundreds of threads.

In short, I want to see updates to all threads that happen at all my
subscribed articles, but I only want to be notified from updates to
talk pages at those articles that I really care for.

(...I've just realized this overloading of the word "topic" may be a
problem. Something to take into account in future conversations
between the community and development team).

___
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, 

Re: [Wikimedia-l] To Flow or not to Flow

[Diego Moya]

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  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  wrote:
>> On 10 September 2014 18:54, Gerard Meijssen  
>> 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, 
>> 
>
> ___
> 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, 
> 

___
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, 

Re: [Wikimedia-l] To Flow or not to Flow

[Diego Moya]

On 10 September 2014 19:49, Martijn Hoekstra  wrote:
> On Wed, Sep 10, 2014 at 7:17 PM, Diego Moya  wrote:
>> The feature shouldn't be "notify on all posts on the subscribed
>> thread" either. I don't want to be notified every time a new thread
>> appears at any one of my watched pages.
>
>
> Hence the "on the subscribed thread" not "on any thread on the
> board/watched page"
>

That doesn't make any difference, Martijn. I ''want'' to be subscribed
to all the topics at my 3000 pages, I just don't want to get a
notification for all them; I want to actively seek most of those at
the watchlist in an opportunistic way.

Notifications from a few selected subset of pages would be a godsend;
however, if it was deployed to all talk pages with the current design,
I'd have to disable the category of notifications from conversations -
it's simply too distracting. The "howler" notification widget (is that
its name? I first heard it this week) draws all attention when it's
activated, in particular with that bright red color; I want it to be
activated only for things I deem important, so  that I only have to
evaluate it for things that require my immediate evaluation. If it
gets triggered too often, it disrupts the attention I pay to my other
main tasks. This distinction between actively seeking updates in the
Watchlist and passive notification from Echo seems missing from the
design, at least for events that are not alerts.


>
>> However, it's hard to tell whether such suggestions ever reach the
>> development team; it's clear that this one need didn't arrive in time
>> to be taken into account before the release.
>>
>
> Says who? What do you consider a release exactly?
>

Anything that can affect what an editor can see at en.wiki or any
other community site without activating it at Preferences>Beta (that's
the official channel for opting in to experimental features, right?)


>>
>>
>> > Everybody acknowledges the former is a mistake and stuff like that can
>> > happen in testing.
>>
>> This is not testing, this was rolled out to the production
>> environment.
>
>
> I'm confused. Where? Did I miss something? (please don't hesitate to say
> "yes" if the answer is yes)

Yes, editors who subscribed to Wikiproject Breakfast and Wikiproject
Hampshire have been receiving some strange, months-old notifications
this week from those Flow pages. Danny had to step in at en:Talk:Flow
and recommend that users disabled notifications from Flow to avoid
problems.

___
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-requ...@lists.wikimedia.org?subject=unsubscribe>

Re: [Wikimedia-l] To Flow or not to Flow

[Diego Moya]

On 10 September 2014 22:28, Brad Jorsch (Anomie)  wrote:
>
> On Wed, Sep 10, 2014 at 1:17 PM, Diego Moya  wrote:
>
>> I have about 3000 pages in my
>> watchlist, and receive around 400 updates daily only from talk pages,
>> which 50 or so come from unique pages; getting all those as
>> notifications would render Echo useless to me.
> I wouldn't want that either. But maybe newbies would; that should probably
> be studied, if notifying newbies of new conversations on their watched talk
> pages is beneficial or not.

Sure, as they don't have 3000 pages watchlisted. :-)


>
> As for people like us, it seems there's already an opt-out in the form of
> going to Special:Preferences and turning off "flow" notifications. That
> could be made clearer that that's what it does, though.
>
> I agree that the ability to select specific threads or boards for
> notification without doing it for every watchlisted board/thread would be
> even better. But that seems like a lower priority, since watchlists still
> work.

My point was that, with relatively little more effort, the feature
could be made useful to both newbies and veterans. If the best selling
point that new Flow features can offer to us old editors is that they
can be disabled, that's not going to make us love the project.

I don't mean that old users should be given priority over newcomers,
nor even equal treatment (I know the newbie experience can be
dreadful, and veterans are more resourceful), but our needs should be
heard at least for those workflows that are being replaced or modified
- and a couple of candies thrown here and there would help a lot too
to create good will (see the example of {{Ping}} for a successful
case).

___
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-requ...@lists.wikimedia.org?subject=unsubscribe>

Re: [Wikimedia-l] To Flow or not to Flow

[Diego Moya]

On 10 September 2014 19:52, David Gerard  wrote:
> On 10 September 2014 18:48, Todd Allen  wrote:
>
>> I think that would be very helpful indeed. "This part of the article was
>> most recently discussed under subject "Stop changing the genre". Click here
>> to review or participate in the discussion."
>
> James, this sort of thing will make experienced editors clamour for VE
> ;-) You should be able to do this with the present talk pages -
> annotate VE pages with a link to the discussion.

+1. Yup, that would be a welcome and useful enhancement. Something
similar was suggested at en:Talk:Flow this week, so it may be a great
idea for a future use case in the medium term -  having some feature
that both sides of the fence can agree it's a good thing :-)

___
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, 

Re: [Wikimedia-l] To Flow or not to Flow

[Diego Moya]

Right, it's gone now. However that page survived the attempts of
removal from several administrators who positively wanted to get rid
of any trace of the "Wikipedia:Teahouse/Questions/Flow test" page, so
I don't know what it says about the discoverability of those features
:-/

It's disturbing to think what could have happened, had it been
deployed at large scale with such undesirable interaction undetected.
It may have been a problem of miscommunication and change of the
standard procedure (which the admins tried, but didn't have the
expected result) rather than a lack of features, but we should make
sure that it cannot happen at a wide-scale deployment, and that all
users get informed of how to use the features before giving them
access to the tool or when they try to achieve the result through the
old ways.


On 10 September 2014 19:58, Marc A. Pelletier  wrote:
> On 09/10/2014 01:41 PM, Diego Moya wrote:
>> Take a look at this deleted topic at the test page that was deployed at 
>> en.wiki:
>> https://en.wikipedia.org/wiki/Topic:S214uoczkp47cfsx
>
> As far as I can tell, you could see it because it never /was/ deleted.
> I just deleted it, can you still see it?
>
> I think what you see is the odd interaction with deleting the "page"
> that a flow board lived at -- which may not even be a supported scenario
> (or, at the very least, might need work).
>
> -- Marc
>
>
> ___
> 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-requ...@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-requ...@lists.wikimedia.org?subject=unsubscribe>

Re: [Wikimedia-l] To Flow or not to Flow

[Diego Moya]

On 10 September 2014 19:29, Marc A. Pelletier  wrote:
> On 09/10/2014 01:25 PM, Diego Moya wrote:
>> [...] that allow editors and admins to
>> detect and combat vandalism and remove BLP sensible material and
>> libel; features which are not available in Flow as of today.
>
> That is simply not true, at last as of the master branch.  Topics and
> replies can be hidden, deleted, or suppressed -- the same things that
> can be done to talk page revisions at this moment.


Take a look at this deleted topic at the test page that was deployed at en.wiki:
https://en.wikipedia.org/wiki/Topic:S214uoczkp47cfsx

Can you see its content? I definitely can. Had it contained sensible
information, admins couldn't have done anything to remove it from
sight. (I know this because they've tried):
https://en.wikipedia.org/wiki/Wikipedia_talk:Flow#Deletion_of_Wikipedia:Teahouse.2FQuestions.2FFlow_test



>> Indeed, the Flow equivalent is even superior in at least one aspect:
> given that the actual comments are isolated and not differences between
> revision, supressing a comment containing libel that has gone unnoticed
> for a bit does *not* cause the history of the conversation to be mangled
> because intermediate diffs have to be suppressed as well.
>
> -- Marc

That would be a good thing if it worked. That a feature has been
implemented doesn't mean that it works as intended.

___
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-requ...@lists.wikimedia.org?subject=unsubscribe>

Re: [Wikimedia-l] To Flow or not to Flow

[Diego Moya]

Gerard, please think of the consequences of what you're proposing.
There are features at talk pages (detailed watchlists, incremental
diffs, true deletion of content) that allow editors and admins to
detect and combat vandalism and remove BLP sensible material and
libel; features which are not available in Flow as of today.

Leaving this material unchecked would expose the Foundation to legal
risk. Would you allow that possibility so that editors can edit from
mobile devices? I hope not, but that's exactly what you've suggested.
The "tinkering" is needed so that the core functions are not lost in
the process to deploy nice-to-have features (and yes, mobile editing
is in the "nice to have" category if you compare it to finding and
removing oversightable material of sensible nature).

On 10 September 2014 18:59, Gerard Meijssen  wrote:
> Hoi,
> Ditch talk pages asap. In my opinion tinkering is mostly a waste of effort.
> Thanks,
> GerardM
>

___
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, 

Re: [Wikimedia-l] To Flow or not to Flow

[Diego Moya]

On 10 September 2014 17:47, Martijn Hoekstra
> I think this is something of an oops, and not really something we should
> judge the product on. Currently the broken mess is "notify on all posts on
> all threads on the page", which should be "notify on all posts on the
> subscribed thread, and possible on new threads on the watched page."

The feature shouldn't be "notify on all posts on the subscribed
thread" either. I don't want to be notified every time a new thread
appears at any one of my watched pages. I have about 3000 pages in my
watchlist, and receive around 400 updates daily only from talk pages,
which 50 or so come from unique pages; getting all those as
notifications would render Echo useless to me. Apparently this volume
of data was not taken into account when designing the notification
feature that was rolled out this week, and it is still ignored in the
redesign proposals that I've seen at the various forums.

We have suggested a couple of times at en:Talk:Flow that notifications
should come only from pages/topics/boards where the user has
subscribed to, AND has explicitly enabled notifications, so that only
a subset of preferred pages will alert the user - the rest of
low-importance ones should be actively looked for at the Watchlist.

However, it's hard to tell whether such suggestions ever reach the
development team; it's clear that this one need didn't arrive in time
to be taken into account before the release.


> Everybody acknowledges the former is a mistake and stuff like that can
> happen in testing.

This is not testing, this was rolled out to the production
environment. The release has been interfering with the work of those
editors who happen to have participated in any Flow page. This is more
than an "oops", it's affecting the mission. Why is experimentation
still being released to all editors, instead of limiting it to those
willing to participate in it?

___
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, 

Re: [Wikimedia-l] To Flow or not to Flow

[Diego Moya]

Thanks Erik for your mindful comment. Such high level technical,
social and strategic vision is rare to find. It deserves being placed
in a prominent position for increased visibility, and it helps in
building bridges with the community.

Inter-wiki conversation sounds indeed like a killer feature in
reference to discussion, and you're right that tags would increase the
flexibility for definition of conversation-based workflows by
increasing its granularity.


On 9 September 2014 11:55, David Gerard  wrote:
> (Wiki talk pages don't have a unit really, which is their blessing for
> flexibility and curse for usability.)
>

So much this. Though it doesn't need to be that way; that's not an
essential property of wiki systems, although it may be for Mediawiki.

I've mentioned MS OneNote because it's an example of a full wiki-like
environment where the unit of content is the multimedia element, and
pages work as whiteboards - collages of such media items, that may
include collaborative text and individualized comments, both
attributable to their authors. The tool keeps track of each
independent part an allows them to be merged or split by simple
copy/paste operations, through a clever UI trick that highlights which
part is currently being edited at any time.

Erik, would it be viable to use the Flow architecture to use topic
threads as media elements?, in such way that:
- topics or individual comments can be embedded as items within wiki blackboards
- changes to comments are shown in the history of the blackboard
container (with full diff support for the blackboard as a whole)

If those functions are viable, it would solve most or all of my
"loss-aversion" "spider sense", as it would show a clear path to grow
the platform into a truly flexible tool for collaborative creation,
not just a conversation and community-building system as it seems to
be planned from the information which is available so far.

On 9 September 2014 11:45, Erik Moeller  wrote:
> On Mon, Sep 8, 2014 at 12:22 AM, David Gerard  wrote:
>> On 8 September 2014 05:46, John Mark Vandenberg  wrote:
>> Those of us who presently use talk pages to get the work done. What is
>> going to make us *love* Flow, for all its imperfections, and demand to
>> have it for ourselves? What's Flow's killer feature for us?
>
> First, on the subject of "kiler features", generally - we can make
> educated guesses, but with software that's used by communities, you
> really need to experiment and iterate. I'm sure we'll try stuff in
> Flow that doesn't make sense (and we've already talked here about
> aspects of the current design that may have to be changed, like the
> limited threading display), and I'm sure things we think are minor
> will become more popular than we expect.
>
> Generally, I'm not a big fan of maintaining illusions of certainty.
> I've argued against detailed year-long plans to Sue and the Board, as
> I'm sure they will attest, until we got the flexibility to set more
> malleable goals in engineering. Lila immediately came in with the
> expectation in mind that we'd have precision a quarter out, and broad
> high level ideas a year out, and need flexibility to change our mind
> as we learn. In tech work, you need to be able to double down on
> success when you hit it (make that killer feature _the_ feature), and
> kill the cruft that you thought was smart but that just doesn't work.
>
> With Echo, we included a bunch of notification types and didn't really
> know which ones people would love. We guessed that mentions would
> become popular, but their use has exceeded our wildest expectations.
> Go to any high traffic talk page and you'll see Echo pings all over
> the place. A feature that didn't exist before 2013 and that nobody, as
> far as I know, ever asked for (!) before we built it. And yet it's
> become indispensable.
>
> When we experimented with mobile contributions, our first hypothesis
> was that uploads would be a good start, because mobile isn't
> well-suited for long form edit contributions. In fact, mobile editing
> became wildly popular very quickly and has generally been embraced by
> the community (to the point where people ask us to enable IP editing
> on mobile, which we consciously did not do initially to lessen crappy
> edits), while the signal to noise ratio on uploads has been so poor
> that we're about to retire most upload features until we really can
> spend cycles on mitigating those risks.
>
> So, educated guesses and hypotheses.
>
> Flow makes lots of things possible that are otherwise hard/impossible
> (much better search, tracking of comments, etc.) but my hypothesis is
> that there are three primary killer features that Flow can provide:
>
> 1) Fast interactions. The process of responding on a talk page is
> ridiculously slow (edit section, find place, indent comment, write
> comment, sign comment, preview, save, worry about edit conflict ..).
>
> In my view, the reason people don't value this in Flow such-as-it-is
> al

Re: [Wikimedia-l] To Flow or not to Flow

[Diego Moya]

On 8 September 2014 11:44, Diego Moya  wrote:

> Now if Erik vision for the deeper than I give him credit for,

... that would be: "Now if Erik vision for the Flow platform is deeper
than I give him credit for..."

___
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-requ...@lists.wikimedia.org?subject=unsubscribe>

Re: [Wikimedia-l] To Flow or not to Flow

[Diego Moya]

On 8 September 2014 05:54, Marc A. Pelletier  wrote:
> And yet, after over a decade of open-ended design through social
> convention, the end result is...  our current talk pages.  Perhaps
> another decade or two will be needed before that document-centric
> architecture gives us a half-decent discussion system?

Marc, I'm not arguing against having a discussion system. In fact I
think having threaded comments happen by default is a great idea that
will make the conversation interface far more usable, both on desktop
and mobile (I agree with Gerard that the mobile editing experience is
dreadful).

The problem I see is with having that discussion system as the 'only'
option, making refactoring of conversations limited and difficult, and
removing the open-ended and flexible platform we currently rely upon,
when several important workflows and goals such as accountability and
building new workflows for projects are based on the well understood
capabilities of a wiki system.

The system I envision as a suitable, modern replacement would be based
on proven enterprise collaboration platforms like Microsoft OneNote or
Atlassian Confluence, which include discussion systems as modules
integrated within the platform. I simply can't see the benefit of
losing the collaboration capabilities of wiki software in favor of
enforced structured discussion, when we can have both.

Now if Erik vision for the deeper than I give him credit for, and he
is able to build a OneNote-like application on top of the suggested
architecture for Flow, I will eat my words with an apology :-)
However, that capability of the system should be better explained so
that we can understand it and discuss its ramifications.


On 7 September 2014 23:53, Diego Moya  wrote:
> On 09/06/2014 17:06 PM, Marc A. Pelletier wrote:
>
>>On 09/06/2014 12:34 PM, Isarra Yos wrote:
>>> if the designers do not even understand the basic principles behind a
>>> wiki, how can what is developed possibly suit our needs?
>>
>>You're starting from the presumption that, for some unexplained reason,
>>collaborative discussion benefits from being a wiki (as opposed to, you
>>know, the actual content).
>
> Wikipedia has been built using that platform. I'd say that's a very good
> reason to trust that the model is at least capable. :-)
>
>
>
>>Very many people, myself included, believe that a wiki page is an
>>*atrocious* medium for discussion.
>
> Sure, and I agree there are many way to improve how users are
> engaged into discussion and to keep it manageable. But what is
> missing from this conversation is the point that Wikipedia talk
> space is not *merely* a medium for discussion: there are other vital
> roles that may be hindered by a radical focus on conversation:
>
> tl;dr version:  there are times and places that Wikipedia discussion
> system needs to be a Microsoft OneNote, and Flow is building us
> a Twitter (minus the 140 characters limit).
>
>
> - The talk space has a strong expectation that it serves as an
> archive of all decisions taken in building the articles, i.e. to
> show how the sausages are made. The disembodied nature
> of Flow topics, which may be shown out of order and distributed
> to many boards, makes it hard to recover a sequential view of the
> conversations in order as they happened.
>
> - Same thing for keeping user's behavior in check - policy
> enforcement often requires that the reviewers can see exactly
> what the users saw when they performed some particular
> disruptive action, to assess whether it was made in good faith
> from incomplete information or a misunderstanding.
>
> - Comment-based discussion is not the only way editors collaborate;
> nor discussions are limited to users expressing their particular views
> at ordered, pre-defined processes. Some fellow users have already
> pointed out how the wiki page works as a shared whiteboard where
> semi-structured or free-form content can be worked upon by several
> editors, and improved iteratively in an opportunistic way.
> Sometimes, that re-shaping of text is made onto the
> form of the conversation itself, by re-factoring, splitting, merging
> and re-classifying comments from many editors. This would be
> hard or impossible to do if the layout of the discussion is fixed
> in hardware and comments belong to the poster.
>
> - Wikiprojects develop over time new procedures that better suit
> the workflow of their members to achieve their goals. Their
> project pages are free-form collages of all the relevant information
> they require to do their work, plus discussion processes that may
> involve just its members or any other external participant. As
> projects cover all the aspects of human knowledge, it would be
> diffi

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

[Diego Moya]

On 09/06/2014 17:06 PM, Marc A. Pelletier wrote:

>On 09/06/2014 12:34 PM, Isarra Yos wrote:
>> if the designers do not even understand the basic principles behind a
>> wiki, how can what is developed possibly suit our needs?
>
>You're starting from the presumption that, for some unexplained reason,
>collaborative discussion benefits from being a wiki (as opposed to, you
>know, the actual content).

Wikipedia has been built using that platform. I'd say that's a very good
reason to trust that the model is at least capable. :-)



>Very many people, myself included, believe that a wiki page is an
>*atrocious* medium for discussion.

Sure, and I agree there are many way to improve how users are
engaged into discussion and to keep it manageable. But what is
missing from this conversation is the point that Wikipedia talk
space is not *merely* a medium for discussion: there are other vital
roles that may be hindered by a radical focus on conversation:

tl;dr version:  there are times and places that Wikipedia discussion
system needs to be a Microsoft OneNote, and Flow is building us
a Twitter (minus the 140 characters limit).


- The talk space has a strong expectation that it serves as an
archive of all decisions taken in building the articles, i.e. to
show how the sausages are made. The disembodied nature
of Flow topics, which may be shown out of order and distributed
to many boards, makes it hard to recover a sequential view of the
conversations in order as they happened.

- Same thing for keeping user's behavior in check - policy
enforcement often requires that the reviewers can see exactly
what the users saw when they performed some particular
disruptive action, to assess whether it was made in good faith
from incomplete information or a misunderstanding.

- Comment-based discussion is not the only way editors collaborate;
nor discussions are limited to users expressing their particular views
at ordered, pre-defined processes. Some fellow users have already
pointed out how the wiki page works as a shared whiteboard where
semi-structured or free-form content can be worked upon by several
editors, and improved iteratively in an opportunistic way.
Sometimes, that re-shaping of text is made onto the
form of the conversation itself, by re-factoring, splitting, merging
and re-classifying comments from many editors. This would be
hard or impossible to do if the layout of the discussion is fixed
in hardware and comments belong to the poster.

- Wikiprojects develop over time new procedures that better suit
the workflow of their members to achieve their goals. Their
project pages are free-form collages of all the relevant information
they require to do their work, plus discussion processes that may
involve just its members or any other external participant. As
projects cover all the aspects of human knowledge, it would be
difficult to provide a one-size-fits-all interface that may cover all
their needs - the flexibility to compose new layouts and
compilations of content is core to achieve their goals.

- There's a sense now that the community owns the content of all
pages including talk, and can manage it to their liking. That will
disappear if the base model is changed to one based on user-owned
comments. There has not been enough discussion of how that will
affect all the existing projects and guidelines, or whether such change
is acceptable and beneficial to the goal of writing the encyclopedia.


A wiki-like system is very good at achieving those. Some of these
needs have surfaced at previous discussion at Talk:Flow, and some have
been already addressed or influenced the design, but some others are
squarely opposed to the nature of a threaded discussion where the
structure is enforced by the platform. It would be sensible that the
process to gather feedback from the community includes solid answers
to these facets of the tool.

___
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, 

Re: [Wikimedia-l] To Flow or not to Flow

[Diego Moya]

...and having said and sent that previous post, I want to publicly
apologize for the third paragraph counting from the end. That was uncalled
for.
___
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, 

Re: [Wikimedia-l] To Flow or not to Flow

[Diego Moya]

On 7 September 2014 13:33, Gerard Meijssen 
wrote:

> Get real and look what Flow is and how it can be improved. Check out the
> use cases it works for and acknowledge the achievements. THEN and only THEN
> consider the features that are being tested and are still deficient. THEN
> and only THEN point out how we can move forward and make it work better.
> THEN and only THEN can you lament what we may lose what you liked in Talk
> pages.
>

What makes you think that I have not made all that already? I've been
participating and giving feedback from the very day Flow was announced to
en.wiki, I've filed bugs (the last one today, sending some screenshots to
Erik and he said they're helping him to narrow down the problem with Echo),
I've tested all the releases the day they appeared, I've built mock-ups,
I've suggested and fought for improvements like the table of contents, I
have acknowledged and welcomed the improvements to the usability that Flow
will suppose for newcomers, which is a subject that I care deeply for.

But I've also analyzed the overall direction and found that its basic
approach is limited in scope, treating talk pages as a mere conversation
channel when it fulfills many other roles, and dismissing some fundamental
goals of the talk space that are essential to the mission to build an
encyclopedia, like their role in documenting how articles have been written
and making editors accountable to the world; I've found ways at which the
current design may hurt those goals, but so far has been impossible to get
you to listen.

I *am* trying to point out how we can move forward and make it work better.
I'm trying to reach you because I want Flow to succeed, by pointing out
what I believe by heart to be its deepest flaws so that they can be
corrected, and you think I'm attacking the project.



> However, please consider our need. We are moving more and more towards
> mobile readers and editors and talk pages just do not cut it. We need
> something better for these use cases and, we need them urgently.
>

I have considered those needs, and I've never denied that those are
important goals to fulfill, why would you think I thought otherwise, when
I've never sated such thing? Gerard, do you hate me so much that you put in
my mouth words that I haven't said and assume that I hold positions that
are opposite to what I believe? :'-/

On the other hand, I have requested you to consider our needs, and you have
dismissed them with prejudice. How do you think that treatment will make us
editors feel, and how it will affect the attitude of the community towards
the project?

Please assume good faith and try to listen to what people who care deeply
about the project have to say. I believe that the end result of building an
understanding, from the very different starting points that are held by the
debaters, will benefit the project deeply and will allow for a much more
robust tool that any other way to proceed.
___
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, 

Re: [Wikimedia-l] To Flow or not to Flow

[Diego Moya]

Gerard, with all due respect, your reply is all based on incorrect
assumptions. I recognize the severe problems that mediawiki conversations
currently have, and my points about Flow acknowledge that it's incomplete
software at its early stages and that it can grow into an acceptable tool
for having discussions, but all that is irrelevant to the conversation
that's going on at this thread.

Both Erik and I are talking about what we expect a finished, full featured
software would look like in the end, and we have both dismissed the current
status of either tool. The idea that I want the new system to be based on
current existing software is a strawman; that's not what I defend. I want a
good, modern document-centric software even if it requires building
something like mediawiki from scratch. This is a high level view of what
either model can grow into if enough resources are poured into it.

Erik has this vision that building a stable and easy-to-use system requires
abandoning the open-ended nature of wiki systems, with which I disagree,
and has committed us to a project with that result in the end, to build a
very good architecture that will solve the wrong problem. From the
conversation so far, I believe such view to be based on an incomplete
understanding of the community needs, and I'm trying to steer the
conversation to take into account perspectives from the wider community
rather than the gut feelings of just one man, no matter how much experience
he has with the project.
___
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, 

Re: [Wikimedia-l] To Flow or not to Flow

[Diego Moya]

> These are just assertions, however. I liked your earlier comments
> because they are testable against the architecture (even if the
> current implementation, early as it is, will fail many of these
> tests). What real world needs cannot be met by a comment-centric
> architecture for .. commenting? How important are they?
>

Erik, a major property of a document-centric architecture that is lost in a
structured one is that it's open-ended, which means that end users can
build new features and flows on top of it, without the need to request the
platform developers to build support for them (sometimes even without
writing new software at all; new workflows can be designed and maintained
purely through social convention).

That's not something that's easy to do when the basic raw material for
communication is split into comments and compartmentalized as table records
with different owners. Such change means that a community that now can
handle their own growth is made to utterly depend on the developers as
gatekeepers for its expansion. In a project where the development team is
understaffed, that's not a healthy proposition.

Sure, you have proposed a Workflow management system in the works, but with
all respect that's pie in the sky. That possibility is under-specified,
would require a lot of research and development with unclear goals and
requirements, and there's no guarantee that it would ever be fit for the
purpose. Please understand why we are wary of such proposal as the solution
for all the flexibility requirements.

Sincerely, it looks like you have this grand vision on how a comment
platform should work, and there's this blind spot to it. Despite repeated
attempts by several experienced editors trying to explain to you how this
architectural change would affect the essence of the project smooth
operation and well-being, you dismiss them by focusing on a single feature
at a time and missing the forest for the trees.

The point is not how we could replicate this or that feature on Flow, it's
how we allow support for all future workflows that we don't know about yet,
without requiring that software changes are made to the platform for each
new need. We know that Wiki systems are valid platforms to support such
expansion requirements, because we have seen them working; but we don't
know how the structured architecture will behave, and there's no reason to
believe it would work - no other structured system have achieved anything
similar. You ask "how important are these needs"? I tell you they are
*essential* to the community; the existing encyclopedia couldn't have been
built without this openness.

You asked Todd to make requirements that are testable against the
architecture. Well, I have one: how well does it allow end-users to build
new unforeseen workflows without requiring development of ad-hoc software
and changes to the platform?

I hope you give consideration to this argument before dismissing it as
inconsequential. So far it seems that the decision has already been made
and that your question ("Do we want discussions to occur in document mode, or
in a structured comment mode?") is rhetorical. I hope that this happens not
to be true, and the decision is still open to debate from the community.
___
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,