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

[Gerard Meijssen]

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  wrote:

> 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,
> 
>
___
Wikimedia-l maili

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

[Wil Sinclair]

Tim, do you think that this list of all the useful stuff that talk
pages can currently includes things that aren't being done because
they are too advanced for newbie editors or too inconvenient for
veterans?

Regardless, you make a strong argument for keeping a meta-document
that spans threads and/or should be more persistent. A lot of this
stuff seems indispensable to recording decisions and linking to stuff
that backs them up, avoiding constant rehashing of issues. My concern
is how such a documents could be tied to pertinent threads in the
discussion oriented software. Maybe we could create anchors in such a
document that could make it easier for the right sections to be
displayed alongside threads that reference them in the UI.

I know that LT splits a page and allows for normal editing above it,
but threads aren't well connected to content above them and only get
more disconnected with time as they get pushed down. What if we had
anchors and both the discussion and the meta-document acted like they
are in two horizontal or vertical iframes so we could view them at the
same time (with Javascript mojo we don't need to use iframes anymore,
of course)? The mobile experience could be different, since presumably
there is less real estate than on a desktop.

This is a tricky problem to solve from a UX perspective, but it maybe
Tim's right that we don't necessarily have to compromise flexibility
for structure.

,Wil

On Wed, Sep 10, 2014 at 2:11 PM, Tim Davenport  wrote:
> Having listened for the last week or two, here's what I'm getting as the
> WMF perspective as the three primary things attempting to be remedied with
> Flow:
>
> 1) Newcomers and casual contributors have a very hard time using wiki
> markup language and find it difficult to participate in talk pages. Flow
> will be more intuitive for them.
>
> 2) The rendition of talk page discussion threads on mobile devices is bad.
> With more people using mobile devices and fewer using laptops, this problem
> is only going to become worse over time. Flow will alleviate this problem.
>
> 3) Wikitext becomes a sprawling mess on large talk pages, leading to vast
> walls of tl;dr text a morass of unsearchable archives. Flow will better
> organize discussions.
>
> Is this a fair representation of the rationale behind Flow? Am I missing
> some main (as opposed to utopian and theoretical) rationale for the change?
>
>
> =
>
>
> Now here is a list of the things which talk pages currently do:
>
> 1) Mark articles as significant to various work projects and track the
> content "grade" for each.
>
> 2) Provides details and links for BLP and other policies related to the
> subject.
>
> 3) Records the history of each page with respect to Articles For Deletion
> challenges, Good Article peer review histories, etc.
>
> 4) Maintains a record of actual and potential Conflict of Interest
> declarations.
>
> 5) Registers reader comments about the content.
>
> 6) Provides a forum for editor debates over content, sometimes including
> large blocks of proposed or removed text and including at times binding
> RFCs over content and detailed merger discussions.
>
> 7) Accumulates requested edits for protected articles.
>
>
> In addition, User-talk pages:
>
> 8) Gather warning templates and notification messages about editing
> problems.
>
> 9) Serves as a de facto email system for communication between editors.
>
>
> 
>
> My outside the box suggestion is this: it seems likely that at least some
> of the vital functions of talk pages are going to be crushed by Flow and
> the mass archiving that its adoption will entail. Perhaps it would be
> better for a new third page to be generated for each article:
>
> MAINSPACE PAGE (the article itself)
>
> ABOUT THIS PAGE (templates and permanent records including 1, 2, 3, 4 above)
>
> DISCUSS THIS PAGE (the actual talk page for discussion of content and
> requested edits)
>
>
> Bear in mind that I still have no confidence that Flow will be superior to
> wikitext in any but the most superficial ways. I do suggest, however, that
> some future permutation of this or some other new discussion format has a
> better chance of acceptance by the core volunteer community if it preserves
> many essential functions of talk pages unaltered.
>
>
> Tim Davenport
> "Carrite" on En-WP /// "Randy from Boise" on WPO
> Corvallis, OR  (USA)
> ___
> 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

[Tim Davenport]

Having listened for the last week or two, here's what I'm getting as the
WMF perspective as the three primary things attempting to be remedied with
Flow:

1) Newcomers and casual contributors have a very hard time using wiki
markup language and find it difficult to participate in talk pages. Flow
will be more intuitive for them.

2) The rendition of talk page discussion threads on mobile devices is bad.
With more people using mobile devices and fewer using laptops, this problem
is only going to become worse over time. Flow will alleviate this problem.

3) Wikitext becomes a sprawling mess on large talk pages, leading to vast
walls of tl;dr text a morass of unsearchable archives. Flow will better
organize discussions.

Is this a fair representation of the rationale behind Flow? Am I missing
some main (as opposed to utopian and theoretical) rationale for the change?


=


Now here is a list of the things which talk pages currently do:

1) Mark articles as significant to various work projects and track the
content "grade" for each.

2) Provides details and links for BLP and other policies related to the
subject.

3) Records the history of each page with respect to Articles For Deletion
challenges, Good Article peer review histories, etc.

4) Maintains a record of actual and potential Conflict of Interest
declarations.

5) Registers reader comments about the content.

6) Provides a forum for editor debates over content, sometimes including
large blocks of proposed or removed text and including at times binding
RFCs over content and detailed merger discussions.

7) Accumulates requested edits for protected articles.


In addition, User-talk pages:

8) Gather warning templates and notification messages about editing
problems.

9) Serves as a de facto email system for communication between editors.




My outside the box suggestion is this: it seems likely that at least some
of the vital functions of talk pages are going to be crushed by Flow and
the mass archiving that its adoption will entail. Perhaps it would be
better for a new third page to be generated for each article:

MAINSPACE PAGE (the article itself)

ABOUT THIS PAGE (templates and permanent records including 1, 2, 3, 4 above)

DISCUSS THIS PAGE (the actual talk page for discussion of content and
requested edits)


Bear in mind that I still have no confidence that Flow will be superior to
wikitext in any but the most superficial ways. I do suggest, however, that
some future permutation of this or some other new discussion format has a
better chance of acceptance by the core volunteer community if it preserves
many essential functions of talk pages unaltered.


Tim Davenport
"Carrite" on En-WP /// "Randy from Boise" on WPO
Corvallis, OR  (USA)
___
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

[James Salsman]

Wil Sinclair wrote:
>
> Flow needs a deep and broad community consensus
> to what would probably amount to the biggest single
> change in the history of the project for the day-to-day
> collaboration amongst editors that is so vital to our success.

Wouldn't it be easier to achieve such consensus if there was any
actual evidence that Flow or any other improvement on talk pages would
improve editor engagement? There is an existence proof that tens of
millions of editors have created nearly ten million articles amounting
to dozens of gigabytes of text using talk pages as they have existed
since 2003. Why haven't the Foundation's major engineering changes
ever been made contingent on the existence of conclusive empirical
data about improvements for those editors?

Where are the usability studies to determine whether Flow makes things
easier or more efficient for editors? Are any planned?

Foundation strategy increasingly seems to me like Craigslist if it had
been infiltrated by hundreds of engineers adding add real-time ad
listing updates, black backgrounds for pictures, WYSIWYG ad editing,
and replacing hypertext function links with minimalist icons. Someone
should sneak up on Craig Newmark and make a video recording of his
reaction to suggesting WYSIWYG editing, and play his reaction to
Foundation leadership staff every morning at the start of their work
day.

___
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

[Martijn Hoekstra]

On Wed, Sep 10, 2014 at 10:42 PM, Diego Moya  wrote:

> 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.
>

A single thread is a single topic.


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

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

[Wil Sinclair]

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, 

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, 

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

[Brad Jorsch (Anomie)]

On Wed, Sep 10, 2014 at 1: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. 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.
>

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.

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

___
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

[Wil Sinclair]

 On Wed, Sep 10, 2014 at 7:54 PM, Gerard Meijssen 
> wrote:
>
>> Hoi,
>> Asap stands for "as soon as possible". It is obvious that there I do not
>> like the talk pages at all. That does not mean that it makes sense to
>> replace them tomorrow.
>>
>> 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. 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.
>>
>> 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.
>> Thanks,
>>  GerardM
>>
>
> Gerard,
>
> It would really help me if you would go a little lower on the hyperbole. As
> soon as possible is indeed not tomorrow. It's today. Only we both agree
> that would be a very bad idea. What you probably mean is "As soon as a
> reasonable replacement for processes and talk pages can be found" - but
> when I phrase it like that, it becomes open for discussion what that
> reasonable replacement could be. It makes it very hard to keep taking your
> posts seriously if you keep speaking in such hyperbole.
>
> --Martijn

