subject:"\[Wikimedia\-l\] To Flow or not to Flow"

On Sep 10, 2014 5:11 AM, Keegan Peterzell keegan.w...@gmail.com wrote:

 On Tue, Sep 9, 2014 at 10:04 AM, Wil Sinclair w...@wllm.com 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_Alaskadiff=prevoldid=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,
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

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 martijnhoeks...@gmail.com
wrote:

 On Sep 10, 2014 5:11 AM, Keegan Peterzell keegan.w...@gmail.com wrote:
 
  On Tue, Sep 9, 2014 at 10:04 AM, Wil Sinclair w...@wllm.com 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_Alaskadiff=prevoldid=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,
 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

___
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

On Sep 10, 2014 9:35 AM, Gerard Meijssen gerard.meijs...@gmail.com
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 keegan.w...@gmail.com
wrote:
  
   On Tue, Sep 9, 2014 at 10:04 AM, Wil Sinclair w...@wllm.com 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_Alaskadiff=prevoldid=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,
  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
 
 ___
 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

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 martijnhoeks...@gmail.com
wrote:

 On Sep 10, 2014 9:35 AM, Gerard Meijssen gerard.meijs...@gmail.com
 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 keegan.w...@gmail.com
 wrote:
   
On Tue, Sep 9, 2014 at 10:04 AM, Wil Sinclair w...@wllm.com 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_Alaskadiff=prevoldid=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,
   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
  
  ___
  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

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

On Wed, Sep 10, 2014 at 9:55 AM, Gerard Meijssen gerard.meijs...@gmail.com
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 martijnhoeks...@gmail.com
 wrote:

  On Sep 10, 2014 9:35 AM, Gerard Meijssen gerard.meijs...@gmail.com
  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 keegan.w...@gmail.com
  wrote:

 On Tue, Sep 9, 2014 at 10:04 AM, Wil Sinclair w...@wllm.com
 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_Alaskadiff=prevoldid=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, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

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

2014-09-10 Thread 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 keegan.w...@gmail.com wrote:
 
  On Tue, Sep 9, 2014 at 10:04 AM, Wil Sinclair w...@wllm.com 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_Alaskadiff=prevoldid=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 stay 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, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

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

2014-09-10 Thread Andrew Gray

On 8 September 2014 08:22, David Gerard dger...@gmail.com wrote:
 On 8 September 2014 05:46, John Mark Vandenberg jay...@gmail.com 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, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

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

On 10 September 2014 12:54, Andrew Gray andrew.g...@dunelm.org.uk 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, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

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

2014-09-10 Thread Risker

On 10 September 2014 07:54, Andrew Gray andrew.g...@dunelm.org.uk wrote:

 On 8 September 2014 08:22, David Gerard dger...@gmail.com wrote:
 snip




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

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

2014-09-10 Thread MF-Warburg

Am 10.09.2014 09:56 schrieb Gerard Meijssen gerard.meijs...@gmail.com:

 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 martijnhoeks...@gmail.com
 wrote:

  On Sep 10, 2014 9:35 AM, Gerard Meijssen gerard.meijs...@gmail.com
  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 keegan.w...@gmail.com
  wrote:

 On Tue, Sep 9, 2014 at 10:04 AM, Wil Sinclair w...@wllm.com
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_Alaskadiff=prevoldid=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,
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
   
   ___
   Wikimedia-l mailing list, guidelines at:
  https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
   Wikimedia-l@lists.wikimedia.org
   Unsubscribe:

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

On Wed, Sep 10, 2014 at 2:42 PM, Risker risker...@gmail.com wrote:

 On 10 September 2014 07:54, Andrew Gray andrew.g...@dunelm.org.uk wrote:

  On 8 September 2014 08:22, David Gerard dger...@gmail.com wrote:
  snip



 
  * 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
 https://meta.wikimedia.org/wiki/Mailing_lists/guidelineswikimedi...@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

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

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

On 10 September 2014 16:48, Marc A. Pelletier m...@uberbox.org 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, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

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

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

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

