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

[Yaroslav M. Blanter]

On 11.09.2014 10:53, Peter Southwood wrote:

Exactly what I was thinking.
Doesn’t mean it would necessarily work, but you are not alone...
Cheers,
Peter


Actually, if I get it correctly, Wikinews uses three pages per item 
(news, talk, and smth else).


Cheers
Yaroslav



-Original Message-
From: wikimedia-l-boun...@lists.wikimedia.org
[mailto:wikimedia-l-boun...@lists.wikimedia.org] On Behalf Of Tim
Davenport
Sent: 10 September 2014 11:12 PM
To: wikimedia-l@lists.wikimedia.org
Subject: Re: [Wikimedia-l] To Flow or not to Flow

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,
<mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>

-
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2014.0.4765 / Virus Database: 4015/8192 - Release Date: 
09/11/14



___
Wikimedia-l mailing list, guidelines at:
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe:
https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
<mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>


___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
<mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>

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

[Peter Southwood]

Exactly what I was thinking.
Doesn’t mean it would necessarily work, but you are not alone...
Cheers,
Peter

-Original Message-
From: wikimedia-l-boun...@lists.wikimedia.org 
[mailto:wikimedia-l-boun...@lists.wikimedia.org] On Behalf Of Tim Davenport
Sent: 10 September 2014 11:12 PM
To: wikimedia-l@lists.wikimedia.org
Subject: Re: [Wikimedia-l] To Flow or not to Flow

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, 
<mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>

-
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2014.0.4765 / Virus Database: 4015/8192 - Release Date: 09/11/14


___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
<mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>

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

[Martijn Hoekstra]

On Thursday, September 11, 2014, John Mark Vandenberg 
wrote:

> On Thu, Sep 11, 2014 at 8:21 AM, Wil Sinclair  > wrote:
> > 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.
>
> The concept of a meta document, which uses wikitext and is editable
> using VE, would alleviate a lot of the concerns about Flow.  It would
> be relatively simple to change processes from using 'Talk:x' to using
> 'MetaDoc:x' (still a big migration task, but less problematic than
> going through process re-engineering for every Wikipedia process in
> 250+ projects with their own language).
>
> If that meta document also had a talk namespace (MetaDocTalk:x), which
> uses wikitext, the old-timers (and bots) will still have a place to
> hold discussions and post notes using wikitext if they wish to.
>
> --
> John Vandenberg



+1, at least as transition mechanism.

--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,
>  ?subject=unsubscribe>
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

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

[John Mark Vandenberg]

On Thu, Sep 11, 2014 at 8:21 AM, Wil Sinclair  wrote:
> 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.

The concept of a meta document, which uses wikitext and is editable
using VE, would alleviate a lot of the concerns about Flow.  It would
be relatively simple to change processes from using 'Talk:x' to using
'MetaDoc:x' (still a big migration task, but less problematic than
going through process re-engineering for every Wikipedia process in
250+ projects with their own language).

If that meta document also had a talk namespace (MetaDocTalk:x), which
uses wikitext, the old-timers (and bots) will still have a place to
hold discussions and post notes using wikitext if they wish to.

-- 
John Vandenberg

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

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

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

[Keegan Peterzell]

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

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 -> it does not flow

[Samuel Klein]

On Sat, Sep 6, 2014 at 6:33 PM, Erik Moeller  wrote:

< Flow is a long term bet that an architecture of structured comments
> will ultimately have fewer hard and fast limitations on how
> collaboration in wikis can work, and will accrue usability benefits
> very quickly (as it already has done, like faster posting and replies)
< due to its architecture ... some rebalancing of effort towards the short
> term may be valuable, and may lead to interim milestones that impact
> users today rather than years from now.

Testing this by irreversibly replacing existing unstructured talk
pages seems likely to be a hard transition and hard to evaluate, since
it breaks workflows as it enables new ones.

Two less dramatic ways to test such a bet:

1. Experiment with annotation and inline comments

This is one of the oldest forms of curation; a rapidly growing area of
knowledge production online; e.g.: one of the early and beloved
features of G!Docs, and the central feature of Genius which has its
own communities curating interleaved and overlaid knowledge.

MW currently has little capacity for annotation, beyond inline
footnotes.  An improvement in that area would be welcome.  The
annotation use case is also a bit better-defined – more universa!ly a
thread of individual thoughts – than the broad range of uses for talk
pages.

Over time I could see many current uses of talk pages, including the
simplest and most common ones, shifting to inline comments.

2. Experiment with UI overlays on top of current talk pages where possible.

For instance: the way talk pages and their tables of contents and
section headings are displayed, where links to "reply" are displayed,
how signatures are generated, the way a textarea is presented for
adding a new comment.

Similarly, font / whitespace / layout changes are general UI shifts,
and could be tested now without changing the function and data models
of talk pages.

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

I don't know how many people here remember their first discussion on
WP, but I do. Probably because it was less than 6 months ago. :)

My first impression was "you have got to be kidding me". I was annoyed
I had to learn a new markup dialect, but that didn't deter me. Since I
had some experience with wiki software when it was still cool about a
decade ago, I chalked it up to the Weltanschauung that a wiki can do
almost anything. I've always thought that there is a clause missing
from this mindset: "and 99% of that it does poorly". I think that
discussions easily find themselves in that 99%. But I wonder if there
is a way that Flow can sit on top of wiki markup; many document
oriented databases back discussion software, so why can't we reuse all
the work done in formatting, version, and handling conflicts for
discussions? Is it possible that discussions can be implemented
without changing the data layer at all?

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


On Mon, Sep 8, 2014 at 7:24 AM, Marc A. Pelletier  wrote:
> On 09/08/2014 10:18 AM, Risker wrote:
>> The most obvious one is automatic signing of comments, and it is
>> something that we have technically been able to impose for years; sinebot
>> didn't come into existence in a vacuum.
>
> I suppose that's a philosophical divergence between us then - that
> sinebot even needs to exist to me is demonstration that the system is
> broken.
>
> You say that discussion isn't all that much harder than editing content.
>  Even if I agreed with that (and I do not, edit conflicts in articles
> are much rarer than on talk pages - and usually easier to sort out),
> that's not a *good* thing!
>
> Participating in discussion should be much, *much* easier than editing
> articles: encouraging newbies to seek help and participate in the
> community *before* diving in anything but trivial article edits would be
> an immensely powerful retention tool!
>
> (Which isn't to say that editing articles doesn't *also* need a lot of
> help - but that's a different project).
>
> -- 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

[Diego Moya]

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

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


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

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

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

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

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

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

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

[David Gerard]

On 9 September 2014 10:45, Erik Moeller  wrote:
> On Mon, Sep 8, 2014 at 12:22 AM, David Gerard  wrote:

>> Those of us who presently use talk pages to get the work done. What is
>> going to make us *love* Flow, for all its imperfections, and demand to
>> have it for ourselves? What's Flow's killer feature for us?

> First, on the subject of "kiler features", generally - we can make
> educated guesses, but with software that's used by communities, you
> really need to experiment and iterate.
> We guessed that mentions would
> become popular, but their use has exceeded our wildest expectations.
> Go to any high traffic talk page and you'll see Echo pings all over
> the place. A feature that didn't exist before 2013 and that nobody, as
> far as I know, ever asked for (!) before we built it. And yet it's
> become indispensable.


Yes, I see what you mean.


> If you want to go nuts, you could build a Flow<->mailing list or
> Flow<->NNTP (oldschool!) gateway. If we do our API homework, I mean
> literally "you" because we're sure as hell not going to do it anytime
> soon ;-)


This is tangential, but caught my eye. I've rambled before about how
(I think) the unit of a forum is the thread, but the unit of
email/NNTP is the individual message; and gateways between the two
suffer from this fundamental difference:
http://reddragdiva.dreamwidth.org/566555.html

So do you expect the unit (in this sense) of Flow will be the message
or the thread? Or both, or either?

(Wiki talk pages don't have a unit really, which is their blessing for
flexibility and curse for usability.)


- 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

[Erik Moeller]

On Mon, Sep 8, 2014 at 12:22 AM, David Gerard  wrote:
> On 8 September 2014 05:46, John Mark Vandenberg  wrote:
> Those of us who presently use talk pages to get the work done. What is
> going to make us *love* Flow, for all its imperfections, and demand to
> have it for ourselves? What's Flow's killer feature for us?

First, on the subject of "kiler features", generally - we can make
educated guesses, but with software that's used by communities, you
really need to experiment and iterate. I'm sure we'll try stuff in
Flow that doesn't make sense (and we've already talked here about
aspects of the current design that may have to be changed, like the
limited threading display), and I'm sure things we think are minor
will become more popular than we expect.

Generally, I'm not a big fan of maintaining illusions of certainty.
I've argued against detailed year-long plans to Sue and the Board, as
I'm sure they will attest, until we got the flexibility to set more
malleable goals in engineering. Lila immediately came in with the
expectation in mind that we'd have precision a quarter out, and broad
high level ideas a year out, and need flexibility to change our mind
as we learn. In tech work, you need to be able to double down on
success when you hit it (make that killer feature _the_ feature), and
kill the cruft that you thought was smart but that just doesn't work.

With Echo, we included a bunch of notification types and didn't really
know which ones people would love. We guessed that mentions would
become popular, but their use has exceeded our wildest expectations.
Go to any high traffic talk page and you'll see Echo pings all over
the place. A feature that didn't exist before 2013 and that nobody, as
far as I know, ever asked for (!) before we built it. And yet it's
become indispensable.