I've got to +1 Martijn on this one. But I'm a little more concerned
with "cut the crap," because "the crap" could easily be interpreted as
other people's ideas. While this kind of language is rather mild
compared to some other posts I've seen to this list, I think that it
is imperative that we all stay constructive and open to each other's
ideas when we talk about Flow. Flow needs a deep and broad community
consensus to what would probably amount to the biggest single change
in the history of the project for the day-to-day collaboration amongst
editors that is so vital to our success. Let's face it, the kind of
challenge ahead is something this community hasn't surmounted in the
last few years, and so far people on this list has done a great job
staying constructive in the discussion.

I want discussion oriented software to happen. Gerard, your messages
have great substance that can get us closer to our goal. Please don't
push it out of reach because of something as easy to change as style.
Thanks in advance for considering the rest of us who'd like to see
this happen in your posts.

And thanks for the forbearance of everyone else. The sooner
meta-discussions about the nature of our discourse are unnecessary,
the happier I'll be, as I'll feel like I can afford to spend all of my
post allowance on the actual substance of the issues.

,Wil

___
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

[Michael Peel]

On 8 Sep 2014, at 08:22, David Gerard  wrote:

> On 8 September 2014 05:46, John Mark Vandenberg  wrote:
> 
>> If it is good
>> software, the projects will *ask* for it to be deployed, like they did
>> with LiquidThreads, and users will want to use it on their user talk
>> even if the wider community isnt ready to migrate.
> 
> 
> This is the key point.
> 
> 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?

This really is the critical point.

If the WMF is developing new software that the community gets behind and 
explicitly asks to be deployed, then it’s doing the right thing.

If it’s having to force new software on the community against its objections, 
then it’s shooting itself in the foot.

Thanks,
Mike


___
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

[James Forrester]

On 10 September 2014 11:01, David Gerard  wrote:

> On 10 September 2014 18:59, James Forrester 
> wrote:
>
> > Eh. I'm not particularly interested in building features that only work
> in
> > VE and not wikitext, and particularly not in ones that would require
> > changing both the wikitext used to write talk pages for the benefit of VE
> > users and disrupting wikitext. We can, and we must, do better than that.
> > (But yes, I imagine the additional ease of VE here would be significant.)
>
> Yeah, special markup in this case is an annoyance. I'm picturing n00bs
> using the VE (newbies I throw at the VE *love* it *so much* ... I need
> to try them on adding a reference) and going "... ah. There's
> discussion on this point."
>

​Indeed, one of the uses of this model of content-centred-discussion
combined with real-time collaborative editing that we're going to add to
VisualEditor eventually, could be letting newbies call out for help​
mid-edit and admins/helpers/etc. could swoop in and show them how to add a
reference; at the end of the edit, these discussions could get archived or
just thrown away, depending on what works.

But now I'm just selling products we haven't built yet, which is a bit
unfair. :-)

J.
-- 
James D. Forrester
Product Manager, Editing
Wikimedia Foundation, Inc.

jforres...@wikimedia.org | @jdforrester
___
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

[David Gerard]

On 10 September 2014 18:59, James Forrester  wrote:

> Eh. I'm not particularly interested in building features that only work in
> VE and not wikitext, and particularly not in ones that would require
> changing both the wikitext used to write talk pages for the benefit of VE
> users and disrupting wikitext. We can, and we must, do better than that.
> (But yes, I imagine the additional ease of VE here would be significant.)



Yeah, special markup in this case is an annoyance. I'm picturing n00bs
using the VE (newbies I throw at the VE *love* it *so much* ... I need
to try them on adding a reference) and going "... ah. There's
discussion on this point."


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

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

[David Gerard]

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, 

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

[Martijn Hoekstra]

On Wed, Sep 10, 2014 at 7:54 PM, Gerard Meijssen 
wrote:

> Hoi,
> Asap stands for "as soon as possible". It is obvious that there I do not
> like the talk pages at all. That does not mean that it makes sense to
> replace them tomorrow.
>
> 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. 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.
>
> 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.
> Thanks,
>  GerardM
>

Gerard,

It would really help me if you would go a little lower on the hyperbole. As
soon as possible is indeed not tomorrow. It's today. Only we both agree
that would be a very bad idea. What you probably mean is "As soon as a
reasonable replacement for processes and talk pages can be found" - but
when I phrase it like that, it becomes open for discussion what that
reasonable replacement could be. It makes it very hard to keep taking your
posts seriously if you keep speaking in such hyperbole.

--Martijn


> On 10 September 2014 19:25, Diego Moya  wrote:
>
> > 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,
> > 
> >
> ___
> 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

[James Forrester]

On 10 September 2014 10: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."
>
> This being Wikipedia, we need to think about when someone
> well-meaningly takes this new process way, way too far. And how to
> mitigate that ahead of time. But, yeah, this is what appeals to me
> about it.
>
> 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.
>

​Eh. I'm not particularly interested in building features that only work in
VE and not wikitext, and particularly not in ones that would require
changing both the wikitext used to write talk pages for the benefit of VE
users and disrupting wikitext. We can, and we must, do better than that.

(But yes, I imagine the additional ease of VE here would be significant.)

J.
-- 
James D. Forrester
Product Manager, Editing
Wikimedia Foundation, Inc.

jforres...@wikimedia.org | @jdforrester
___
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

[Marc A. Pelletier]

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, 

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

[Gerard Meijssen]

Hoi,
Asap stands for "as soon as possible". It is obvious that there I do not
like the talk pages at all. That does not mean that it makes sense to
replace them tomorrow.

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. 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.

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.
Thanks,
 GerardM

On 10 September 2014 19:25, Diego Moya  wrote:

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

[David Gerard]

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."



This being Wikipedia, we need to think about when someone
well-meaningly takes this new process way, way too far. And how to
mitigate that ahead of time. But, yeah, this is what appeals to me
about it.

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.


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

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

[Martijn Hoekstra]

On Wed, Sep 10, 2014 at 7:17 PM, Diego Moya  wrote:

> 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.


Hence the "on the subscribed thread" not "on any thread on the
board/watched page"


> 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?


>
>
> > 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)


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

[Todd Allen]

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."
On Sep 10, 2014 11:38 AM, "James Forrester" 
wrote:

> On 10 September 2014 04:58, David Gerard  wrote:
>
> > On 10 September 2014 12:54, Andrew Gray 
> wrote:
> >
> > > * inter-wiki or intra-wiki integration of multiple-venue discussions
> > > rather than several parallel pages and potentially parallel
> > > discussions (not a very frequent issue, but a messy one when needed;
> > > Pine notes this below)
> >
> > Yeah, that's getting into the "solves a problem I have" area I was
> > thinking of.
> >
> > A few more of these and experienced users will be demanding Flow.
> >
>
> ​[Talking well into the future, and free-lancing a little in Danny's area;
> please do not expect this soon.]​
>
> ​One of the pain points about our treatment of content vs. discussion right
> now is how to expose to casual editors of a page that discussion is
> on-going about a particular aspect of an article, or that there has been a
> lot of argument about an aspect of the page and that this is now 'settled'
> – not that it can't be changed, but that editors may wish to consider
> before blindly changing something.
>
> These discussions can range from the very specific (what exact term /
> wording should we use here?) to the very general (we should take care to
> use photos of the concept from all 'sides' of the debate). Most often
> they're about a small chunk of content and proposals to alter, expand or
> remove it. Indeed, the need to comment on these is flagged quite often when
> talking about Flow – generally in terms of "we need to copy content into
> the discussion and back out again", which I think is a solution rather than
> the core problem we're trying to address, framed by our current way of
> treating discussions.
>
> Normally these discussions, and their total lack of visibility to all but a
> handful of editors who read the talk page and all its archives before they
> make each edit, aren't a problem. It's rare that a page has issues, after
> all, and very often "common sense" gets you most of the way there, so even
> without knowing about prior discussion your edits can be uncontroversial.
>
> Sometimes we make edits against these agreed points, and someone previously
> involved in the discussion notices and undoes the change (or "fixes" it or
> whatever), and might drop a note on their talk page to that effect. This is
> effective for very highly-watched pages, but adds a lot of burden to people
> to monitor their watchlists' articles for changes against their hazy
> memories of what has and hasn't been discussed. Certainly, editor working
> on recent changes patrolling won't know the particulars of each article and
> the local discussions that have been had.
>
> Occasionally, we use HTML comments to shout at potential editors ("Do NOT
> change his race!" on Barack Obama's article on the English Wikipedia, for
> instance). These are confusing to newbies (it's a magic fragile syntax
> that's uncommon), don't always 'work' (lots of people tune out whacky
> syntax they don't know), and very rarely give an indication as to /why/
> some user posted that instruction, when this dates from and whether it's
> still current, or if it actually has consensus.
>
> To make it easier for editors, we could provide a way to attach discussions
> not just to an article (Talk:Foo is stuff about "Foo") but as well to a
> particular item inside Foo – a section, a paragraph, a template, a
> reference, an image. When you edit, we could show somehow discussions
> attached to that item.
>
> There have been proposals to use a right-hand bar to show information
> relevant to the content in view ("see related Wikidata item"; "articles on
> this subject in other languages use these images"; etc.); that could be a
> neat place to put relevant discussions' subjects/titles (or even the whole
> discussion). Alternatively, we could put little markers in a tray/gutter
> that users can click on to see more of, or put a highlighted ring around
> content subject to recent discussion when editors change it. There are lots
> of ways we could consider making a more powerful, more visible way to
> discuss content.
>
> Making these kind of tool available through VisualEditor would be pretty
> easy (though getting the design right for all our workflows would need some
> care, and as always the challenges of getting a reasonable, consistent
> design for phone, tablet and desktop platforms will need some thought).
> Doing it in the wikitext editor in a way that makes sense for users might
> be harder. However, "hard" is not a good enough excuse for us not tackling
> these kinds of big issues around making editing a simpler, more obvious
> experience that doesn't need people to have read the talk page and all its
> archives before making an edit.
>
> Does that sound like 

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

[David Gerard]

On 10 September 2014 18:37, James Forrester  wrote:

> There have been proposals to use a right-hand bar to show information
> relevant to the content in view ("see related Wikidata item"; "articles on
> this subject in other languages use these images"; etc.); that could be a
> neat place to put relevant discussions' subjects/titles (or even the whole
> discussion). Alternatively, we could put little markers in a tray/gutter
> that users can click on to see more of, or put a highlighted ring around
> content subject to recent discussion when editors change it. There are lots
> of ways we could consider making a more powerful, more visible way to
> discuss content.
> Making these kind of tool available through VisualEditor would be pretty
> easy (though getting the design right for all our workflows would need some
> care, and as always the challenges of getting a reasonable, consistent
> design for phone, tablet and desktop platforms will need some thought).
> Doing it in the wikitext editor in a way that makes sense for users might
> be harder. However, "hard" is not a good enough excuse for us not tackling
> these kinds of big issues around making editing a simpler, more obvious
> experience that doesn't need people to have read the talk page and all its
> archives before making an edit.
> Does that sound like a useful change for experience editors? :-)



Yes, I like that a lot - the idea of "well, you hit edit. There's a
discussion about *this* point *here* that you should probably read and
argue in."


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

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, 

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

[James Forrester]

On 10 September 2014 04:58, David Gerard  wrote:

> On 10 September 2014 12:54, Andrew Gray  wrote:
>
> > * inter-wiki or intra-wiki integration of multiple-venue discussions
> > rather than several parallel pages and potentially parallel
> > discussions (not a very frequent issue, but a messy one when needed;
> > Pine notes this below)
>
> Yeah, that's getting into the "solves a problem I have" area I was
> thinking of.
>
> A few more of these and experienced users will be demanding Flow.
>

​[Talking well into the future, and free-lancing a little in Danny's area;
please do not expect this soon.]​

​One of the pain points about our treatment of content vs. discussion right
now is how to expose to casual editors of a page that discussion is
on-going about a particular aspect of an article, or that there has been a
lot of argument about an aspect of the page and that this is now 'settled'
– not that it can't be changed, but that editors may wish to consider
before blindly changing something.

These discussions can range from the very specific (what exact term /
wording should we use here?) to the very general (we should take care to
use photos of the concept from all 'sides' of the debate). Most often
they're about a small chunk of content and proposals to alter, expand or
remove it. Indeed, the need to comment on these is flagged quite often when
talking about Flow – generally in terms of "we need to copy content into
the discussion and back out again", which I think is a solution rather than
the core problem we're trying to address, framed by our current way of
treating discussions.

Normally these discussions, and their total lack of visibility to all but a
handful of editors who read the talk page and all its archives before they
make each edit, aren't a problem. It's rare that a page has issues, after
all, and very often "common sense" gets you most of the way there, so even
without knowing about prior discussion your edits can be uncontroversial.

Sometimes we make edits against these agreed points, and someone previously
involved in the discussion notices and undoes the change (or "fixes" it or
whatever), and might drop a note on their talk page to that effect. This is
effective for very highly-watched pages, but adds a lot of burden to people
to monitor their watchlists' articles for changes against their hazy
memories of what has and hasn't been discussed. Certainly, editor working
on recent changes patrolling won't know the particulars of each article and
the local discussions that have been had.

Occasionally, we use HTML comments to shout at potential editors ("Do NOT
change his race!" on Barack Obama's article on the English Wikipedia, for
instance). These are confusing to newbies (it's a magic fragile syntax
that's uncommon), don't always 'work' (lots of people tune out whacky
syntax they don't know), and very rarely give an indication as to /why/
some user posted that instruction, when this dates from and whether it's
still current, or if it actually has consensus.

To make it easier for editors, we could provide a way to attach discussions
not just to an article (Talk:Foo is stuff about "Foo") but as well to a
particular item inside Foo – a section, a paragraph, a template, a
reference, an image. When you edit, we could show somehow discussions
attached to that item.

There have been proposals to use a right-hand bar to show information
relevant to the content in view ("see related Wikidata item"; "articles on
this subject in other languages use these images"; etc.); that could be a
neat place to put relevant discussions' subjects/titles (or even the whole
discussion). Alternatively, we could put little markers in a tray/gutter
that users can click on to see more of, or put a highlighted ring around
content subject to recent discussion when editors change it. There are lots
of ways we could consider making a more powerful, more visible way to
discuss content.

Making these kind of tool available through VisualEditor would be pretty
easy (though getting the design right for all our workflows would need some
care, and as always the challenges of getting a reasonable, consistent
design for phone, tablet and desktop platforms will need some thought).
Doing it in the wikitext editor in a way that makes sense for users might
be harder. However, "hard" is not a good enough excuse for us not tackling
these kinds of big issues around making editing a simpler, more obvious
experience that doesn't need people to have read the talk page and all its
archives before making an edit.

Does that sound like a useful change for experience editors? :-)

​J.
-- 
James D. Forrester
Product Manager, Editing
Wikimedia Foundation, Inc.

jforres...@wikimedia.org | @jdforrester
___
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/wikime

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

[David Gerard]

On 10 September 2014 18:29, Marc A. Pelletier  wrote:

> 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.



That's a second "useful to experienced regulars" feature. I recommend
keeping a list :-)


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

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

[Marc A. Pelletier]

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.

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


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

[Gerard Meijssen]

Hoi,
Ditch talk pages asap. In my opinion tinkering is mostly a waste of effort.
Thanks,
GerardM

On 10 September 2014 17:45, MF-Warburg  wrote:

> Am 10.09.2014 09:56 schrieb "Gerard Meijssen" :
> >
> > Hoi,
> > I expected that it was obvious... Arguments that are based on desktop
> > experiences are futile because  the desktop experience is the lesser of
> two
> > evils. The desktop experience is already bad, the experience on mobiles
> and
> > tablets is much worse it is intolerably unusable,
> >
> > Yes, you are overlooking stuff when you only consider inserting an
> isolated
> > comment that may help. That is not the only problem and not even the main
> > problem. Reading and analysing talk pages is already next to impossible
> in
> > this environment therefore inserting an isolated comment does not help
> > enough to make the experience at least bearable.
> > Thanks,
> >   GerardM
>
> What do you propose to make talk pages easier to read and analyse?
>
> >
> > On 10 September 2014 09:47, Martijn Hoekstra 
> > wrote:
> >
> > > On Sep 10, 2014 9:35 AM, "Gerard Meijssen" 
> > > wrote:
> > > >
> > > > Hoi.
> > > > When you look at talk pages in isolation, you look at them on a
> computer
> > > > screen. A mobile or tablet screen is increasingly not used in
> isolation.
> > >
> > > I'm not sure what you mean by this.
> > >
> > > It
> > > > is where we find our new users and editors. We cannot afford to
> ignore
> > > > them; they are our future. This is why tinkering with talk pages is
> not
> > > an
> > > > option. Moving away from talk pages because of mobiles and tablets is
> the
> > > > killer reason why we need to move away from talk pages.
> > > >
> > > > It is a killer reason because it makes all arguments to the contrary
> pale
> > > > away.
> > > > Thanks,
> > > >  GerardM
> > >
> > > What I find most painful about talk pages on mobile (on the desktop
> skin,
> > > because so far I've been too impatient to find talk pages and edit
> > > functionality on mobile) have been that editing huge text areas really
> > > sucks (the scrolling and positioning the cursor is a huge pain). This
> is
> > > not limited to talk pages by the way, but is identical for mainspace
> pages.
> > >
> > > A reply button that inserts an isolated comment at the correct
> indentation
> > > level would fix that. Am I overlooking stuff?
> > > >
> > > > On 10 September 2014 09:20, Martijn Hoekstra <
> martijnhoeks...@gmail.com>
> > > > wrote:
> > > >
> > > > > On Sep 10, 2014 5:11 AM, "Keegan Peterzell"  >
> > > wrote:
> > > > > >
> > > > > > On Tue, Sep 9, 2014 at 10:04 AM, Wil Sinclair 
> wrote:
> > > > > >
> > > > > > >
> > > > > > > FWIW, I signed my first comment by hand. I missed the comments
> > > about
> > > > > > > sigs in the wikitext editor interface. If it weren't for my
> family
> > > > > > > situation, I'm pretty sure I would have bailed. In any case, it
> was
> > > > > > > much easier to engage at WO, and that was partly- but not
> mostly-
> > > due
> > > > > > > to the fact that they run discussion software over there.
> > > > > > >
> > > > > > > ,Wil
> > > > > > >
> > > > > > >
> > > > > > ​This - signing by hand - is pretty much a universal experience
> for
> > > new
> > > > > > users, myself included.
> > > > > >
> > > > > >
> > > > >
> > > > >
> > >
> > >
>
> https://en.wikipedia.org/w/index.php?title=Talk:History_of_Alaska&diff=prev&oldid=26555079
> > > > > > ​
> > > > > >
> > > > > >
> > > > > > --
> > > > > > ~Keegan
> > > > > >
> > > > > > https://en.wikipedia.org/wiki/User:Keegan
> > > > >
> > > > > I'm not saying that isn't crap and unwelcoming: it is, and it
> deters
> > > new
> > > > > users. But it's hardly the end of the world either. By signing the
> > > wrong
> > > > > way no real harm is done, if someone just tells you about the
> option to
> > > use
> > > > > 
> > > > >
> > > > > It's crap and archaic and should be fixed, but it's also an example
> of
> > > the
> > > > > idea that there are no mistakes on a wiki. So you did something not
> > > right?
> > > > > Great, that means you contributed. So we fix it (collaboratively)
> and
> > > > > improve your contribution, no harm done.
> > > > >
> > > > > That said, auto sign and a reply button would be a *whole* lot
> > > friendlier
> > > > > than what we have now, and would be great improvements over the
> current
> > > > > situation.
> > > > >
> > > > > Flow definitely has a reply button, and automatic signing as well,
> but
> > > I
> > > > > can't help but think that just those features in isolation would be
> > > better
> > > > > then completely overhauling talk pages.
> > > > >
> > > > > --Martijn
> > > > >
> > > > > >
> > > > > > This is my personal email address. Everything sent from this
> email
> > > > > address
> > > > > > is in a personal capacity.
> > > > > > ___
> > > > > > Wikimedia-l mailing list, guidelines at:
> > > > > https://meta.wikimedia.org/wiki/Mailing_lists/Guideli

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

[David Gerard]

On 10 September 2014 17:29, Marc A. Pelletier  wrote:

> Clearly, text discussion with people on phones is a known use case - and
> arguably the primary use of those things nowadays - so it's not like
> we're blazing new trails there.  Editing /documents/ is a different
> beast altogether and waiting to solve that to fix discussions is, IMO,
> putting the cart before the horses.


Big fingers, small phone :-) Yeah, less punctuation will help.


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

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