On 10 September 2014 17:29, Marc A. Pelletier m...@uberbox.org 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, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

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

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 mfwarb...@googlemail.com wrote:

 Am 10.09.2014 09:56 schrieb Gerard Meijssen gerard.meijs...@gmail.com:
 
  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 martijnhoeks...@gmail.com
  wrote:
 
   On Sep 10, 2014 9:35 AM, Gerard Meijssen gerard.meijs...@gmail.com
   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 keegan.w...@gmail.com
 
   wrote:
 
  On Tue, Sep 9, 2014 at 10:04 AM, Wil Sinclair w...@wllm.com
 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_Alaskadiff=prevoldid=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,
 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:

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

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

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

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

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

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

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

On 10 September 2014 18:29, Marc A. Pelletier m...@uberbox.org 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, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

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

2014-09-10 Thread James Forrester

On 10 September 2014 04:58, David Gerard dger...@gmail.com wrote:

 On 10 September 2014 12:54, Andrew Gray andrew.g...@dunelm.org.uk 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:

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

On 10 September 2014 19:29, Marc A. Pelletier m...@uberbox.org wrote:
On 09/10/2014 01:25 PM, Diego Moya wrote:
[...] that allow editors and admins to
detect and combat vandalism and remove BLP sensible material and
libel; features which are not available in Flow as of today.

That is simply not true, at last as of the master branch. Topics and
replies can be hidden, deleted, or suppressed -- the same things that
can be done to talk page revisions at this moment.

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

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

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

-- Marc

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

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

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

On 10 September 2014 18:37, James Forrester jforres...@wikimedia.org 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, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

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

On Wed, Sep 10, 2014 at 7:17 PM, Diego Moya dialm...@gmail.com 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,
 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

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 dialm...@gmail.com 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 gerard.meijs...@gmail.com
 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,
 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

On 09/10/2014 01:41 PM, Diego Moya wrote:
 Take a look at this deleted topic at the test page that was deployed at 
 en.wiki:
 https://en.wikipedia.org/wiki/Topic:S214uoczkp47cfsx

As far as I can tell, you could see it because it never /was/ deleted.
I just deleted it, can you still see it?

I think what you see is the odd interaction with deleting the page
that a flow board lived at -- which may not even be a supported scenario
(or, at the very least, might need work).

-- Marc


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

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

2014-09-10 Thread James Forrester

On 10 September 2014 10:52, David Gerard dger...@gmail.com wrote:

 On 10 September 2014 18:48, Todd Allen toddmal...@gmail.com 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, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

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

On 10 September 2014 18:54, Gerard Meijssen gerard.meijs...@gmail.com wrote:

 When a specific way of working insists on talk pages, it means that the
 associated workflow has to be revisited and changed with urgency. It cannot
 be permitted that special interests take the whole of the much needed
 change hostage. Leaving this material unchecked ... is FUD. It is not an
 argument that prevents change, at most it means that a different mechanism
 has to be designed for that special interest.



You are entirely correct. Nevertheless, the change still needs to be
accepted by the crusty old editors who are used to the old ways. So
we're now at the stage of: how do we make experienced editors want
and demand this?


- d.

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

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

On Wed, Sep 10, 2014 at 7:54 PM, Gerard Meijssen gerard.meijs...@gmail.com
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 dialm...@gmail.com 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 gerard.meijs...@gmail.com
  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,
  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

___
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

On 10 September 2014 18:59, James Forrester jforres...@wikimedia.org 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, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

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

2014-09-10 Thread James Forrester

On 10 September 2014 11:01, David Gerard dger...@gmail.com wrote:

 On 10 September 2014 18:59, James Forrester jforres...@wikimedia.org
 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, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

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

2014-09-10 Thread Michael Peel


On 8 Sep 2014, at 08:22, David Gerard dger...@gmail.com wrote:

 On 8 September 2014 05:46, John Mark Vandenberg jay...@gmail.com 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, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

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

2014-09-10 Thread Wil Sinclair

 On Wed, Sep 10, 2014 at 7:54 PM, Gerard Meijssen gerard.meijs...@gmail.com
 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, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

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

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 m...@uberbox.org wrote:
 On 09/10/2014 01:41 PM, Diego Moya wrote:
 Take a look at this deleted topic at the test page that was deployed at 
 en.wiki:
 https://en.wikipedia.org/wiki/Topic:S214uoczkp47cfsx

 As far as I can tell, you could see it because it never /was/ deleted.
 I just deleted it, can you still see it?

 I think what you see is the odd interaction with deleting the page
 that a flow board lived at -- which may not even be a supported scenario
 (or, at the very least, might need work).

 -- Marc


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

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

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