When we experimented with mobile contributions, our first hypothesis
was that uploads would be a good start, because mobile isn't
well-suited for long form edit contributions. In fact, mobile editing
became wildly popular very quickly and has generally been embraced by
the community (to the point where people ask us to enable IP editing
on mobile, which we consciously did not do initially to lessen crappy
edits), while the signal to noise ratio on uploads has been so poor
that we're about to retire most upload features until we really can
spend cycles on mitigating those risks.

So, educated guesses and hypotheses.

Flow makes lots of things possible that are otherwise hard/impossible
(much better search, tracking of comments, etc.) but my hypothesis is
that there are three primary killer features that Flow can provide:

1) Fast interactions. The process of responding on a talk page is
ridiculously slow (edit section, find place, indent comment, write
comment, sign comment, preview, save, worry about edit conflict ..).

In my view, the reason people don't value this in Flow such-as-it-is
already is primarily [[loss aversion]]. There's a large set of
concerns that Flow makes existing things impossible (and yes, I'll
respond a bit more to Diego) or harder. Losses are psychologically far
more powerful than gains -- so any cool comment features that Flow
_already has_ (fast and easy replies, no edit conflicts, etc) will not
be perceived to be "killer features" unless/until the balance of
perceived losses shrinks dramatically from what it is now. And it'll
keep shrinking as we go.

As pointed out, we can _try_ to make this work with sticks, spit and
duct tape on top of wikitext, even in the odd cases of mixed markup
for indentation, comments interrupted in the middle, outdent
templates, etc. -- but it'll almost certainly just have to bail in
some cases, and misidentify comment demarcations in others. I'd like
to test those boundaries a bit more before making confident statements
about how much of "fast interactions" we can deliver without Flow,
however. Either way, it is IMO a clear killer feature that's badly
needed.

2) Centralized conversation spaces. Flow's architecture is already
cross-wiki; its UI is not. As pointed out, there are multiple
cross-wiki discussions as well as mailing list discussions about this
very topic. Wil suggested "Pick a conversation space and stick to
it!". Well, wouldn't that be nice - if it worked in our universe.
Except that we know it rarely does. People want to have discussions in
their "home wiki", and we use mailing list threads like this for good
reasons as well.

You could participate in the same Flow conversation from en.wp,
mediawiki.org and meta, without caring one way or another (SUL
finalization being the main blocker to avoid account wonkiness).
When/where that's desirable is something to negotiate -- but for
example, feedback on features that are deployed across wikis is a
perfect case for wanting to have local pages that feed into a single
stream of comments.

If you want to go nuts, you could build a Flow<->mailing list or
Flow<->NNTP (oldschool!) gateway. If we do our API homework, 

Re: [Wikimedia-l] To Flow or not to Flow -> it does not flow

[Erik Moeller]

On Mon, Sep 8, 2014 at 6:47 PM, Erik Moeller  wrote:

> - Gabriel Wicke has done some experimentation with this as well, and
> is looking if he can dig up the old code for me.

Very old indeed, but if anyone wants to take a look:
https://github.com/gwicke/wikiforum


-- 
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation

___
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 -> it does not flow

[Erik Moeller]

On Sat, Sep 6, 2014 at 3:33 PM, Erik Moeller  wrote:

> As I wrote to Risker, I think it's worth considering spending some
> development time on turning something like the Teahouse gadget (which
> allows one click insertion of replies on the Teahouse Q/A page) into a
> Beta Feature after some further improvement, to see just how useful it
> could be for the common case. If there's an 80/20 rule and in 20% of
> cases it just gives up and edits the section, that might still be a
> time-saver and convenience. There might even be other relevant gadgets
> already in some languages/projects -- worth a closer look, for sure.

I'm talking about this with the Flow team, but I also want to be
conscious of their focus and energy. One possibility is to contract
this out to an individual dev to test out the boundaries of what can
be done in JavaScript alone -- and make recommendations for any
mediawiki/core changes that could help. Since a JS opt-in script can
be quickly developed by anyone with talent and motivation there's
really no barrier to trying this.

If anyone's reading feels they're qualified to take this on and would
be interested doing it on a contract, drop me a line offlist.
Obviously it's also a great opportunity for volunteer experimentation,
as well. I think at this stage we should consider this a research
effort.

There is some pre-existing work on this, beyond the Teahouse gadget.

- Mobile web has a very experimental "reply" feature on talk pages
right now. It doesn't handle the indentation levels, as far as I can
tell - it just inserts a new top-level comment. You can turn this on
by 1) enabling beta, 2) enabling alpha, 3) logging in, 4) going to a
talk page, 5) going to a section. That's a lot of steps, but since
it's so experimental that's probably for the best :-)

- Gabriel Wicke has done some experimentation with this as well, and
is looking if he can dig up the old code for me.

If others are aware of relevant hacks/gadgets/user srcipts, please let me know.

Erik

-- 
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation

___
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

[WereSpielChequers]

Responding to two comments. Firstly Risker " Newbies have an equally hard time
> 
> editing content, too, and even when they succeed, on many projects they're
> very likely to be reverted and deluged with templated messages in response
> to a good faith attempt.  There is no evidentiary basis to demonstrate that
> new users have a harder time participating in discussion than they do in
> content contribution."

I would go further, reverting newbie edits to talk pages is rare. They may 
occasionally need help with indentation or signing, and if they edit a busy 
page they may get edit conflicts. But unlike in main space actual reversion is 
rare. We do need some system to identify newbie queries that have been left 
longest, as queries on article talk pages can linger for a very long time. But 
we should not treat the need for improvements on talk pages as being as 
pressing as the need to improve the experience for newbies in main space. V/E 
will help a little there, though not till it is ready to be deployed. But there 
are bigger problems, the amount of edit conflicts suffered by the creators of 
new articles and the ongoing train wreck with some of the regulars working to 
the unwritten rule that everything must be verified, while the system doesn't 
even prompt newbies to add a source.

Re Erik's comment "I'm open to us putting some short term effort into talk
> 
>> page improvements that can be made without Flow -- knowing it's still
>> some time out."

That would be great, there are various Won't fix bugs on Bugzilla that should 
be easy to fix. Setting : # and * as paragraph delimiters as far as edit 
conflicts are concerned should resolve a lot of the edit conflicts in talk 
space. Really low hanging fruit.

Regards

Jonathan Cardy


> 

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

Facebook?

So tell me, how do you explain to new Facebook users about the different
levels of "privacy"?  Seems to me that I'm constantly hearing about people
having a lot of problems with that, especially since it's supposed to be a
key site feature.

I'm with you about indenting, it's always been something strange.  But
signing posts is very natural for a lot of people, and many, many online
sites encourage the development of "canned signature lines" - just as we do
with preferences, although we put more constraints on them generally.

Indeed, the majority of people in this thread have signed their posts.
Indeed, Jon Davies' "+1" in response to this post had a 588-character
signature line, presumably added to his mail client preferences.


Risker/Anne



On 8 September 2014 11:43, Ziko van Dijk  wrote:

> Hello,
>
> a) This discussion actually belongs to a talk page on Meta or
> Mediawiki.org, for example :-)
>
> b) All my experience in teaching Wikipedia tells me that the talk page
> system is absolutely outdated and inappropriate. It is, sorry to use this
> word, *ridiculous* that you have to teach people how to communicate
> technically in Wikipedia. I never had to explain to someone how to do that
> on Facebook...
>
> As other people have pointed it out already, if you are already accustomed
> to the Wikipedia user interface for a longer time, you might find it
> difficult to fully understand what is the problem for newbies. And how big
> this is a problem, and how important it is to solve this problem.
>
> Kind regards
> Ziko
>
>
>
> Am Montag, 8. September 2014 schrieb Risker :
>
> > Well, I think that the "article editing" project (i.e., VE)  has a huge
> > potential for also resolving a lot of discussion space issues.  I don't
> see
> > tacking on yet another UI as being a positive for new editor introduction
> > or retention, and cannot think of another significant site that has two
> > such wildly divergent interfaces (one very flexible and the other very
> > rigid in structure), except perhaps in the mobile vs. desktop situation.
> >
> > I dunno, Marc.  There are different expectations about signature,
> depending
> > on the target group.  We still have people being freaked out that article
> > histories contain their username or IP (a form of automatic signature),
> so
> > I'm not convinced that there's an expectation on the part of new users
> that
> > anything they write anywhere will automatically be signed.
> >
> > Risker/Anne
> >
> >
> > On 8 September 2014 10:24, Marc A. Pelletier  > > wrote:
> >
> > > On 09/08/2014 10:18 AM, Risker wrote:
> > > > The most obvious one is automatic signing of comments, and it is
> > > > something that we have technically been able to impose for years;
> > sinebot
> > > > didn't come into existence in a vacuum.
> > >
> > > I suppose that's a philosophical divergence between us then - that
> > > sinebot even needs to exist to me is demonstration that the system is
> > > broken.
> > >
> > > You say that discussion isn't all that much harder than editing
> content.
> > >  Even if I agreed with that (and I do not, edit conflicts in articles
> > > are much rarer than on talk pages - and usually easier to sort out),
> > > that's not a *good* thing!
> > >
> > > Participating in discussion should be much, *much* easier than editing
> > > articles: encouraging newbies to seek help and participate in the
> > > community *before* diving in anything but trivial article edits would
> be
> > > an immensely powerful retention tool!
> > >
> > > (Which isn't to say that editing articles doesn't *also* need a lot of
> > > help - but that's a different project).
> > >
> > > -- Marc
> > >
> > >
> > > ___
> > > Wikimedia-l mailing list, guidelines at:
> > > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> > > Wikimedia-l@lists.wikimedia.org 
> > > <
> >
> https://meta.wikimedia.org/wiki/Mailing_lists/guidelineswikimedi...@lists.wikimedia.org
> > >
> > > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > >  > ?subject=unsubscribe>
> > >
> > ___
> > Wikimedia-l mailing list, guidelines at:
> > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> > Wikimedia-l@lists.wikimedia.org
> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> >  > ?subject=unsubscribe>
> ___
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l@lists.wikimedia.org
> 
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> 
>
___
Wikimedia-

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

[Jon Davies]

+1

On 8 September 2014 16:43, Ziko van Dijk  wrote:

> Hello,
>
> a) This discussion actually belongs to a talk page on Meta or
> Mediawiki.org, for example :-)
>
> b) All my experience in teaching Wikipedia tells me that the talk page
> system is absolutely outdated and inappropriate. It is, sorry to use this
> word, *ridiculous* that you have to teach people how to communicate
> technically in Wikipedia. I never had to explain to someone how to do that
> on Facebook...
>
> As other people have pointed it out already, if you are already accustomed
> to the Wikipedia user interface for a longer time, you might find it
> difficult to fully understand what is the problem for newbies. And how big
> this is a problem, and how important it is to solve this problem.
>
> Kind regards
> Ziko
>
>
>
> Am Montag, 8. September 2014 schrieb Risker :
>
> > Well, I think that the "article editing" project (i.e., VE)  has a huge
> > potential for also resolving a lot of discussion space issues.  I don't
> see
> > tacking on yet another UI as being a positive for new editor introduction
> > or retention, and cannot think of another significant site that has two
> > such wildly divergent interfaces (one very flexible and the other very
> > rigid in structure), except perhaps in the mobile vs. desktop situation.
> >
> > I dunno, Marc.  There are different expectations about signature,
> depending
> > on the target group.  We still have people being freaked out that article
> > histories contain their username or IP (a form of automatic signature),
> so
> > I'm not convinced that there's an expectation on the part of new users
> that
> > anything they write anywhere will automatically be signed.
> >
> > Risker/Anne
> >
> >
> > On 8 September 2014 10:24, Marc A. Pelletier  > > wrote:
> >
> > > On 09/08/2014 10:18 AM, Risker wrote:
> > > > The most obvious one is automatic signing of comments, and it is
> > > > something that we have technically been able to impose for years;
> > sinebot
> > > > didn't come into existence in a vacuum.
> > >
> > > I suppose that's a philosophical divergence between us then - that
> > > sinebot even needs to exist to me is demonstration that the system is
> > > broken.
> > >
> > > You say that discussion isn't all that much harder than editing
> content.
> > >  Even if I agreed with that (and I do not, edit conflicts in articles
> > > are much rarer than on talk pages - and usually easier to sort out),
> > > that's not a *good* thing!
> > >
> > > Participating in discussion should be much, *much* easier than editing
> > > articles: encouraging newbies to seek help and participate in the
> > > community *before* diving in anything but trivial article edits would
> be
> > > an immensely powerful retention tool!
> > >
> > > (Which isn't to say that editing articles doesn't *also* need a lot of
> > > help - but that's a different project).
> > >
> > > -- Marc
> > >
> > >
> > > ___
> > > Wikimedia-l mailing list, guidelines at:
> > > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> > > Wikimedia-l@lists.wikimedia.org 
> > > <
> >
> https://meta.wikimedia.org/wiki/Mailing_lists/guidelineswikimedi...@lists.wikimedia.org
> > >
> > > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > >  > ?subject=unsubscribe>
> > >
> > ___
> > Wikimedia-l mailing list, guidelines at:
> > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> > Wikimedia-l@lists.wikimedia.org
> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> >  > ?subject=unsubscribe>
> ___
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> 




-- 
*Jon Davies - Chief Executive Wikimedia UK*.  Mobile (0044) 7803 505 169
tweet @jonatreesdavies

Wikimedia UK is a Company Limited by Guarantee registered in England and
Wales, Registered No. 6741827. Registered Charity No.1144513. Registered
Office 4th Floor, Development House, 56-64 Leonard Street, London EC2A 4LT.
United Kingdom. Wikimedia UK is the UK chapter of a global Wikimedia
movement. The Wikimedia projects are run by the Wikimedia Foundation (who
operate Wikipedia, amongst other projects).
Telephone (0044) 207 065 0990.

Visit http://www.wikimedia.org.uk/ and @wikimediauk
___
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

[Ziko van Dijk]

Hello,

a) This discussion actually belongs to a talk page on Meta or
Mediawiki.org, for example :-)

b) All my experience in teaching Wikipedia tells me that the talk page
system is absolutely outdated and inappropriate. It is, sorry to use this
word, *ridiculous* that you have to teach people how to communicate
technically in Wikipedia. I never had to explain to someone how to do that
on Facebook...

As other people have pointed it out already, if you are already accustomed
to the Wikipedia user interface for a longer time, you might find it
difficult to fully understand what is the problem for newbies. And how big
this is a problem, and how important it is to solve this problem.

Kind regards
Ziko



Am Montag, 8. September 2014 schrieb Risker :

> Well, I think that the "article editing" project (i.e., VE)  has a huge
> potential for also resolving a lot of discussion space issues.  I don't see
> tacking on yet another UI as being a positive for new editor introduction
> or retention, and cannot think of another significant site that has two
> such wildly divergent interfaces (one very flexible and the other very
> rigid in structure), except perhaps in the mobile vs. desktop situation.
>
> I dunno, Marc.  There are different expectations about signature, depending
> on the target group.  We still have people being freaked out that article
> histories contain their username or IP (a form of automatic signature), so
> I'm not convinced that there's an expectation on the part of new users that
> anything they write anywhere will automatically be signed.
>
> Risker/Anne
>
>
> On 8 September 2014 10:24, Marc A. Pelletier  > wrote:
>
> > On 09/08/2014 10:18 AM, Risker wrote:
> > > The most obvious one is automatic signing of comments, and it is
> > > something that we have technically been able to impose for years;
> sinebot
> > > didn't come into existence in a vacuum.
> >
> > I suppose that's a philosophical divergence between us then - that
> > sinebot even needs to exist to me is demonstration that the system is
> > broken.
> >
> > You say that discussion isn't all that much harder than editing content.
> >  Even if I agreed with that (and I do not, edit conflicts in articles
> > are much rarer than on talk pages - and usually easier to sort out),
> > that's not a *good* thing!
> >
> > Participating in discussion should be much, *much* easier than editing
> > articles: encouraging newbies to seek help and participate in the
> > community *before* diving in anything but trivial article edits would be
> > an immensely powerful retention tool!
> >
> > (Which isn't to say that editing articles doesn't *also* need a lot of
> > help - but that's a different project).
> >
> > -- Marc
> >
> >
> > ___
> > Wikimedia-l mailing list, guidelines at:
> > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> > Wikimedia-l@lists.wikimedia.org 
> > <
> https://meta.wikimedia.org/wiki/Mailing_lists/guidelineswikimedi...@lists.wikimedia.org
> >
> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> >  ?subject=unsubscribe>
> >
> ___
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
>  ?subject=unsubscribe>
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

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

[phoebe ayers]

Thank you for this overview and history, Erik!

On Fri, Sep 5, 2014 at 9:49 PM, Erik Moeller  wrote:

> Hi all,
>
>
> And as above, I'm open to us putting some short term effort into talk
> page improvements that can be made without Flow -- knowing it's still
> some time out.


Is there a good wiki page for brainstorming/discussing these kinds of talk
page improvements (that may or may not be part of Flow?)

I always find it helpful in these kinds of conversations to try and imagine
what concrete changes would help me on a day to day basis, as an editor and
discussion participant, since it can be hard to envision what working with
a whole new system would be like or to wrap one's head around the whole
universe of discussions that take place on talk pages.

best,
-- phoebe

-- 
* I use this address for lists; send personal messages to phoebe.ayers 
gmail.com *
___
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]

Well, I think that the "article editing" project (i.e., VE)  has a huge
potential for also resolving a lot of discussion space issues.  I don't see
tacking on yet another UI as being a positive for new editor introduction
or retention, and cannot think of another significant site that has two
such wildly divergent interfaces (one very flexible and the other very
rigid in structure), except perhaps in the mobile vs. desktop situation.

I dunno, Marc.  There are different expectations about signature, depending
on the target group.  We still have people being freaked out that article
histories contain their username or IP (a form of automatic signature), so
I'm not convinced that there's an expectation on the part of new users that
anything they write anywhere will automatically be signed.

Risker/Anne


On 8 September 2014 10:24, Marc A. Pelletier  wrote:

> On 09/08/2014 10:18 AM, Risker wrote:
> > The most obvious one is automatic signing of comments, and it is
> > something that we have technically been able to impose for years; sinebot
> > didn't come into existence in a vacuum.
>
> I suppose that's a philosophical divergence between us then - that
> sinebot even needs to exist to me is demonstration that the system is
> broken.
>
> You say that discussion isn't all that much harder than editing content.
>  Even if I agreed with that (and I do not, edit conflicts in articles
> are much rarer than on talk pages - and usually easier to sort out),
> that's not a *good* thing!
>
> Participating in discussion should be much, *much* easier than editing
> articles: encouraging newbies to seek help and participate in the
> community *before* diving in anything but trivial article edits would be
> an immensely powerful retention tool!
>
> (Which isn't to say that editing articles doesn't *also* need a lot of
> help - but that's a different project).
>
> -- 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

[Marc A. Pelletier]

On 09/08/2014 10:18 AM, Risker wrote:
> The most obvious one is automatic signing of comments, and it is
> something that we have technically been able to impose for years; sinebot
> didn't come into existence in a vacuum.

I suppose that's a philosophical divergence between us then - that
sinebot even needs to exist to me is demonstration that the system is
broken.

You say that discussion isn't all that much harder than editing content.
 Even if I agreed with that (and I do not, edit conflicts in articles
are much rarer than on talk pages - and usually easier to sort out),
that's not a *good* thing!

Participating in discussion should be much, *much* easier than editing
articles: encouraging newbies to seek help and participate in the
community *before* diving in anything but trivial article edits would be
an immensely powerful retention tool!

(Which isn't to say that editing articles doesn't *also* need a lot of
help - but that's a different project).

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

[Risker]

That's not a reasonable task, Marc.  Newbies have an equally hard time
editing content, too, and even when they succeed, on many projects they're
very likely to be reverted and deluged with templated messages in response
to a good faith attempt.  There is no evidentiary basis to demonstrate that
new users have a harder time participating in discussion than they do in
content contribution. Independent studies seem to identify the nature of
the discussions as being significantly more problematic than the technical
means of participating.

Nobody is saying that it is easy for newbies to participate on many of the
larger Wikimedia projects.  There are lots of ways that we can make it
easier.  The most obvious one is automatic signing of comments, and it is
something that we have technically been able to impose for years; sinebot
didn't come into existence in a vacuum.

Risker/Anne



On 8 September 2014 09:58, Marc A. Pelletier  wrote:

> On 09/08/2014 12:46 AM, John Mark Vandenberg wrote:
> > While it may not be everybody's dream system, talk pages are quite
> > usable, as demonstrated by a lot of people using them every single
> > day.
>
> That's... not a demonstration of usability.  Like many people, I found
> myself using some random blunt object not designed for purpose to hammer
> in a nail at least once; that speaks to the importance of getting the
> nail in, not the lack of need for a proper hammer.  :-)
>
> Let's be honest here; I'm /highly/ computer-literate, and I've been
> using Mediawiki for some 11 years and I *still* find talk pages an
> annoyance at the best of times and they can be downright painful if
> there's anything like a large discussion in progress you are attempting
> to track/participate in.  Between edit conflicts, increasingly confusing
> indentation, signatures that may or may not make separation between
> commenters clear...  It's no surprise that newbies are scared away.
> Editing articles is already hard enough, anything that provides an extra
> barrier to participation hurts - especially when that barrier lies in
> the way of getting /help/.
>
> Talk pages, as a mechanism, are lacking every affordance that users
> expect of a communication medium.  And no, that X thousand people have
> gotten used to their failings does not make them any better for the Y
> billion people that have not.
>
> But don't take my word for it!  Find random newbies, and ask them to try
> the simple task of commenting on a discussion in progress without giving
> them guidance.  They they flail around, or simply give up, remember that
> it's not /them/ who have failed -- I'm pretty sure they've participated
> in plenty of other online discussions before.
>
> -- 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

[Marc A. Pelletier]

On 09/08/2014 12:46 AM, John Mark Vandenberg wrote:
> While it may not be everybody's dream system, talk pages are quite
> usable, as demonstrated by a lot of people using them every single
> day.

That's... not a demonstration of usability.  Like many people, I found
myself using some random blunt object not designed for purpose to hammer
in a nail at least once; that speaks to the importance of getting the
nail in, not the lack of need for a proper hammer.  :-)

Let's be honest here; I'm /highly/ computer-literate, and I've been
using Mediawiki for some 11 years and I *still* find talk pages an
annoyance at the best of times and they can be downright painful if
there's anything like a large discussion in progress you are attempting
to track/participate in.  Between edit conflicts, increasingly confusing
indentation, signatures that may or may not make separation between
commenters clear...  It's no surprise that newbies are scared away.
Editing articles is already hard enough, anything that provides an extra
barrier to participation hurts - especially when that barrier lies in
the way of getting /help/.

Talk pages, as a mechanism, are lacking every affordance that users
expect of a communication medium.  And no, that X thousand people have
gotten used to their failings does not make them any better for the Y
billion people that have not.

But don't take my word for it!  Find random newbies, and ask them to try
the simple task of commenting on a discussion in progress without giving
them guidance.  They they flail around, or simply give up, remember that
it's not /them/ who have failed -- I'm pretty sure they've participated
in plenty of other online discussions before.

-- 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,
Pine, I would like so many things.. I expect that SUL and more goodliness
from this will be a requirement. For me there is urgency in having a
discussion system that works for mobiles and templates...

Once we have that we either have other priorities or it is a really good
idea to be implemented while developers know Flow intimately well..
Thanks,
 GerardM

On 8 September 2014 09:46, Pine W  wrote:

> A problem that I would like Flow to solve is the high amount of labor
> needed to read over a dozen pages across four wikis in order for the reader
> to access most of the MediaViewer discussions.
>
> Pine
> On Sep 8, 2014 12:22 AM, "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.)
> >
> >
> > - d.
> >
> > ___
> > Wikimedia-l mailing list, guidelines at:
> > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> > Wikimedia-l@lists.wikimedia.org
> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > 
> ___
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> 
>
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

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

[Diego Moya]

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

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

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

___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

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

[Diego Moya]

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

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

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

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

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


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

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

[Pine W]

A problem that I would like Flow to solve is the high amount of labor
needed to read over a dozen pages across four wikis in order for the reader
to access most of the MediaViewer discussions.

Pine
On Sep 8, 2014 12:22 AM, "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.)
>
>
> - 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

[David Gerard]

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


- 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

[Gerard Meijssen]

Hoi,
You missed the multiple discussion pages in all the "other" languages. They
are certainly as observant, as eloquent and they have different use cases
and issues as well.
Thanks,
 GerardM


On 8 September 2014 06:26, Wil Sinclair  wrote:

> I composed the following as part of a longer message, but I decided
> not to send it unless others were having similar issues since I'm on
> track to exceed my monthly allowance of posts here ;):
>
> "
> There's one thing in this discussion that troubles me greatly.
>
> We've got a treasure trove of information/feedback in this thread from
> some of the people who are most knowledgable about the software and
> the problems it's trying to solve. Are we sure we're capturing all of
> the take-aways somewhere? How about the unresolved concerns? Is
> anything getting lost in transient discussions here or elsewhere?
>
> I set out to answer this myself.
>
> First, I looked for the talk page on Flow. Here it is:
>
> https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Flow&action=history
> The first things to strike me are that it is very long, very active,
> very unstructured, and archived across 10 pages and counting. Hmmm.
> Same questions as above, applied to exponentially more threads.
>
> Next, I went to bugzilla:
>
> https://bugzilla.wikimedia.org/buglist.cgi?component=Flow&list_id=342315&product=MediaWiki&product=MediaWiki%20extensions&product=Wikimedia
> . Much more structured and captures some requirements in a workflow.
> Not so good for discussing higher-level issues, however. Moreover,
> that doesn't seem to be what the development team is keeping their
> backlog in. Off to trello. . .
>
> I'm an experienced development manager that has been evangelizing
> agile programming of all stripes since 2001, and it took my searching
> the Flow talk page and clicking on a specific task to figure out how
> to list the backlog in trello. I think this is the right link in case
> you're looking for it yourself:
> https://trello.com/b/HD0lBssr/flow-backlog. A lot of these items link
> back to bugzilla and to another Flow discussion page. . .
>
> . . .on the MediaWiki site conducted in Flow itself:
> https://www.mediawiki.org/wiki/Talk:Flow. I think I'll stop here,
> although there are more places where Flow is discussed, and I haven't
> even gotten in to the mainspace pages that are edited by the Wikimedia
> and MediaWiki developers to communicate outwards to the broader
> community.
> "
>
> The summary of the tl;dr version is that it seems like there are
> opportunities to improve the discussion of Flow, starting with
> conducting it in fewer places and adding all takeaways as requirements
> to a workflow we can all track. The next step would be a discussion
> around prioritizing these requirements. Has this been done for Flow
> with full community involvement? If not, I think the WMF should take
> the lead on this one and show the community that it has taken the
> lessons from the recent MV experience and other poorly received
> rollouts to heart.
>
> WMF, I appeal to you directly when I ask you to get us more involved,
> and, moreover, get us more invested in the success of Flow starting
> now by leading a discussion too many on this list and elsewhere have
> said hasn't happened and/or hasn't been heeded.
>
> ,Wil
>
> On Sun, Sep 7, 2014 at 7:28 PM, Craig Franklin
>  wrote:
> > Hi,
> >
> > Is there a page somewhere where I can see a detailed functional
> > specification of this product, showing how it'll work, what
> > functions/features it will include in it's MVP state, and such?  I know
> > about the page on Mediawiki ( https://www.mediawiki.org/wiki/Flow ) that
> > talks about things in generalities and answers some specific questions in
> > the FAQ, but I've not been able to locate any document that tells me
> > exactly what it will *do*.
> >
> > I have to confess that I'm not entirely confident that the rollout of
> Flow
> > will be any smoother than the rollout of Visual Editor or MediaViewer,
> > largely because I'm not entirely confident of what it is that I'm
> supposed
> > to be getting.  I'd be delighted to be corrected on this point if there
> is
> > something out there that I've missed.
> >
> > Cheers,
> > Craig
> >
> > On 6 September 2014 14:49, Erik Moeller  wrote:
> >
> >> Hi all,
> >>
> >> I'm breaking out this discussion about Flow/talk pages (apologies for
> >> repeatedly breaking the megathread, but this is a well-scoped subject
> >> which deserves its own thread).
> >>
> >> Fundamentally, there's one key question to answer for talk pages in
> >> Wikimedia projects: Do we want discussions to occur in document mode,
> >> or in a structured comment mode? All else flows from there (pun
> >> intended).
> >>
> >> == Document mode ==
> >>
> >> There are not many examples of document mode discussion systems beyond
> >> wikis. You sometimes see people use collaborative realtime editors as
> >> such, because people want to talk in the same space wher

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