[Marc A. Pelletier]

On 09/10/2014 11:53 AM, David Gerard wrote:
> Making entering text on a phone a process not made entirely of pain
> will be interesting.

I don't think it's the text proper that's the issue so much as the
navigation and (often) markup that uses a great deal of punctuation that
phone interfaces were really not meant to make easy to use.

Clearly, text discussion with people on phones is a known use case - and
arguably the primary use of those things nowadays - so it's not like
we're blazing new trails there.  Editing /documents/ is a different
beast altogether and waiting to solve that to fix discussions is, IMO,
putting the cart before the horses.

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

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

[David Gerard]

On 10 September 2014 16:48, Marc A. Pelletier  wrote:
> On 09/10/2014 11:45 AM, MF-Warburg wrote:

>> What do you propose to make talk pages easier to read and analyse?

> That's a hard question, and I expect one where a lot of UX
> experimentation will need to take place before we know.
> But one thing /is/ known: it's going to be feasible iff the data is
> actually structured like a discussion; not a flat document that may or
> may not be perhaps parsable as something vaguely discussion-like.


Making entering text on a phone a process not made entirely of pain
will be interesting.


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

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

[Marc A. Pelletier]

On 09/10/2014 11:45 AM, MF-Warburg wrote:
> What do you propose to make talk pages easier to read and analyse?

That's a hard question, and I expect one where a lot of UX
experimentation will need to take place before we know.

But one thing /is/ known: it's going to be feasible iff the data is
actually structured like a discussion; not a flat document that may or
may not be perhaps parsable as something vaguely discussion-like.

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

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

[Martijn Hoekstra]

On Wed, Sep 10, 2014 at 2:42 PM, Risker  wrote:

> On 10 September 2014 07:54, Andrew Gray  wrote:
>
> > On 8 September 2014 08:22, David Gerard  wrote:
> > 
>
>
>
> >
> > * potential to work with Notifications ("tell me when anyone replies
> > to this discussion") without needing individual pings or relying on
> > spotting one talkpage edit in a busy watchlist - especially since on
> > some pages a comment may come two years later.
> >
> >
>
> You know, Andrew, this was always something that I thought would be one of
> the real features of Flow, one of the things that could pull people over to
> supporting the transition.  Until it got turned it on.
>
> I have 'watch-listed' the Flow-specific pages on Mediawikiwiki (MWW) and
> English Wikipedia for a very long time.  When they turned on notifications
> at MWW about a week ago, my mailbox and notifications were flooded - I'm
> not talking just a little bit, I mean I got so many notifications that I
> couldn't sort out the ones that weren't related to that one specific Flow
> page - and that was with a single Flow stream being watched.  I suppose I
> expected it to be like the email notices we get when a watched page gets
> edited on non-Wikipedia projects (e.g., Meta, MWW) - that is, the first
> change would generate an email/notification and nothing more until I went
> to the "page" itself.  From what I've been told, this isn't something that
> Echo/notifications does or was meant to do.
>
> I know the Flow team is scrambling to try to reduce the overwhelming nature
> of the notifications.  But it occurs to me that there was a reason why
> "email notification" was never turned on for Wikipedia projects - the sheer
> volume of messages that would be generated for users with hundreds or
> thousands of pages on their watchlists - and that's going to be just as
> much an issue for Flow as it would be if we just turned on those email
> messages today.  Looks brilliant on paper, but reality is a different
> thing.
>
> Risker/Anne
>

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."
Everybody acknowledges the former is a mistake and stuff like that can
happen in testing.

--Martijn

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

[MF-Warburg]

Am 10.09.2014 09:56 schrieb "Gerard Meijssen" :
>
> Hoi,
> I expected that it was obvious... Arguments that are based on desktop
> experiences are futile because  the desktop experience is the lesser of
two
> evils. The desktop experience is already bad, the experience on mobiles
and
> tablets is much worse it is intolerably unusable,
>
> Yes, you are overlooking stuff when you only consider inserting an
isolated
> comment that may help. That is not the only problem and not even the main
> problem. Reading and analysing talk pages is already next to impossible in
> this environment therefore inserting an isolated comment does not help
> enough to make the experience at least bearable.
> Thanks,
>   GerardM

What do you propose to make talk pages easier to read and analyse?

>
> On 10 September 2014 09:47, Martijn Hoekstra 
> wrote:
>
> > On Sep 10, 2014 9:35 AM, "Gerard Meijssen" 
> > wrote:
> > >
> > > Hoi.
> > > When you look at talk pages in isolation, you look at them on a
computer
> > > screen. A mobile or tablet screen is increasingly not used in
isolation.
> >
> > I'm not sure what you mean by this.
> >
> > It
> > > is where we find our new users and editors. We cannot afford to ignore
> > > them; they are our future. This is why tinkering with talk pages is
not
> > an
> > > option. Moving away from talk pages because of mobiles and tablets is
the
> > > killer reason why we need to move away from talk pages.
> > >
> > > It is a killer reason because it makes all arguments to the contrary
pale
> > > away.
> > > Thanks,
> > >  GerardM
> >
> > What I find most painful about talk pages on mobile (on the desktop
skin,
> > because so far I've been too impatient to find talk pages and edit
> > functionality on mobile) have been that editing huge text areas really
> > sucks (the scrolling and positioning the cursor is a huge pain). This is
> > not limited to talk pages by the way, but is identical for mainspace
pages.
> >
> > A reply button that inserts an isolated comment at the correct
indentation
> > level would fix that. Am I overlooking stuff?
> > >
> > > On 10 September 2014 09:20, Martijn Hoekstra <
martijnhoeks...@gmail.com>
> > > wrote:
> > >
> > > > On Sep 10, 2014 5:11 AM, "Keegan Peterzell" 
> > wrote:
> > > > >
> > > > > On Tue, Sep 9, 2014 at 10:04 AM, Wil Sinclair 
wrote:
> > > > >
> > > > > >
> > > > > > FWIW, I signed my first comment by hand. I missed the comments
> > about
> > > > > > sigs in the wikitext editor interface. If it weren't for my
family
> > > > > > situation, I'm pretty sure I would have bailed. In any case, it
was
> > > > > > much easier to engage at WO, and that was partly- but not
mostly-
> > due
> > > > > > to the fact that they run discussion software over there.
> > > > > >
> > > > > > ,Wil
> > > > > >
> > > > > >
> > > > > ​This - signing by hand - is pretty much a universal experience
for
> > new
> > > > > users, myself included.
> > > > >
> > > > >
> > > >
> > > >
> >
> >
https://en.wikipedia.org/w/index.php?title=Talk:History_of_Alaska&diff=prev&oldid=26555079
> > > > > ​
> > > > >
> > > > >
> > > > > --
> > > > > ~Keegan
> > > > >
> > > > > https://en.wikipedia.org/wiki/User:Keegan
> > > >
> > > > I'm not saying that isn't crap and unwelcoming: it is, and it deters
> > new
> > > > users. But it's hardly the end of the world either. By signing the
> > wrong
> > > > way no real harm is done, if someone just tells you about the
option to
> > use
> > > > 
> > > >
> > > > It's crap and archaic and should be fixed, but it's also an example
of
> > the
> > > > idea that there are no mistakes on a wiki. So you did something not
> > right?
> > > > Great, that means you contributed. So we fix it (collaboratively)
and
> > > > improve your contribution, no harm done.
> > > >
> > > > That said, auto sign and a reply button would be a *whole* lot
> > friendlier
> > > > than what we have now, and would be great improvements over the
current
> > > > situation.
> > > >
> > > > Flow definitely has a reply button, and automatic signing as well,
but
> > I
> > > > can't help but think that just those features in isolation would be
> > better
> > > > then completely overhauling talk pages.
> > > >
> > > > --Martijn
> > > >
> > > > >
> > > > > This is my personal email address. Everything sent from this email
> > > > address
> > > > > is in a personal capacity.
> > > > > ___
> > > > > 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.wik

Re: [Wikimedia-l] Access by Wikimedia volunteers to WMF records about them

[Luis Villa]

On Wed, Sep 10, 2014 at 12:27 AM, Fæ  wrote:

> Should WMF Legal say they are happy for me to do so, I will be happy
> to publish their reply in full.
>

Our reply, as I sent it at 7:58 pm Pacific time, Sep. 9:

===
Hi, Ashley-

As you know, the Wikimedia Foundation keeps very little data about users.
Most information that we have is public and accessible on-wiki, like user
pages and contribution pages.  For the small amount of personally
identifiable data that we do collect, we also seek to comply with our data
retention guidelines
, deleting
information after prescribed periods.

Given our small administrative staff, the lack of any mandate under the
relevant applicable law, and the need to focus our limited resources on our
mission, we do not think it is an appropriate use of staff time or donor
money to do significant research in locating and preparing information, if
any, that falls under your broadly scoped request. We appreciate your
understanding.

Sincerely-
Luis
===


-- 
Luis Villa
Deputy General Counsel
Wikimedia Foundation
415.839.6885 ext. 6810

*This message may be confidential or legally privileged. If you have
received it by accident, please delete it and let us know about the
mistake. As an attorney for the Wikimedia Foundation, for legal/ethical
reasons I cannot give legal advice to, or serve as a lawyer for, community
members, volunteers, or staff members in their personal capacity. For more
on what this means, please see our legal disclaimer
.*
___
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

[Risker]

On 10 September 2014 07:54, Andrew Gray  wrote:

> On 8 September 2014 08:22, David Gerard  wrote:
> 



>
> * potential to work with Notifications ("tell me when anyone replies
> to this discussion") without needing individual pings or relying on
> spotting one talkpage edit in a busy watchlist - especially since on
> some pages a comment may come two years later.
>
>

You know, Andrew, this was always something that I thought would be one of
the real features of Flow, one of the things that could pull people over to
supporting the transition.  Until it got turned it on.

I have 'watch-listed' the Flow-specific pages on Mediawikiwiki (MWW) and
English Wikipedia for a very long time.  When they turned on notifications
at MWW about a week ago, my mailbox and notifications were flooded - I'm
not talking just a little bit, I mean I got so many notifications that I
couldn't sort out the ones that weren't related to that one specific Flow
page - and that was with a single Flow stream being watched.  I suppose I
expected it to be like the email notices we get when a watched page gets
edited on non-Wikipedia projects (e.g., Meta, MWW) - that is, the first
change would generate an email/notification and nothing more until I went
to the "page" itself.  From what I've been told, this isn't something that
Echo/notifications does or was meant to do.

I know the Flow team is scrambling to try to reduce the overwhelming nature
of the notifications.  But it occurs to me that there was a reason why
"email notification" was never turned on for Wikipedia projects - the sheer
volume of messages that would be generated for users with hundreds or
thousands of pages on their watchlists - and that's going to be just as
much an issue for Flow as it would be if we just turned on those email
messages today.  Looks brilliant on paper, but reality is a different
thing.

Risker/Anne
___
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

[David Gerard]

On 10 September 2014 12:54, Andrew Gray  wrote:

> * inter-wiki or intra-wiki integration of multiple-venue discussions
> rather than several parallel pages and potentially parallel
> discussions (not a very frequent issue, but a messy one when needed;
> Pine notes this below)


Yeah, that's getting into the "solves a problem I have" area I was thinking of.

A few more of these and experienced users will be demanding Flow.


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

Re: [Wikimedia-l] wikipedia access traces ?

[Pine W]

Hi Valerio,

This kind of request is a better fit for the Research mailing list. I've
included the email for that list in the To: line of this email reply.

Pine

On Wed, Sep 10, 2014 at 4:15 AM, Valerio Schiavoni <
valerio.schiav...@gmail.com> wrote:

> Dear WikiMedia foundation,
> in the context of a EU research project [1], we are interested in accessing
> wikipedia access traces.
> In the past, such traces were given for research purposes to other groups
> [2].
> Unfortunately, only a small percentage (10%) of that trace has been made
> made available (10%).
> We are interested in accessing the totality of that same trace (or even
> better, a more recent one, but the same one will do).
>
> If this is not the correct ML to use for such requests, could please anyone
> redirect me to correct one ?
>
> Thanks again for your attention,
>
> Valerio Schiavoni
> Post-Doc Researcher
> University of Neuchatel, Switzerland
>
>
> 1 - http://www.leads-project.eu
> 2 - http://www.wikibench.eu/?page_id=60
> ___
> 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

[Andrew Gray]

On 8 September 2014 08:22, David Gerard  wrote:
> On 8 September 2014 05:46, John Mark Vandenberg  wrote:
>
>> If it is good
>> software, the projects will *ask* for it to be deployed, like they did
>> with LiquidThreads, and users will want to use it on their user talk
>> even if the wider community isnt ready to migrate.
>
>
> This is the key point.
>
> 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?
>
> (I asked this before.)

When I sat in on a talk about Flow at Wikimania a year or so ago, the
two that made me sit bolt upright as things we can't easily do with
wikitext:

* potential to work with Notifications ("tell me when anyone replies
to this discussion") without needing individual pings or relying on
spotting one talkpage edit in a busy watchlist - especially since on
some pages a comment may come two years later.

* inter-wiki or intra-wiki integration of multiple-venue discussions
rather than several parallel pages and potentially parallel
discussions (not a very frequent issue, but a messy one when needed;
Pine notes this below)

The more nebulous one that has great promise is using Flow for
workflows/processes (which falls out naturally from the integration of
discussions) - this is what Erik describes below as tags, though I
think that terminology is new to me.

-- 
- Andrew Gray
  andrew.g...@dunelm.org.uk

___
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] wikipedia access traces ?

[Valerio Schiavoni]

Dear WikiMedia foundation,
in the context of a EU research project [1], we are interested in accessing
wikipedia access traces.
In the past, such traces were given for research purposes to other groups
[2].
Unfortunately, only a small percentage (10%) of that trace has been made
made available (10%).
We are interested in accessing the totality of that same trace (or even
better, a more recent one, but the same one will do).

If this is not the correct ML to use for such requests, could please anyone
redirect me to correct one ?

Thanks again for your attention,

Valerio Schiavoni
Post-Doc Researcher
University of Neuchatel, Switzerland


1 - http://www.leads-project.eu
2 - http://www.wikibench.eu/?page_id=60
___
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

[Martijn Hoekstra]

I'd like to note that the following is my personal opinion, and any
resemblance to the opinions of the Wikipedia community or any parts therof,
Jimmy Wales, the NSA, the Dutch government, Y-combinator, the national
library of Australia, the British Housewives' League, and/or any other
opinion of any individual and/or organisation is purely coincidental. (am I
doing this right?)

On Wed, Sep 10, 2014 at 10:28 AM, Keegan Peterzell 
wrote:

> In case it's not clear enough in my sig, this is my personal opinion:
>
> On Wed, Sep 10, 2014 at 12:20 AM, Martijn Hoekstra <
> martijnhoeks...@gmail.com> wrote:
>
> > On Sep 10, 2014 5:11 AM, "Keegan Peterzell" 
> wrote:
> > >
> > > On Tue, Sep 9, 2014 at 10:04 AM, Wil Sinclair  wrote:
> > >
> > > >
> > > > FWIW, I signed my first comment by hand. I missed the comments about
> > > > sigs in the wikitext editor interface. If it weren't for my family
> > > > situation, I'm pretty sure I would have bailed. In any case, it was
> > > > much easier to engage at WO, and that was partly- but not mostly- due
> > > > to the fact that they run discussion software over there.
> > > >
> > > > ,Wil
> > > >
> > > >
> > > ​This - signing by hand - is pretty much a universal experience for new
> > > users, myself included.
> > >
> > >
> >
> >
> https://en.wikipedia.org/w/index.php?title=Talk:History_of_Alaska&diff=prev&oldid=26555079
> > > ​
> > >
> > >
> > > --
> > > ~Keegan
> > >
> > > https://en.wikipedia.org/wiki/User:Keegan
> >
> > I'm not saying that isn't crap and unwelcoming: it is, and it deters new
> > users. But it's hardly the end of the world either. By signing the wrong
> > way no real harm is done, if someone just tells you about the option to
> use
> > 
> >
> > It's crap and archaic and should be fixed, but it's also an example of
> the
> > idea that there are no mistakes on a wiki. So you did something not
> right?
> > Great, that means you contributed. So we fix it (collaboratively) and
> > improve your contribution, no harm done.
>
>
> ​I agree with you, Martjin. If you follow the cookie crumbs you'd see that
> I registered an account on the English Wikipedia /solely/ so I could sign a
> complaint about a resource I used and loved, and I thought it best to give
> respect back by registering and figuring out how to sign my complaint. I
> was also incredibly lucky as a n00b to have positive interactions, right
> from the get-go, which makes it a little more clear to me why I'm still
> around after all this time. I'm thirty-three years old, to me a nine-year
> unintentional commitment is a lifetime :)
>
> I'm also aware, through my experiences through the past nine years, that my
> experience is Golden™, and I desperately wish all new users could have such
> an experience.
>
> This kind of thing starts with software changes that break my workflow. I
> hate that. But to be fair, my workflow is ridiculous because the software
> is.​
>
> ​The steps I have to take to do the things that I do would, IMO, make a
> rational person cry :).  I really don't understand the theory that new
> users have to go through the same experiences as I did, no matter how
> pleasant, again IMO, my experiences were.