2014-09-10 Thread Brad Jorsch (Anomie)

this represents my personal opinion and in no way is anything official

On Wed, Sep 10, 2014 at 1:17 PM, Diego Moya dialm...@gmail.com 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, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

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

On 10 September 2014 22:28, Brad Jorsch (Anomie) bjor...@wikimedia.org wrote:

 On Wed, Sep 10, 2014 at 1:17 PM, Diego Moya dialm...@gmail.com wrote:

 I have about 3000 pages in my
 watchlist, and receive around 400 updates daily only from talk pages,
 which 50 or so come from unique pages; getting all those as
 notifications would render Echo useless to me.
 I wouldn't want that either. But maybe newbies would; that should probably
 be studied, if notifying newbies of new conversations on their watched talk
 pages is beneficial or not.

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



 As for people like us, it seems there's already an opt-out in the form of
 going to Special:Preferences and turning off flow notifications. That
 could be made clearer that that's what it does, though.

 I agree that the ability to select specific threads or boards for
 notification without doing it for every watchlisted board/thread would be
 even better. But that seems like a lower priority, since watchlists still
 work.

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

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

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

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

On 10 September 2014 19:49, Martijn Hoekstra martijnhoeks...@gmail.com wrote:
 On Wed, Sep 10, 2014 at 7:17 PM, Diego Moya dialm...@gmail.com 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 PreferencesBeta (that's
the official channel for opting in to experimental features, right?)




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

 This is not testing, this was rolled out to the production
 environment.


 I'm confused. Where? Did I miss something? (please don't hesitate to say
 yes if the answer is yes)

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

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

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

On Wed, Sep 10, 2014 at 10:42 PM, Diego Moya dialm...@gmail.com wrote:

 On 10 September 2014 19:49, Martijn Hoekstra martijnhoeks...@gmail.com
 wrote:
  On Wed, Sep 10, 2014 at 7:17 PM, Diego Moya dialm...@gmail.com 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 PreferencesBeta (that's
 the official channel for opting in to experimental features, right?)


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

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

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

___
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

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

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

On 10 September 2014 22:49, Martijn Hoekstra martijnhoeks...@gmail.com 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, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

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

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

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

2014-09-10 Thread 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 shoehu...@gmail.com 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, 
 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

On 10 September 2014 19:54, Gerard Meijssen gerard.meijs...@gmail.com 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, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

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

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 dialm...@gmail.com wrote:

 On 10 September 2014 19:54, Gerard Meijssen gerard.meijs...@gmail.com
 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,
 mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

___
Wikimedia-l mailing list, guidelines at:

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

2014-09-09 Thread Erik Moeller

On Mon, Sep 8, 2014 at 12:22 AM, David Gerard dger...@gmail.com wrote:
 On 8 September 2014 05:46, John Mark Vandenberg jay...@gmail.com 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

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

2014-09-09 Thread David Gerard

On 9 September 2014 10:45, Erik Moeller e...@wikimedia.org wrote:
 On Mon, Sep 8, 2014 at 12:22 AM, David Gerard dger...@gmail.com 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, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

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

2014-09-09 Thread 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 dger...@gmail.com 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 e...@wikimedia.org wrote:
 On Mon, Sep 8, 2014 at 12:22 AM, David Gerard dger...@gmail.com wrote:
 On 8 September 2014 05:46, John Mark Vandenberg jay...@gmail.com 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

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

2014-09-09 Thread 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 m...@uberbox.org 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, 
 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 - it does not flow

2014-09-09 Thread Samuel Klein

On Sat, Sep 6, 2014 at 6:33 PM, Erik Moeller e...@wikimedia.org 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, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

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

2014-09-09 Thread Keegan Peterzell

On Tue, Sep 9, 2014 at 10:04 AM, Wil Sinclair w...@wllm.com 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_Alaskadiff=prevoldid=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, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

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

2014-09-08 Thread David Gerard