[Gerard Meijssen]

Hoi,
There are two ways to look at the talk systems. It served us so far to some
extend. It has been considered in need of replacement for a long time and
consequently we have systems like Liquid Threads that are arguably at least
as good in many use cases and fail in others.

The other way to look at tit is to see it fail on what is becoming
increasingly the platform of our readers and our new editors; the mobile
and the tablet. On those platforms talk pages are a disaster, an utter
failure. This realisation that these types of devices are our future make
it imperative to move away from our talk pages as soon as possible.

We do not have the time to procrastinate and we do not have time for
continued deliberations of how nice it would be if we could do it all over
again. As it is, we have a team of developers working on Flow. They are
committed to consider the many use cases that exist in our community but in
the end, fixing those will increasingly become an exercise in diminishing
returns given the need to support our readers and editors on mobiles and
tablets. The cost is not in the time of the development team, it is not in
functionality we really want it is in supporting the growing percentage of
people that do NOT use computers.

The question to ask is: who do we do it for,
Thanks,
   GerardM


On 8 September 2014 06:13, Risker  wrote:

> On 7 September 2014 23:54, Marc A. Pelletier  wrote:
>
> > On 09/07/2014 01:57 AM, Diego Moya wrote:
> > > a major property of a document-centric architecture that is lost in a
> > > structured one is that it's open-ended, which means that end users can
> > > build new features and flows on top of it, without the need to request
> > the
> > > platform developers to build support for them (sometimes even without
> > > writing new software at all; new workflows can be designed and
> maintained
> > > purely through social convention).
> >
> > And yet, after over a decade of open-ended design through social
> > convention, the end result is...  our current talk pages.  Perhaps
> > another decade or two will be needed before that document-centric
> > architecture gives us a half-decent discussion system?
> >
> > Sorry if that sound snarky, but I have difficulty buying an argument
> > that the current system has the potential to suffice when it has
> > demonstrably already failed.  It does no good to have the hypothetical
> > capacity for a good system if, in practice, it's unusable.
> >
> > -- Marc
> >
> >
> I suppose the question really is, has it failed?  On what basis are we
> saying that our current discussion system is unusable?
>
> Simply put, I'd suggest that the problem isn't the system, it's the
> discussion process itself that has points of failure.  The replacement of
> actual discussion with templates is a point of failure, and that will not
> be improved by a change in the platform if all that happens is we use
> basically the same templates to have the same non-discussions.  Nothing in
> the technology, either document-based or open-ended, will change the nature
> of the discourse itself; rude people will still be rude, erudite people
> will still be erudite, and none of will change the snark on Jimbo Wales's
> talk page. A significant percentage of Wikimedians rarely use talk pages at
> all (and a goodly number of those identify as exopedians), but no evidence
> that the percentage of Wikimedians who eschew social interaction has
> changed significantly, or that those with a low level of contribution to
> discussion space are doing so because they find the *technology*
> unappealing.
>
> 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,
> 
>
___
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 8 September 2014 00:46, John Mark Vandenberg  wrote:




> .  e.g. once it is
> beta quality, I am sure Jimmy Wales will want it enabled on his user
> talk page, which would increase exposure to, and acceptance of, Flow.
>
>

...or possibly far less complaining on his page.  :-)

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

[John Mark Vandenberg]

On Mon, Sep 8, 2014 at 1:54 PM, Marc A. Pelletier  wrote:
> On 09/07/2014 01:57 AM, Diego Moya wrote:
>> a major property of a document-centric architecture that is lost in a
>> structured one is that it's open-ended, which means that end users can
>> build new features and flows on top of it, without the need to request the
>> platform developers to build support for them (sometimes even without
>> writing new software at all; new workflows can be designed and maintained
>> purely through social convention).
>
> And yet, after over a decade of open-ended design through social
> convention, the end result is...  our current talk pages.  Perhaps
> another decade or two will be needed before that document-centric
> architecture gives us a half-decent discussion system?

Or maybe it will take a decade to deliver a discussion-centric system
that meets the needs of our community to replace the document-centric
discussion system we currently have.

> Sorry if that sound snarky, but I have difficulty buying an argument
> that the current system has the potential to suffice when it has
> demonstrably already failed.  It does no good to have the hypothetical
> capacity for a good system if, in practice, it's unusable.

While it may not be everybody's dream system, talk pages are quite
usable, as demonstrated by a lot of people using them every single
day.

I am all for the addition of a discussion system, effectively the next
iteration of Liquid Threads, but it worries me to see the *deployment*
objectives are already articulated in annual plans to be complete
replacement of all talk pages in 2015.

This potential problematic deploy could be very easily de-escalated by
a WMF decision that Flow will not be forcibly deployed onto an
unwilling project, and can be deployed per-page.  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.  e.g. once it is
beta quality, I am sure Jimmy Wales will want it enabled on his user
talk page, which would increase exposure to, and acceptance of, Flow.

-- 
John Vandenberg

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

I composed the following as part of a longer message, but I decided
not to send it unless others were having similar issues since I'm on
track to exceed my monthly allowance of posts here ;):

"
There's one thing in this discussion that troubles me greatly.

We've got a treasure trove of information/feedback in this thread from
some of the people who are most knowledgable about the software and
the problems it's trying to solve. Are we sure we're capturing all of
the take-aways somewhere? How about the unresolved concerns? Is
anything getting lost in transient discussions here or elsewhere?

I set out to answer this myself.

First, I looked for the talk page on Flow. Here it is:
https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Flow&action=history
The first things to strike me are that it is very long, very active,
very unstructured, and archived across 10 pages and counting. Hmmm.
Same questions as above, applied to exponentially more threads.

Next, I went to bugzilla:
https://bugzilla.wikimedia.org/buglist.cgi?component=Flow&list_id=342315&product=MediaWiki&product=MediaWiki%20extensions&product=Wikimedia
. Much more structured and captures some requirements in a workflow.
Not so good for discussing higher-level issues, however. Moreover,
that doesn't seem to be what the development team is keeping their
backlog in. Off to trello. . .

I'm an experienced development manager that has been evangelizing
agile programming of all stripes since 2001, and it took my searching
the Flow talk page and clicking on a specific task to figure out how
to list the backlog in trello. I think this is the right link in case
you're looking for it yourself:
https://trello.com/b/HD0lBssr/flow-backlog. A lot of these items link
back to bugzilla and to another Flow discussion page. . .

. . .on the MediaWiki site conducted in Flow itself:
https://www.mediawiki.org/wiki/Talk:Flow. I think I'll stop here,
although there are more places where Flow is discussed, and I haven't
even gotten in to the mainspace pages that are edited by the Wikimedia
and MediaWiki developers to communicate outwards to the broader
community.
"

The summary of the tl;dr version is that it seems like there are
opportunities to improve the discussion of Flow, starting with
conducting it in fewer places and adding all takeaways as requirements
to a workflow we can all track. The next step would be a discussion
around prioritizing these requirements. Has this been done for Flow
with full community involvement? If not, I think the WMF should take
the lead on this one and show the community that it has taken the
lessons from the recent MV experience and other poorly received
rollouts to heart.

WMF, I appeal to you directly when I ask you to get us more involved,
and, moreover, get us more invested in the success of Flow starting
now by leading a discussion too many on this list and elsewhere have
said hasn't happened and/or hasn't been heeded.

,Wil

On Sun, Sep 7, 2014 at 7:28 PM, Craig Franklin
 wrote:
> Hi,
>
> Is there a page somewhere where I can see a detailed functional
> specification of this product, showing how it'll work, what
> functions/features it will include in it's MVP state, and such?  I know
> about the page on Mediawiki ( https://www.mediawiki.org/wiki/Flow ) that
> talks about things in generalities and answers some specific questions in
> the FAQ, but I've not been able to locate any document that tells me
> exactly what it will *do*.
>
> I have to confess that I'm not entirely confident that the rollout of Flow
> will be any smoother than the rollout of Visual Editor or MediaViewer,
> largely because I'm not entirely confident of what it is that I'm supposed
> to be getting.  I'd be delighted to be corrected on this point if there is
> something out there that I've missed.
>
> Cheers,
> Craig
>
> On 6 September 2014 14:49, Erik Moeller  wrote:
>
>> Hi all,
>>
>> I'm breaking out this discussion about Flow/talk pages (apologies for
>> repeatedly breaking the megathread, but this is a well-scoped subject
>> which deserves its own thread).
>>
>> Fundamentally, there's one key question to answer for talk pages in
>> Wikimedia projects: Do we want discussions to occur in document mode,
>> or in a structured comment mode? All else flows from there (pun
>> intended).
>>
>> == Document mode ==
>>
>> There are not many examples of document mode discussion systems beyond
>> wikis. You sometimes see people use collaborative realtime editors as
>> such, because people want to talk in the same space where they work,
>> but Google Docs provided alternatives (a pretty powerful
>> comments/margin system and built-in chat) early on, for example.
>>
>> The current talk page system is a document mode system. Individual
>> comments have unclear boundaries (a single transaction can result in
>> multiple comments, signed or unsigned; indentation levels are
>> unpredictable and often inconsistent). All the joys and pain points of
>> working on the sam

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

[Todd Allen]

On Sun, Sep 7, 2014 at 9:54 PM, Marc A. Pelletier  wrote:

> On 09/07/2014 01:57 AM, Diego Moya wrote:
> > a major property of a document-centric architecture that is lost in a
> > structured one is that it's open-ended, which means that end users can
> > build new features and flows on top of it, without the need to request
> the
> > platform developers to build support for them (sometimes even without
> > writing new software at all; new workflows can be designed and maintained
> > purely through social convention).
>
> And yet, after over a decade of open-ended design through social
> convention, the end result is...  our current talk pages.  Perhaps
> another decade or two will be needed before that document-centric
> architecture gives us a half-decent discussion system?
>

I don't see talk pages as not being a half-decent discussion system. They
support a lot more functionality than simple threaded discussion, so
forum-style or social media-style software won't work for them. They
provide a flexible system that allows them to serve the purpose of hosting
discussions as well as a significant number of other functions.


>
> Sorry if that sound snarky, but I have difficulty buying an argument
> that the current system has the potential to suffice when it has
> demonstrably already failed.


You said demonstrably, so I'm going to ask you to demonstrate it. What
basis do you have for saying it's failed?


> It does no good to have the hypothetical
> capacity for a good system if, in practice, it's unusable.
>

Sure, that statement is true, but it's irrelevant here given that a system
used thousands upon thousands of times a day can hardly be called unusable.

Todd
___
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 7 September 2014 23:54, Marc A. Pelletier  wrote:

> On 09/07/2014 01:57 AM, Diego Moya wrote:
> > a major property of a document-centric architecture that is lost in a
> > structured one is that it's open-ended, which means that end users can
> > build new features and flows on top of it, without the need to request
> the
> > platform developers to build support for them (sometimes even without
> > writing new software at all; new workflows can be designed and maintained
> > purely through social convention).
>
> And yet, after over a decade of open-ended design through social
> convention, the end result is...  our current talk pages.  Perhaps
> another decade or two will be needed before that document-centric
> architecture gives us a half-decent discussion system?
>
> Sorry if that sound snarky, but I have difficulty buying an argument
> that the current system has the potential to suffice when it has
> demonstrably already failed.  It does no good to have the hypothetical
> capacity for a good system if, in practice, it's unusable.
>
> -- Marc
>
>
I suppose the question really is, has it failed?  On what basis are we
saying that our current discussion system is unusable?

Simply put, I'd suggest that the problem isn't the system, it's the
discussion process itself that has points of failure.  The replacement of
actual discussion with templates is a point of failure, and that will not
be improved by a change in the platform if all that happens is we use
basically the same templates to have the same non-discussions.  Nothing in
the technology, either document-based or open-ended, will change the nature
of the discourse itself; rude people will still be rude, erudite people
will still be erudite, and none of will change the snark on Jimbo Wales's
talk page. A significant percentage of Wikimedians rarely use talk pages at
all (and a goodly number of those identify as exopedians), but no evidence
that the percentage of Wikimedians who eschew social interaction has
changed significantly, or that those with a low level of contribution to
discussion space are doing so because they find the *technology*
unappealing.

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

[Marc A. Pelletier]

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

And yet, after over a decade of open-ended design through social
convention, the end result is...  our current talk pages.  Perhaps
another decade or two will be needed before that document-centric
architecture gives us a half-decent discussion system?

Sorry if that sound snarky, but I have difficulty buying an argument
that the current system has the potential to suffice when it has
demonstrably already failed.  It does no good to have the hypothetical
capacity for a good system if, in practice, it's unusable.

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

[Wil Sinclair]

Let me begin with this: my preferences lie far closer to yours,
Gerard, than Diego's. I believe that we have a document oriented
system that works well for stuff like encyclopedic content. But I
think that we should be conducting our discussions in a discussion
oriented system. That doesn't necessarily mean more structure- after
all, Wikipedia pages are almost always highly structured documents-
but it certainly requires '''different''' structure that might be
enforced by software as opposed to editorial convention.

> The central point  Diego made starts from is that the current broken system
> has a POTENTIAL for unstructured, unaccountable changes by whomever.
>
> You do not build on a fundament that is collapsing as it is. A system that
> is manifestly broken particularly on the one platform where our new users
> are; mobile.

I think Diego has a great point. By relying on software to enforce
structure in our discussions, we will rely more on the developers.
Let's take something that we all have a stake in as an example. In the
beginning, there will be inevitably be bugs as the system is rolled
out, and we will rely on the developers to fix them. Without the
flexibility of our document oriented system, there may be no
workarounds. That is something that may be mitigated with more
flexibility built in to the system.

Diego touches on the need for flexibility within the discussion for
many use cases, and I don't consider any of his requirements mutually
exclusive with a discussion oriented system, as such. He seems to
believe that we haven't held sufficient discussion on critical issues
like the right tradeoff between flexibility for editors and structure
for discussions. This sentiment has been expressed by several
Wikipedians in this forum.

Without broad consensus that this discussion has been held, and the
WMF has turned legitimate and sensible community needs and desires in
to Flow requirements, Flow will not succeed. If Diego's sentiment is
shared by a significant contingent of Wikipedians, we need to back up
and do this right. No biggies. It's far more important to have the
community invested in the success of Flow than to work towards
deadlines. If we're concerned about getting this done soon for use
cases such as those for mobile, we can accelerate the schedule as a
community by helping the WMF. There is no shortage of opportunities to
help at all levels of technical expertise.

> If we are to take arguments seriously, please explain why we should in this
> instance. If dismissing such ideas makes him go away AFTER it has been
> explained why the arguments do not wash.. Well, the best that can be said
> is that it makes the conversation easier, it does not change the quality of
> the arguments at all.

Even if I were to disagree with Diego on certain issues, I won't be
dismissing his ideas. Not because I want to recruit him as some sort
of ally for the next battle. And not because dismissing them will not
make these ideas go away, tho that is a very good reason not to
dismiss them. I won't be dismissing them because Diego is a thoughtful
Wikipedian, and all Wikipedians deserve respect and a chance to be
heard out.

As a post script, I see that Diego wrote a thorough and de-escalating
response. Huge +1 from me on that score. And then he did something
that only the strongest of souls seem to be able to do: he apologized
publicly for something he felt he could have done better. Diego, you
have my deepest respect, and please keep on keeping on in this forum
and elsewhere.

,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

[Craig Franklin]

Hi,