Neither do I, really - which is why I support auto signing and a
quick-reply button added to the current interface

Hazing is an antiquated and
> unfruitful process. It only breaks people down to rebuild them in the image
> that you want, and that's contradictory to the individualism that Wikimedia
> promotes.


I think you're attacking a straw man. I certainly want new users to have a
positive experience, and not, in your words haze them.


> I enjoy the fact that Wikimedia sites allow flexibility and
> customization on a personal account and institutional level. On the other
> hand, the world keeps moving and I sta​y in the same place unless I choose
> to go through the process of acceptance of a changing world. I do not
> consider the world changing to be something shoved down my throat; it's a
> reality of life.
>
> --
> ~Keegan
>
> https://en.wikipedia.org/wiki/User:Keegan
>
> This is my personal email address. Everything sent from this email address
> is in a personal capacity.
> ___
> 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

[Keegan Peterzell]

In case it's not clear enough in my sig, this is my personal opinion:

On Wed, Sep 10, 2014 at 12:20 AM, Martijn Hoekstra <
martijnhoeks...@gmail.com> wrote:

> On Sep 10, 2014 5:11 AM, "Keegan Peterzell"  wrote:
> >
> > On Tue, Sep 9, 2014 at 10:04 AM, Wil Sinclair  wrote:
> >
> > >
> > > FWIW, I signed my first comment by hand. I missed the comments about
> > > sigs in the wikitext editor interface. If it weren't for my family
> > > situation, I'm pretty sure I would have bailed. In any case, it was
> > > much easier to engage at WO, and that was partly- but not mostly- due
> > > to the fact that they run discussion software over there.
> > >
> > > ,Wil
> > >
> > >
> > ​This - signing by hand - is pretty much a universal experience for new
> > users, myself included.
> >
> >
>
> https://en.wikipedia.org/w/index.php?title=Talk:History_of_Alaska&diff=prev&oldid=26555079
> > ​
> >
> >
> > --
> > ~Keegan
> >
> > https://en.wikipedia.org/wiki/User:Keegan
>
> I'm not saying that isn't crap and unwelcoming: it is, and it deters new
> users. But it's hardly the end of the world either. By signing the wrong
> way no real harm is done, if someone just tells you about the option to use
> 
>
> It's crap and archaic and should be fixed, but it's also an example of the
> idea that there are no mistakes on a wiki. So you did something not right?
> Great, that means you contributed. So we fix it (collaboratively) and
> improve your contribution, no harm done.


​I agree with you, Martjin. If you follow the cookie crumbs you'd see that
I registered an account on the English Wikipedia /solely/ so I could sign a
complaint about a resource I used and loved, and I thought it best to give
respect back by registering and figuring out how to sign my complaint. I
was also incredibly lucky as a n00b to have positive interactions, right
from the get-go, which makes it a little more clear to me why I'm still
around after all this time. I'm thirty-three years old, to me a nine-year
unintentional commitment is a lifetime :)

I'm also aware, through my experiences through the past nine years, that my
experience is Golden™, and I desperately wish all new users could have such
an experience.

This kind of thing starts with software changes that break my workflow. I
hate that. But to be fair, my workflow is ridiculous because the software
is.​

​The steps I have to take to do the things that I do would, IMO, make a
rational person cry :).  I really don't understand the theory that new
users have to go through the same experiences as I did, no matter how
pleasant, again IMO, my experiences were. Hazing is an antiquated and
unfruitful process. It only breaks people down to rebuild them in the image
that you want, and that's contradictory to the individualism that Wikimedia
promotes. I enjoy the fact that Wikimedia sites allow flexibility and
customization on a personal account and institutional level. On the other
hand, the world keeps moving and I sta​y in the same place unless I choose
to go through the process of acceptance of a changing world. I do not
consider the world changing to be something shoved down my throat; it's a
reality of life.

-- 
~Keegan

https://en.wikipedia.org/wiki/User:Keegan

This is my personal email address. Everything sent from this email address
is in a personal capacity.
___
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

[Martijn Hoekstra]

On Wed, Sep 10, 2014 at 9:55 AM, Gerard Meijssen 
wrote:

> Hoi,
> I expected that it was obvious... Arguments that are based on desktop
> experiences are futile because  the desktop experience is the lesser of two
> evils. The desktop experience is already bad, the experience on mobiles and
> tablets is much worse it is intolerably unusable,
>

I meant I didn't understand what you meant by "A mobile or tablet screen is
increasingly not used in isolation."

>
> Yes, you are overlooking stuff when you only consider inserting an isolated
> comment that may help. That is not the only problem and not even the main
> problem. Reading and analysing talk pages is already next to impossible in
> this environment therefore inserting an isolated comment does not help
> enough to make the experience at least bearable.
> Thanks,
>   GerardM
>