On 8 September 2014 05:46, John Mark Vandenberg jay...@gmail.com 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, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

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

2014-09-08 Thread 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 dger...@gmail.com wrote:

 On 8 September 2014 05:46, John Mark Vandenberg jay...@gmail.com 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,
 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

2014-09-08 Thread Diego Moya

On 8 September 2014 05:54, Marc A. Pelletier m...@uberbox.org 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 dialm...@gmail.com 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 talk, and can manage it to their liking. That

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

2014-09-08 Thread Diego Moya

On 8 September 2014 11:44, Diego Moya dialm...@gmail.com wrote:

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

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

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

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

2014-09-08 Thread 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 wiki.p...@gmail.com 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 dger...@gmail.com wrote:

  On 8 September 2014 05:46, John Mark Vandenberg jay...@gmail.com
 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,
  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

___
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

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

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

2014-09-08 Thread 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 m...@uberbox.org 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
 https://meta.wikimedia.org/wiki/Mailing_lists/guidelineswikimedi...@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

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

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

2014-09-08 Thread 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 m...@uberbox.org 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,
 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

2014-09-08 Thread phoebe ayers

Thank you for this overview and history, Erik!

On Fri, Sep 5, 2014 at 9:49 PM, Erik Moeller e...@wikimedia.org 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 at
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, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

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

2014-09-08 Thread 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 m...@uberbox.org
 javascript:; 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 javascript:;
  
 https://meta.wikimedia.org/wiki/Mailing_lists/guidelineswikimedi...@lists.wikimedia.org
 
  Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
  mailto:wikimedia-l-requ...@lists.wikimedia.org javascript:;
 ?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 javascript:;
 ?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

2014-09-08 Thread Jon Davies

+1

On 8 September 2014 16:43, Ziko van Dijk zvand...@gmail.com 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 m...@uberbox.org
  javascript:; 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 javascript:;
   
 
 https://meta.wikimedia.org/wiki/Mailing_lists/guidelineswikimedi...@lists.wikimedia.org
  
   Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
   mailto:wikimedia-l-requ...@lists.wikimedia.org javascript:;
  ?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 javascript:;
  ?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




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

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

2014-09-08 Thread 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 zvand...@gmail.com 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 m...@uberbox.org
  javascript:; 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 javascript:;
   
 
 https://meta.wikimedia.org/wiki/Mailing_lists/guidelineswikimedi...@lists.wikimedia.org
  
   Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
   mailto:wikimedia-l-requ...@lists.wikimedia.org javascript:;
  ?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 javascript:;
  ?subject=unsubscribe
 ___
 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,
 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:

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

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

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

2014-09-08 Thread Erik Moeller

On Sat, Sep 6, 2014 at 3:33 PM, Erik Moeller e...@wikimedia.org 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, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

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

2014-09-08 Thread Erik Moeller

On Mon, Sep 8, 2014 at 6:47 PM, Erik Moeller e...@wikimedia.org 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, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

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

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 dialm...@gmail.com 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,
 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

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

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

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 w...@wllm.com 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,
 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

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

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

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

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

2014-09-07 Thread Diego Moya

On 7 September 2014 13:33, Gerard Meijssen gerard.meijs...@gmail.com
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, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

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

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

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

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

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

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

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

2014-09-07 Thread Risker

On 7 September 2014 23:54, Marc A. Pelletier m...@uberbox.org 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, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

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

2014-09-07 Thread Todd Allen

On Sun, Sep 7, 2014 at 9:54 PM, Marc A. Pelletier m...@uberbox.org 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, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

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

2014-09-07 Thread 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:Flowaction=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=Flowlist_id=342315product=MediaWikiproduct=MediaWiki%20extensionsproduct=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
cfrank...@halonetwork.net 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 e...@wikimedia.org 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

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

2014-09-07 Thread John Mark Vandenberg

On Mon, Sep 8, 2014 at 1:54 PM, Marc A. Pelletier m...@uberbox.org 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, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

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

2014-09-07 Thread Risker

On 8 September 2014 00:46, John Mark Vandenberg jay...@gmail.com wrote:

snip


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

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

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 risker...@gmail.com wrote:

 On 7 September 2014 23:54, Marc A. Pelletier m...@uberbox.org 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,
 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