Is there a page somewhere where I can see a detailed functional
specification of this product, showing how it'll work, what
functions/features it will include in it's MVP state, and such?  I know
about the page on Mediawiki ( https://www.mediawiki.org/wiki/Flow ) that
talks about things in generalities and answers some specific questions in
the FAQ, but I've not been able to locate any document that tells me
exactly what it will *do*.

I have to confess that I'm not entirely confident that the rollout of Flow
will be any smoother than the rollout of Visual Editor or MediaViewer,
largely because I'm not entirely confident of what it is that I'm supposed
to be getting.  I'd be delighted to be corrected on this point if there is
something out there that I've missed.

Cheers,
Craig

On 6 September 2014 14:49, Erik Moeller  wrote:

> Hi all,
>
> I'm breaking out this discussion about Flow/talk pages (apologies for
> repeatedly breaking the megathread, but this is a well-scoped subject
> which deserves its own thread).
>
> Fundamentally, there's one key question to answer for talk pages in
> Wikimedia projects: Do we want discussions to occur in document mode,
> or in a structured comment mode? All else flows from there (pun
> intended).
>
> == Document mode ==
>
> There are not many examples of document mode discussion systems beyond
> wikis. You sometimes see people use collaborative realtime editors as
> such, because people want to talk in the same space where they work,
> but Google Docs provided alternatives (a pretty powerful
> comments/margin system and built-in chat) early on, for example.
>
> The current talk page system is a document mode system. Individual
> comments have unclear boundaries (a single transaction can result in
> multiple comments, signed or unsigned; indentation levels are
> unpredictable and often inconsistent). All the joys and pain points of
> working on the same document are present (a heavily trafficked talk
> page will see many edit conflicts). You can't easily show comments in
> multiple contexts (cross-wiki, via email, as a notification, etc.)
> because of the boundary problem.
>
> You could try to make a document mode system work better. On the basis
> of wikitext, you can do some very basic things, like the "new section"
> link I added to MediaWiki back in July 2003 [1], when I wrote: "This
> feature could also be the first stage of a more sophisticated
> discussion system, where the next stage would be auto-appending
> signatures and providing a 'Reply to this' link after each comment."
>
> But due to the aforementioned unpredictability, even making a "reply"
> link work consistently (and do the right thing) is non-trivial. You
> can get some of the way there, and the Wikipedia Teahouse actually has
> a gadget, written by Andrew Garrett (more on him below) that does
> precisely that.
>
> https://en.wikipedia.org/wiki/Wikipedia:Teahouse/Questions
>
> Note the "Join this discussion" link. It does give you a pop-up, and
> posts the comment for you in the right place, with indentation (it
> does not auto-sign, but instead tries to teach users the signature
> habit which they'll need to use on other talk pages).
>
> It may be worth doing more research and development on this, to see
> just how far we can get without changing the fundamentals, since a
> wholly new system may still be years out for wide use. However, there
> are inherent limitations due to the lack of a predictable and
> consistent structure.
>
> You could go further down the road of a document mode or hybrid
> system, but IMO not without introducing fully predictable comment
> markers (think Bla ~~~) -- which would
> pollute the wikitext, be fragile (e.g. accidental or deliberate
> corruption of identifiers), and probably be considered unacceptable in
> a system that still supports unlimited wikitext editing for those
> reasons.
>
> == Structured ==
>
> I personally gave up on patchwork on top of talk pages about 10 years
> ago. The advantages of having comments clearly identified as such are
> many:
>
> - Display comments in arbitrary order, arbitrary threading style
> - Search comments across date ranges
> - Search comments by author
> - Track comments as comments, not as diffs
> - Monitor changes at any part of a comment thread
> - Display comments independent of a given document (e.g. email,
> cross-wiki, etc.)
> - Display comment metadata in different formats easily (e.g. timestamps)
> - Update author names after a username change without having to update
> documents
> - Enables third parties to build new UIs (think Wikiwand for comments)
> more easily
> - Ability to tag/categorize individual comments/threads
> - and more.
>
> I identified some of these reasons when I wrote the proposal for
> LiquidThreads in October 2004 [2]. At that point, the Wikimedia
> Foundation had 0 employees, and this was too large an effort to likely
> get traction just from ad hoc volunteering. So after some time, I
> managed

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

[Diego Moya]

...and having said and sent that previous post, I want to publicly
apologize for the third paragraph counting from the end. That was uncalled
for.
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

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

[Diego Moya]

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

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

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

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

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



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

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

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

Please assume good faith and try to listen to what people who care deeply
about the project have to say. I believe that the end result of building an
understanding, from the very different starting points that are held by the
debaters, will benefit the project deeply and will allow for a much more
robust tool that any other way to proceed.
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

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

[Gerard Meijssen]

Hoi,
It is fine to disagree. What is lacking in your vision is a viable
alternative and, as you acknowledge the current system is no longer viable
we are in need of an alternative now. Your notions are yours and that is
fine. However, we are not a debating club really. My point is very much
that in Flow we have a project that is actively developed. It is based on
the lessons learned with the current talk pages and Liquid Threads. The
process of development includes community consultation and it has a chance
of delivering something viable in the near future.

To be honest, I do not care at all that you have another vision. It lacks
reality, it lacks a way forward. Get real and look what Flow is and how it
can be improved. Check out the use cases it works for and acknowledge the
achievements. THEN and only THEN consider the features that are being
tested and are still deficient. THEN and only THEN point out how we can
move forward and make it work better. THEN and only THEN can you lament
what we may lose what you liked in Talk pages.

We have to move forward and there is no time to start anew. So blame me
because I am harsh about your notions. I do not care for them, they are in
the way. However, please consider our need. We are moving more and more
towards mobile readers and editors and talk pages just do not cut it. We
need something better for these use cases and, we need them urgently.
Thanks,
 GerardM


On 7 September 2014 11:14, Diego Moya  wrote:

> Gerard, with all due respect, your reply is all based on incorrect
> assumptions. I recognize the severe problems that mediawiki conversations
> currently have, and my points about Flow acknowledge that it's incomplete
> software at its early stages and that it can grow into an acceptable tool
> for having discussions, but all that is irrelevant to the conversation
> that's going on at this thread.
>
> Both Erik and I are talking about what we expect a finished, full featured
> software would look like in the end, and we have both dismissed the current
> status of either tool. The idea that I want the new system to be based on
> current existing software is a strawman; that's not what I defend. I want a
> good, modern document-centric software even if it requires building
> something like mediawiki from scratch. This is a high level view of what
> either model can grow into if enough resources are poured into it.
>
> Erik has this vision that building a stable and easy-to-use system
> requires abandoning the open-ended nature of wiki systems, with which I
> disagree, and has committed us to a project with that result in the end, to
> build a very good architecture that will solve the wrong problem. From the
> conversation so far, I believe such view to be based on an incomplete
> understanding of the community needs, and I'm trying to steer the
> conversation to take into account perspectives from the wider community
> rather than the gut feelings of just one man, no matter how much experience
> he has with the project.
>
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

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

[Diego Moya]

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

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

Erik has this vision that building a stable and easy-to-use system requires
abandoning the open-ended nature of wiki systems, with which I disagree,
and has committed us to a project with that result in the end, to build a
very good architecture that will solve the wrong problem. From the
conversation so far, I believe such view to be based on an incomplete
understanding of the community needs, and I'm trying to steer the
conversation to take into account perspectives from the wider community
rather than the gut feelings of just one man, no matter how much experience
he has with the project.
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

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

[Gerard Meijssen]

Hoi,
The central point  Diego made starts from is that the current broken system
has a POTENTIAL for unstructured, unaccountable changes by whomever.

You do not build on a fundament that is collapsing as it is. A system that
is manifestly broken particularly on the one platform where our new users
are; mobile.

If we are to take arguments seriously, please explain why we should in this
instance. If dismissing such ideas makes him go away AFTER it has been
explained why the arguments do not wash.. Well, the best that can be said
is that it makes the conversation easier, it does not change the quality of
the arguments at all.
Thanks,
  GerardM


On 7 September 2014 09:55, Wil Sinclair  wrote:

> > Your suggestion is to be dismissed with prejudice because it is so
> > obviously wrong in so many ways.. I do not care about a possible
> potential
> > of a broken system at all I may want to think about features that are
> > actively used in this broken system.
> > Thanks,
> >   GerardM
>
> I won't be dismissing it, because Diego makes some very good points
> and articulates the concerns that many in the community have expressed
> well.
>
> Dismissing his ideas won't make them go away. I just hope that
> dismissing them with that prejudice you mentioned doesn't make him go
> away.
>
> ,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,
> 
>
___
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]

> Your suggestion is to be dismissed with prejudice because it is so
> obviously wrong in so many ways.. I do not care about a possible potential
> of a broken system at all I may want to think about features that are
> actively used in this broken system.
> Thanks,
>   GerardM

I won't be dismissing it, because Diego makes some very good points
and articulates the concerns that many in the community have expressed
well.

Dismissing his ideas won't make them go away. I just hope that
dismissing them with that prejudice you mentioned doesn't make him go
away.

,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

[Gerard Meijssen]

Hoi,
As it is the current talk pages are horrible. You gloss over this fact
because you are so fired up about the potential of "end users can
build new features and flows on top of it, without the need to request
the platform
developers to build support for them". Then you attack flow because some
specifications are not there yet. In a previous mail it was said that much
of the UI is very much under development, any discussion is to be taken
with a table spoon of salt.

REALLY the current talk system is horrible on desktops, it is atrocious on
mobiles. Your suggestion is to be dismissed with prejudice because it is so
obviously wrong in so many ways.. I do not care about a possible potential
of a broken system at all I may want to think about features that are
actively used in this broken system.
Thanks,
  GerardM


On 7 September 2014 07:57, Diego Moya  wrote:

> > These are just assertions, however. I liked your earlier comments
> > because they are testable against the architecture (even if the
> > current implementation, early as it is, will fail many of these
> > tests). What real world needs cannot be met by a comment-centric
> > architecture for .. commenting? How important are they?
> >
>
> Erik, a major property of a document-centric architecture that is lost in a
> structured one is that it's open-ended, which means that end users can
> build new features and flows on top of it, without the need to request the
> platform developers to build support for them (sometimes even without
> writing new software at all; new workflows can be designed and maintained
> purely through social convention).
>
> That's not something that's easy to do when the basic raw material for
> communication is split into comments and compartmentalized as table records
> with different owners. Such change means that a community that now can
> handle their own growth is made to utterly depend on the developers as
> gatekeepers for its expansion. In a project where the development team is
> understaffed, that's not a healthy proposition.
>
> Sure, you have proposed a Workflow management system in the works, but with
> all respect that's pie in the sky. That possibility is under-specified,
> would require a lot of research and development with unclear goals and
> requirements, and there's no guarantee that it would ever be fit for the
> purpose. Please understand why we are wary of such proposal as the solution
> for all the flexibility requirements.
>
> Sincerely, it looks like you have this grand vision on how a comment
> platform should work, and there's this blind spot to it. Despite repeated
> attempts by several experienced editors trying to explain to you how this
> architectural change would affect the essence of the project smooth
> operation and well-being, you dismiss them by focusing on a single feature
> at a time and missing the forest for the trees.
>
> The point is not how we could replicate this or that feature on Flow, it's
> how we allow support for all future workflows that we don't know about yet,
> without requiring that software changes are made to the platform for each
> new need. We know that Wiki systems are valid platforms to support such
> expansion requirements, because we have seen them working; but we don't
> know how the structured architecture will behave, and there's no reason to
> believe it would work - no other structured system have achieved anything
> similar. You ask "how important are these needs"? I tell you they are
> *essential* to the community; the existing encyclopedia couldn't have been
> built without this openness.
>
> You asked Todd to make requirements that are testable against the
> architecture. Well, I have one: how well does it allow end-users to build
> new unforeseen workflows without requiring development of ad-hoc software
> and changes to the platform?
>
> I hope you give consideration to this argument before dismissing it as
> inconsequential. So far it seems that the decision has already been made
> and that your question ("Do we want discussions to occur in document mode,
> or
> in a structured comment mode?") is rhetorical. I hope that this happens not
> to be true, and the decision is still open to debate from the community.
> ___
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> 
>
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

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

[Diego Moya]

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

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

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

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

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

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

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

I hope you give consideration to this argument before dismissing it as
inconsequential. So far it seems that the decision has already been made
and that your question ("Do we want discussions to occur in document mode, or
in a structured comment mode?") is rhetorical. I hope that this happens not
to be true, and the decision is still open to debate from the community.
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] To Flow or not to Flow -> it does not flow

[Pine W]

Tim, I read that a bit differently.

"Flow is an *experimental* but already feature
rich alternative..."

"We will aim to cover one major set of new deployments per quarter,
*carefully picking use cases*."

This looks to me like the kind of incremental rollout that is appropriate.
The idea of users opting into Flow on their personal talk pages would also
be a good development for testing purposes.

I think Lila may also have some ideas about how to stage rollouts and
integrate user feedback into the development process early and often.

Pine


On Sat, Sep 6, 2014 at 8:34 PM, Tim Davenport  wrote:

> Erik Möller wrote:
>
> >> It's [Flow is] a system in early development, and has never been
> advertised as anything else.
>
> ==
>
> *This statement is simply not true.*
>
> See the WMF's 2014-15 annual plan:
> https://archive.org/details/WikimediaFoundation2014-15AnnualPlan
>
> Page 20 (DIRECT QUOTE FOLLOWS):
>
> *FLOW*
>
> * Current state (June 2014): Flow is an experimental but already feature
> rich alternative to talk pages which can be enabled by WMF on a per-page
> basis and is currently used in production on a small number of 'real world'
> pages, including a couple of WikiProjects and feedback pages for new
> features.
>
> *Key Milestones*
>
> * We will aim to cover one major set of new deployments per quarter,
> carefully picking use cases. Example use cases may include: additional
> WikiProjects, shared conversation spaces like Teahouse and Village Pump,
> entire wikis willing to switch to Flow, etc. Success will be reflected in
> adoption/participation metrics, targeting improved participation dynamics
> relative to talk pages.
> * By the end of the fiscal year [i.e. June 30, 2015 --t.d.], we expect to
> cover one major use case thoroughly (e.g. all user talk pages, all Village
> Pump type pages, etc.)
> * By the end of the fiscal year [i.e. June 30, 2015. --t.d.], the team will
> be a multi-device team, ready to maintain and develop the user experience
> for phones, tablets, and desktops.
>
> (END QUOTE)
>
>
> It is shocking to see an assertion from WMF's VP of Engineering and Product
> Development that Flow has been consistently portrayed by WMF as nothing
> more than "a system in early development." In actual fact, it has been
> portrayed as more or less finished software heading for a rollout in the
> near future, as the above clearly illustrates.
>
> 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 -> it does not flow

[Tim Davenport]

Erik Möller wrote:

>> It's [Flow is] a system in early development, and has never been
advertised as anything else.

==

*This statement is simply not true.*

See the WMF's 2014-15 annual plan:
https://archive.org/details/WikimediaFoundation2014-15AnnualPlan

Page 20 (DIRECT QUOTE FOLLOWS):

*FLOW*

* Current state (June 2014): Flow is an experimental but already feature
rich alternative to talk pages which can be enabled by WMF on a per-page
basis and is currently used in production on a small number of 'real world'
pages, including a couple of WikiProjects and feedback pages for new
features.

*Key Milestones*

* We will aim to cover one major set of new deployments per quarter,
carefully picking use cases. Example use cases may include: additional
WikiProjects, shared conversation spaces like Teahouse and Village Pump,
entire wikis willing to switch to Flow, etc. Success will be reflected in
adoption/participation metrics, targeting improved participation dynamics
relative to talk pages.
* By the end of the fiscal year [i.e. June 30, 2015 --t.d.], we expect to
cover one major use case thoroughly (e.g. all user talk pages, all Village
Pump type pages, etc.)
* By the end of the fiscal year [i.e. June 30, 2015. --t.d.], the team will
be a multi-device team, ready to maintain and develop the user experience
for phones, tablets, and desktops.

(END QUOTE)


It is shocking to see an assertion from WMF's VP of Engineering and Product
Development that Flow has been consistently portrayed by WMF as nothing
more than "a system in early development." In actual fact, it has been
portrayed as more or less finished software heading for a rollout in the
near future, as the above clearly illustrates.

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 -> it does not flow

[Keegan Peterzell]

On Sat, Sep 6, 2014 at 10:27 PM, Keegan Peterzell 
wrote:

> ..last July...
>

July 2013, for clarity.

-- 
Keegan Peterzell
Community Liaison, Product
Wikimedia Foundation
___
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 -> it does not flow

[Keegan Peterzell]

On Sat, Sep 6, 2014 at 10:03 PM, Pine W  wrote:

> rik, I appreciate your engaging with this *early* enough for design
> decisions to be adjusted before Flow gets to major rollouts.
>
> Romaine, if the Dutch uses of features like templates are not being taken
> into account in how features are designed, I suggest contacting the
> Engineering community liaisons to make your needs known. I'm also sending
> this email to Rachel so she can consider having one of her employees reach
> out to you and the Dutch Wikipedia community.
>
> Pine


Thanks for the initiative Pine. Romaine and I know each other and spent a
great deal of last July talking about template usage on the Dutch Wikipedia
in the context of VisualEditor :) . I'm not on the Flow team (I don't work
with VE anymore either) so I can't speak for experience there, but I do
know that thanks to Romaine's advocacy within the community and to me that
VisualEditor was never enabled by default on the Dutch Wikipedia. This
occurred because of consideration of the special-use case that community
has built with templates. It was intense time for sure, but the right
decision was certainly made as far as the Dutch Wikipedia goes.

-- 
Keegan Peterzell
Community Liaison, Product
Wikimedia Foundation
___
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 -> it does not flow

[Pine W]

rik, I appreciate your engaging with this *early* enough for design
decisions to be adjusted before Flow gets to major rollouts.

Romaine, if the Dutch uses of features like templates are not being taken
into account in how features are designed, I suggest contacting the
Engineering community liaisons to make your needs known. I'm also sending
this email to Rachel so she can consider having one of her employees reach
out to you and the Dutch Wikipedia community.

Pine


On Sat, Sep 6, 2014 at 5:01 PM, Erik Moeller  wrote:

> On Sat, Sep 6, 2014 at 4:15 PM, Dan Garry  wrote:
> > There is one notable exception to the above, which is talk page header
> > templates. One expects updates to a template used as a talk page header
> to
> > update every page the template is currently transcluded on, which is not
> > happening presently. {{talk header}} is currently transcluded on over
> > 250,000 pages, so were these all Flow pages it would be excessively
> > laborious to edit all of those headers to force a reparsing of the
> template
> > were it updated. So this functionality, or something similar, should
> > probably be included in the Flow MVP [1] if it's deployed on a larger
> > scale. I think it's fine for now.
>
> That makes perfect sense -- thanks for pointing it out. Stale headers
> would suck indeed.
>
> And now I'm taking a break from wikimedia-l til Monday. The weather's
> nice, and the monthly posting limit is starting to loom into view. ;-)
> Hope everyone has a nice weekend.
>
> Erik
> --
> Erik Möller
> VP of Engineering and Product Development, Wikimedia Foundation
>
> ___
> 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 -> it does not flow

[Erik Moeller]

On Sat, Sep 6, 2014 at 4:15 PM, Dan Garry  wrote:
> There is one notable exception to the above, which is talk page header
> templates. One expects updates to a template used as a talk page header to
> update every page the template is currently transcluded on, which is not
> happening presently. {{talk header}} is currently transcluded on over
> 250,000 pages, so were these all Flow pages it would be excessively
> laborious to edit all of those headers to force a reparsing of the template
> were it updated. So this functionality, or something similar, should
> probably be included in the Flow MVP [1] if it's deployed on a larger
> scale. I think it's fine for now.

That makes perfect sense -- thanks for pointing it out. Stale headers
would suck indeed.

And now I'm taking a break from wikimedia-l til Monday. The weather's
nice, and the monthly posting limit is starting to loom into view. ;-)
Hope everyone has a nice weekend.

Erik
-- 
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation

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