Yeah, reading long intricate discussion on mobile sucks, but I'm not sure
how Flow will help combat that - I'm very open to being shown a wider
perspective. I'm still convinced that the primary difficulty in reading and
analyzing long, intricate, branching discussions on mobile is caused by
them being long, branching and intricate, not due to any software or
rendering issues.

>
> On 10 September 2014 09:47, Martijn Hoekstra 
> wrote:
>
> > On Sep 10, 2014 9:35 AM, "Gerard Meijssen" 
> > wrote:
> > >
> > > Hoi.
> > > When you look at talk pages in isolation, you look at them on a
> computer
> > > screen. A mobile or tablet screen is increasingly not used in
> isolation.
> >
> > I'm not sure what you mean by this.
> >
> > It
> > > is where we find our new users and editors. We cannot afford to ignore
> > > them; they are our future. This is why tinkering with talk pages is not
> > an
> > > option. Moving away from talk pages because of mobiles and tablets is
> the
> > > killer reason why we need to move away from talk pages.
> > >
> > > It is a killer reason because it makes all arguments to the contrary
> pale
> > > away.
> > > Thanks,
> > >  GerardM
> >
> > What I find most painful about talk pages on mobile (on the desktop skin,
> > because so far I've been too impatient to find talk pages and edit
> > functionality on mobile) have been that editing huge text areas really
> > sucks (the scrolling and positioning the cursor is a huge pain). This is
> > not limited to talk pages by the way, but is identical for mainspace
> pages.
> >
> > A reply button that inserts an isolated comment at the correct
> indentation
> > level would fix that. Am I overlooking stuff?
> > >
> > > On 10 September 2014 09:20, Martijn Hoekstra <
> martijnhoeks...@gmail.com>
> > > wrote:
> > >
> > > > On Sep 10, 2014 5:11 AM, "Keegan Peterzell" 
> > wrote:
> > > > >
> > > > > On Tue, Sep 9, 2014 at 10:04 AM, Wil Sinclair 
> wrote:
> > > > >
> > > > > >
> > > > > > FWIW, I signed my first comment by hand. I missed the comments
> > about
> > > > > > sigs in the wikitext editor interface. If it weren't for my
> family
> > > > > > situation, I'm pretty sure I would have bailed. In any case, it
> was
> > > > > > much easier to engage at WO, and that was partly- but not mostly-
> > due
> > > > > > to the fact that they run discussion software over there.
> > > > > >
> > > > > > ,Wil
> > > > > >
> > > > > >
> > > > > ​This - signing by hand - is pretty much a universal experience for
> > new
> > > > > users, myself included.
> > > > >
> > > > >
> > > >
> > > >
> >
> >
> https://en.wikipedia.org/w/index.php?title=Talk:History_of_Alaska&diff=prev&oldid=26555079
> > > > > ​
> > > > >
> > > > >
> > > > > --
> > > > > ~Keegan
> > > > >
> > > > > https://en.wikipedia.org/wiki/User:Keegan
> > > >
> > > > I'm not saying that isn't crap and unwelcoming: it is, and it deters
> > new
> > > > users. But it's hardly the end of the world either. By signing the
> > wrong
> > > > way no real harm is done, if someone just tells you about the option
> to
> > use
> > > > 
> > > >
> > > > It's crap and archaic and should be fixed, but it's also an example
> of
> > the
> > > > idea that there are no mistakes on a wiki. So you did something not
> > right?
> > > > Great, that means you contributed. So we fix it (collaboratively) and
> > > > improve your contribution, no harm done.
> > > >
> > > > That said, auto sign and a reply button would be a *whole* lot
> > friendlier
> > > > than what we have now, and would be great improvements over the
> current
> > > > situation.
> > > >
> > > > Flow definitely has a reply button, and automatic signing as well,
> but
> > I
> > > > can't help but think that just those features in isolation would be
> > better
> > > > then completely overhauling talk pages.
> > > >
> > > > --Martijn
> > > >
>
___
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

[Gerard Meijssen]

Hoi,
I expected that it was obvious... Arguments that are based on desktop
experiences are futile because  the desktop experience is the lesser of two
evils. The desktop experience is already bad, the experience on mobiles and
tablets is much worse it is intolerably unusable,

Yes, you are overlooking stuff when you only consider inserting an isolated
comment that may help. That is not the only problem and not even the main
problem. Reading and analysing talk pages is already next to impossible in
this environment therefore inserting an isolated comment does not help
enough to make the experience at least bearable.
Thanks,
  GerardM

On 10 September 2014 09:47, Martijn Hoekstra 
wrote:

> On Sep 10, 2014 9:35 AM, "Gerard Meijssen" 
> wrote:
> >
> > Hoi.
> > When you look at talk pages in isolation, you look at them on a computer
> > screen. A mobile or tablet screen is increasingly not used in isolation.
>
> I'm not sure what you mean by this.
>
> It
> > is where we find our new users and editors. We cannot afford to ignore
> > them; they are our future. This is why tinkering with talk pages is not
> an
> > option. Moving away from talk pages because of mobiles and tablets is the
> > killer reason why we need to move away from talk pages.
> >
> > It is a killer reason because it makes all arguments to the contrary pale
> > away.
> > Thanks,
> >  GerardM
>
> What I find most painful about talk pages on mobile (on the desktop skin,
> because so far I've been too impatient to find talk pages and edit
> functionality on mobile) have been that editing huge text areas really
> sucks (the scrolling and positioning the cursor is a huge pain). This is
> not limited to talk pages by the way, but is identical for mainspace pages.
>
> A reply button that inserts an isolated comment at the correct indentation
> level would fix that. Am I overlooking stuff?
> >
> > On 10 September 2014 09:20, Martijn Hoekstra 
> > wrote:
> >
> > > On Sep 10, 2014 5:11 AM, "Keegan Peterzell" 
> wrote:
> > > >
> > > > On Tue, Sep 9, 2014 at 10:04 AM, Wil Sinclair  wrote:
> > > >
> > > > >
> > > > > FWIW, I signed my first comment by hand. I missed the comments
> about
> > > > > sigs in the wikitext editor interface. If it weren't for my family
> > > > > situation, I'm pretty sure I would have bailed. In any case, it was
> > > > > much easier to engage at WO, and that was partly- but not mostly-
> due
> > > > > to the fact that they run discussion software over there.
> > > > >
> > > > > ,Wil
> > > > >
> > > > >
> > > > ​This - signing by hand - is pretty much a universal experience for
> new
> > > > users, myself included.
> > > >
> > > >
> > >
> > >
>
> https://en.wikipedia.org/w/index.php?title=Talk:History_of_Alaska&diff=prev&oldid=26555079
> > > > ​
> > > >
> > > >
> > > > --
> > > > ~Keegan
> > > >
> > > > https://en.wikipedia.org/wiki/User:Keegan
> > >
> > > I'm not saying that isn't crap and unwelcoming: it is, and it deters
> new
> > > users. But it's hardly the end of the world either. By signing the
> wrong
> > > way no real harm is done, if someone just tells you about the option to
> use
> > > 
> > >
> > > It's crap and archaic and should be fixed, but it's also an example of
> the
> > > idea that there are no mistakes on a wiki. So you did something not
> right?
> > > Great, that means you contributed. So we fix it (collaboratively) and
> > > improve your contribution, no harm done.
> > >
> > > That said, auto sign and a reply button would be a *whole* lot
> friendlier
> > > than what we have now, and would be great improvements over the current
> > > situation.
> > >
> > > Flow definitely has a reply button, and automatic signing as well, but
> I
> > > can't help but think that just those features in isolation would be
> better
> > > then completely overhauling talk pages.
> > >
> > > --Martijn
> > >
> > > >
> > > > This is my personal email address. Everything sent from this email
> > > address
> > > > is in a personal capacity.
> > > > ___
> > > > 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

[Martijn Hoekstra]

On Sep 10, 2014 9:35 AM, "Gerard Meijssen" 
wrote:
>
> Hoi.
> When you look at talk pages in isolation, you look at them on a computer
> screen. A mobile or tablet screen is increasingly not used in isolation.

I'm not sure what you mean by this.

It
> is where we find our new users and editors. We cannot afford to ignore
> them; they are our future. This is why tinkering with talk pages is not an
> option. Moving away from talk pages because of mobiles and tablets is the
> killer reason why we need to move away from talk pages.
>
> It is a killer reason because it makes all arguments to the contrary pale
> away.
> Thanks,
>  GerardM

What I find most painful about talk pages on mobile (on the desktop skin,
because so far I've been too impatient to find talk pages and edit
functionality on mobile) have been that editing huge text areas really
sucks (the scrolling and positioning the cursor is a huge pain). This is
not limited to talk pages by the way, but is identical for mainspace pages.

A reply button that inserts an isolated comment at the correct indentation
level would fix that. Am I overlooking stuff?
>
> On 10 September 2014 09:20, Martijn Hoekstra 
> wrote:
>
> > On Sep 10, 2014 5:11 AM, "Keegan Peterzell" 
wrote:
> > >
> > > On Tue, Sep 9, 2014 at 10:04 AM, Wil Sinclair  wrote:
> > >
> > > >
> > > > FWIW, I signed my first comment by hand. I missed the comments about
> > > > sigs in the wikitext editor interface. If it weren't for my family
> > > > situation, I'm pretty sure I would have bailed. In any case, it was
> > > > much easier to engage at WO, and that was partly- but not mostly-
due
> > > > to the fact that they run discussion software over there.
> > > >
> > > > ,Wil
> > > >
> > > >
> > > ​This - signing by hand - is pretty much a universal experience for
new
> > > users, myself included.
> > >
> > >
> >
> >
https://en.wikipedia.org/w/index.php?title=Talk:History_of_Alaska&diff=prev&oldid=26555079
> > > ​
> > >
> > >
> > > --
> > > ~Keegan
> > >
> > > https://en.wikipedia.org/wiki/User:Keegan
> >
> > I'm not saying that isn't crap and unwelcoming: it is, and it deters new
> > users. But it's hardly the end of the world either. By signing the wrong
> > way no real harm is done, if someone just tells you about the option to
use
> > 
> >
> > It's crap and archaic and should be fixed, but it's also an example of
the
> > idea that there are no mistakes on a wiki. So you did something not
right?
> > Great, that means you contributed. So we fix it (collaboratively) and
> > improve your contribution, no harm done.
> >
> > That said, auto sign and a reply button would be a *whole* lot
friendlier
> > than what we have now, and would be great improvements over the current
> > situation.
> >
> > Flow definitely has a reply button, and automatic signing as well, but I
> > can't help but think that just those features in isolation would be
better
> > then completely overhauling talk pages.
> >
> > --Martijn
> >
> > >
> > > This is my personal email address. Everything sent from this email
> > address
> > > is in a personal capacity.
> > > ___
> > > 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,

___
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

[Gerard Meijssen]

Hoi.
When you look at talk pages in isolation, you look at them on a computer
screen. A mobile or tablet screen is increasingly not used in isolation. It
is where we find our new users and editors. We cannot afford to ignore
them; they are our future. This is why tinkering with talk pages is not an
option. Moving away from talk pages because of mobiles and tablets is the
killer reason why we need to move away from talk pages.

It is a killer reason because it makes all arguments to the contrary pale
away.
Thanks,
 GerardM

On 10 September 2014 09:20, Martijn Hoekstra 
wrote:

> On Sep 10, 2014 5:11 AM, "Keegan Peterzell"  wrote:
> >
> > On Tue, Sep 9, 2014 at 10:04 AM, Wil Sinclair  wrote:
> >
> > >
> > > FWIW, I signed my first comment by hand. I missed the comments about
> > > sigs in the wikitext editor interface. If it weren't for my family
> > > situation, I'm pretty sure I would have bailed. In any case, it was
> > > much easier to engage at WO, and that was partly- but not mostly- due
> > > to the fact that they run discussion software over there.
> > >
> > > ,Wil
> > >
> > >
> > ​This - signing by hand - is pretty much a universal experience for new
> > users, myself included.
> >
> >
>
> https://en.wikipedia.org/w/index.php?title=Talk:History_of_Alaska&diff=prev&oldid=26555079
> > ​
> >
> >
> > --
> > ~Keegan
> >
> > https://en.wikipedia.org/wiki/User:Keegan
>
> I'm not saying that isn't crap and unwelcoming: it is, and it deters new
> users. But it's hardly the end of the world either. By signing the wrong
> way no real harm is done, if someone just tells you about the option to use
> 
>
> It's crap and archaic and should be fixed, but it's also an example of the
> idea that there are no mistakes on a wiki. So you did something not right?
> Great, that means you contributed. So we fix it (collaboratively) and
> improve your contribution, no harm done.
>
> That said, auto sign and a reply button would be a *whole* lot friendlier
> than what we have now, and would be great improvements over the current
> situation.
>
> Flow definitely has a reply button, and automatic signing as well, but I
> can't help but think that just those features in isolation would be better
> then completely overhauling talk pages.
>
> --Martijn
>
> >
> > This is my personal email address. Everything sent from this email
> address
> > is in a personal capacity.
> > ___
> > 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] Access by Wikimedia volunteers to WMF records about them

[Fæ]

I had a reply yesterday from WMF legal. The answer is no.

This is based on the WMF believing that they have no policies which
obligate them to explain what records they keep on a volunteer or
provide copies of records, and that there are no data protection laws
that ensure that this information is provided to their volunteers.

There appears to have been no attempt to review what records and
reports the WMF holds on me, the answer was generic.

Should WMF Legal say they are happy for me to do so, I will be happy
to publish their reply in full.

Thanks,
Fae

On 22/08/2014, Fæ  wrote:
> I wrote the email below to Lila and the WMF Legal department asking
> for access to records (and reports) they hold on me, but I'm sad to
> say that after 3 weeks waiting, I have yet to receive an
> acknowledgement. As a Wikimania London volunteer I had a moment to
> speak with Jan-Bart, and some of my Wikimedia Commons uploads were
> even featured as part of a presentation by WMF Legal on their
> successes in the past year, so there was plenty of opportunity for us
> to have the friendly chat I suggested.
>
> Can someone recommend if there is a WMF policy on transparency that
> volunteers can rely on for questions like mine, or does the law in the
> USA give me any specific rights of access to records or reports the
> WMF may keep on me that would mean that WMF Legal would do more than
> stay silent in response to reasonable requests from its established
> volunteers?
>
> Thanks,
> Fae
>
> -- Forwarded message --
> From: Fæ 
> Date: Sun, 3 Aug 2014 13:49:45 +0100
> Subject: Request for disclosure of all WMF records relating to Fae
> To: Lila Tretikov 
> Cc: legal , Jan-Bart de Vreede
> 
>
> Dear Lila,
>
> The Wikimedia Foundation keeps information such as management
> summaries about me, which have never been shared with me.
> [Redacted example material]
>
> Could you please ensure that all records that the WMF has retained
> about me are copied to me? It would seem fair that I have the
> opportunity to both understand what the WMF management and board have
> available to refer to when discussing my activities for Wikimedia, and
> that I have a chance to both correct any mistakes in this personal
> data, or to ask that inappropriate material gets permanently removed
> from WMF databases.
>
> I will be active in both the Wikimania hackerthon and conference in
> the coming week, should you or an employee wish to informally review
> this request with me in person, along with my reasons for making the
> request at this time.
> ...
> --
> fae...@gmail.com https://commons.wikimedia.org/wiki/User:Fae

-- 
fae...@gmail.com https://commons.wikimedia.org/wiki/User:Fae

___
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

[Martijn Hoekstra]

On Sep 10, 2014 5:11 AM, "Keegan Peterzell"  wrote:
>
> On Tue, Sep 9, 2014 at 10:04 AM, Wil Sinclair  wrote:
>
> >
> > FWIW, I signed my first comment by hand. I missed the comments about
> > sigs in the wikitext editor interface. If it weren't for my family
> > situation, I'm pretty sure I would have bailed. In any case, it was
> > much easier to engage at WO, and that was partly- but not mostly- due
> > to the fact that they run discussion software over there.
> >
> > ,Wil
> >
> >
> ​This - signing by hand - is pretty much a universal experience for new
> users, myself included.
>
>
https://en.wikipedia.org/w/index.php?title=Talk:History_of_Alaska&diff=prev&oldid=26555079
> ​
>
>
> --
> ~Keegan
>
> https://en.wikipedia.org/wiki/User:Keegan

I'm not saying that isn't crap and unwelcoming: it is, and it deters new
users. But it's hardly the end of the world either. By signing the wrong
way no real harm is done, if someone just tells you about the option to use


It's crap and archaic and should be fixed, but it's also an example of the
idea that there are no mistakes on a wiki. So you did something not right?
Great, that means you contributed. So we fix it (collaboratively) and
improve your contribution, no harm done.

That said, auto sign and a reply button would be a *whole* lot friendlier
than what we have now, and would be great improvements over the current
situation.

Flow definitely has a reply button, and automatic signing as well, but I
can't help but think that just those features in isolation would be better
then completely overhauling talk pages.

--Martijn

>
> This is my personal email address. Everything sent from this email address
> is in a personal capacity.
> ___
> 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,