Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

2015-03-28 Thread Kevin Wayne Williams

Risker schreef op 2015/03/20 om 5:46:

Nonetheless, if you were trying to illustrate that there are communication
benefits in having an easily read flow of discussion, I don't think anyone
is disagreeing with you about that, and simplification of the indentation
system/process would be desirable no matter what underlying software is
used for discussion.  What is being said in this thread is that Flow does
not do this now, and in fact is currently designed to prevent this from
happening.

Precisely. It takes the biggest problem we currently have and aggravates it.
KWW

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

2015-03-23 Thread Tilman Bayer
Hi Risker,

the researchers' conclusion in their own words (see section 4.1,
Indentation Reliability) is:


*Incorrect indentation (i.e., indentation that implies a reply-to relation
with the wrong post) is quite common in longer discussions in the EWDC [the
English Wikipedia Discussion Corpus].*


Responding below to your concerns about their methodology, taking the
opportunity to clear up some statistical misconceptions, which might be
valuable for other contexts too.


On Friday, March 20, 2015, Risker risker...@gmail.com wrote:

 On 20 March 2015 at 06:13, Tilman Bayer tba...@wikimedia.org wrote:

  On Friday, March 20, 2015, Tilman Bayer tba...@wikimedia.org
  javascript:_e(%7B%7D,'cvml','tba...@wikimedia.org'); wrote:
  
   Just to throw this in here as one data point: 39% of talk page threads
   contain wrong indentations
   
 
 https://meta.wikimedia.org/wiki/Research:Newsletter/2014/November#39.25_of_talk_page_threads_contain_wrong_indentations
  
   
  
   PS: The result from that paper was actually even worse than that
 (somewhat
  sloppy) headline suggests: the researchers found that 29 of 74 total
  turns, or 39%±14pp of an average thread, had indentation that
 misidentified
  the turn to which they were a reply.
 
 

 I'm not sure you really read the underlying study, Tilman; the sample size
 is so absurdly small that there is no way it is statistically signifant.
 (550 discussions on 83 article talk pages, in case anyone was wondering;

No, the sample size was actually stated right in the sentence I quoted
above: 74 total turns (talk page comments responding to another one),
together with a ±14pp confidence interval.

And what exactly did you mean here by statistically significant? The term
doesn't make mathematical sense when applied to such a measured percentage
in isolation, i.e. without a hypothesis or comparison value. Rather, one
can talk about confidence intervals - a smaller confidence interval means
the estimate is likely to be more precise.

The 550 discussions you quoted refer to a different sample within the same
corpus.


the equivalent of about 10 minutes' worth of discussions on enwiki, except
 that they are looking at talk pages that may have conversations dating back
 10+ years.)

This 10 minutes/10 years comparison and the absurdly small/no way
rhetoric sound a lot like a common statistical fallacy, namely erroneously
assuming that it is size of the sample as a fraction of the population
that matters http://www.amstat.org/publications/jse/v12n2/smith.html
(Unless the sample encompasses a substantial portion of the population,
the standard error of an estimator depends on the size of the sample, but
not the size of the population. This is a crucial statistical insight that
students find very counterintuitive).

Granted, if one draws a sample of 74 turns from all turns on all talk pages
made in Wikipedia's history, then it's plausible that that overall
population numbers hundreds of millions. But at such a large population
size (or small sample/population ratio) it is is the absolute size of the
sample that matters for the size of the confidence interval - not how large
the sample is compared to the population.

There may be accessible explanations elsewhere that include more of the
math behind it, but perhaps this Khan Academy video
https://www.youtube.com/watch?v=1JT9oODsClE helps, which walks one
through a calculation showing how measuring a percentage of 38% in a sample
of just 150 US households (out of 100+million) already allows one to reject
the null hypothesis that the real percentage among the entire population of
all households is less than 30%. It calls 150 a large sample in terms of
the approximation regime used there - which I'm sure you must find
extremely shocking as you earlier called a sample of 550 absurdly small.
For a more thorough derivation, these online lectures
http://www.stat.berkeley.edu/~stark/SticiGui/Text/confidenceIntervals.htm are
quite useful (see e.g. the Conservative confidence intervals for
percentages section. The finite population correction
https://en.wikipedia.org/wiki/Finite_population_correction term there is
close to 1 for small sample/population ratios and so the resulting formula
for the confidence interval does no longer depend on N, the population
size).

Sure, in the present case the absolute size of the sample (74) wasn't very
big either, and there are other things to consider such as the selection
method (e.g. they actually selected from whole threads longer than 10
turns each only, so that's what the percentage relates to). But the
authors did their due diligence and indicated the limitations resulting
from the sample size by including that ±14% confidence interval. Yes,
that's quite broad and for more precise estimations of the real overall
percentage of wrong indentations (39% or 32% or 48%?...) one would need a
larger sample. But it already makes it highly unlikely that this real
percentage is only 1% or 2%, say.

Hence I 

[Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

2015-03-20 Thread Tilman Bayer
On Friday, March 20, 2015, Tilman Bayer tba...@wikimedia.org
javascript:_e(%7B%7D,'cvml','tba...@wikimedia.org'); wrote:

 Just to throw this in here as one data point: 39% of talk page threads
 contain wrong indentations
 https://meta.wikimedia.org/wiki/Research:Newsletter/2014/November#39.25_of_talk_page_threads_contain_wrong_indentations
 

 PS: The result from that paper was actually even worse than that (somewhat
sloppy) headline suggests: the researchers found that 29 of 74 total
turns, or 39%±14pp of an average thread, had indentation that misidentified
the turn to which they were a reply.


-- 
Sent from Gmail Mobile
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

2015-03-20 Thread Daniel Friesen
On 2015-03-20 2:52 AM, Tilman Bayer wrote:
 And like Jon, I'm surprised to hear about stories where staff are
 reverting to emails. Admittedly, WMF employees do indeed sometimes
 discuss topics per email instead exclusively using wiki talk pages,
 but in my recollection this happened even before the existence of
 Flow. And after all, this very thread is happening on Wikitech-l
 instead of mediawiki.org ;)
Instant notifications.
All messages no matter who they're from, who they're for (mailing list
or personal message to you), or what their topic is are available from
one place and you can organize them if you wish.
Any of many different types of clients can be used to access them.
And everyone gets to pick whichever threading model they want.

It's no wonder people get drawn back to using email when there isn't
something contextual to the subject anchoring it to a wiki, no matter
what method of discussions are used on-wiki.

~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

2015-03-20 Thread Risker
On 20 March 2015 at 06:13, Tilman Bayer tba...@wikimedia.org wrote:

 On Friday, March 20, 2015, Tilman Bayer tba...@wikimedia.org
 javascript:_e(%7B%7D,'cvml','tba...@wikimedia.org'); wrote:
 
  Just to throw this in here as one data point: 39% of talk page threads
  contain wrong indentations
  
 https://meta.wikimedia.org/wiki/Research:Newsletter/2014/November#39.25_of_talk_page_threads_contain_wrong_indentations
 
  
 
  PS: The result from that paper was actually even worse than that (somewhat
 sloppy) headline suggests: the researchers found that 29 of 74 total
 turns, or 39%±14pp of an average thread, had indentation that misidentified
 the turn to which they were a reply.



I'm not sure you really read the underlying study, Tilman; the sample size
is so absurdly small that there is no way it is statistically signifant.
(550 discussions on 83 article talk pages, in case anyone was wondering;
the equivalent of about 10 minutes' worth of discussions on enwiki, except
that they are looking at talk pages that may have conversations dating back
10+ years.)  And the purpose of the study was to see if this particular
manner of analysing a discussion (lexical pairs) was useful in
identifying who said what to whom; it's a discussion of the analysis
process, not the actual discussions.

Nonetheless, if you were trying to illustrate that there are communication
benefits in having an easily read flow of discussion, I don't think anyone
is disagreeing with you about that, and simplification of the indentation
system/process would be desirable no matter what underlying software is
used for discussion.  What is being said in this thread is that Flow does
not do this now, and in fact is currently designed to prevent this from
happening.

Risker/Anne
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

2015-03-20 Thread Tilman Bayer
On Thu, Mar 19, 2015 at 10:28 AM, Ryan Lane rlan...@gmail.com wrote:

 On Thu, Mar 19, 2015 at 8:18 AM, Risker risker...@gmail.com wrote:

 
  The dogfooding has been happening for a while on WMF's own office-wiki.
 We
  haven't heard any results about that.  Is the system being used more than
  the wikitext system?  (i.e., are there more talk page comments now than
  there were before?)  Have users expressed satisfaction/dissatisfaction
 with
  the system?  Have they been surveyed?  Do they break down into groups
  (e.g., engineering loves it, grants hates it, etc...)?  I hear some
 stories
  (including stories that suggest some groups of staff have pretty much
  abandoned talk pages on office-wiki and are now reverting to emails
  instead) but without any documentary evidence or analysis it's
 unreasonable
  to think that it is either a net positive OR a net negative.
 
 
 From what I remember officewiki is pretty unused by most of the staff, so
 I'd doubt you'd get much usable feedback there.

Actually,
https://office.wikimedia.org/w/index.php?title=Special:RecentChangeslimit=250
currently goes back about 90 hours (i.e. more than 60 edits/day), with more
than 30 different users active in that time.

And like Jon, I'm surprised to hear about stories where staff are
reverting to emails. Admittedly, WMF employees do indeed sometimes
discuss topics per email instead exclusively using wiki talk pages, but in
my recollection this happened even before the existence of Flow. And after
all, this very thread is happening on Wikitech-l instead of mediawiki.org ;)


 As someone who's used mediawiki for 10+ years I can say that *anything* is
 better than wikitext for discussion. I have a certain bias towards LQT and
 such, but that's because I actually want to use discussion pages for
 discussion and wikitext is basically the worst user experience in the world
 in this regard.

Just to throw this in here as one data point: 39% of talk page threads
contain wrong indentations
https://meta.wikimedia.org/wiki/Research:Newsletter/2014/November#39.25_of_talk_page_threads_contain_wrong_indentations


-- 
Tilman Bayer
Senior Analyst
Wikimedia Foundation
IRC (Freenode): HaeB
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

2015-03-19 Thread Daniel Friesen
On 2015-03-18 11:31 PM, Isarra Yos wrote:
 On 19/03/15 01:42, Danny Horn wrote:
 Brad: unfortunately, it's really hard to tell very much from a
 conversation
 with messages like 3: Post C: reply to Post A. You could do that
 with the
 old model, the new model or the perfect magic Nobel-Prize-winning
 discussion threading still to be discovered, and it would probably look
 like nonsense in all three.

 We've tried in our testing to pretend that we're having real
 conversations,
 so we could see whether there's any logical way to get to eight
 levels of
 nested threading. It's not easy to organize make-believe
 conversations, but
 if you want to start a thread, I'd be happy to fire up a few sockpuppets
 and pretend to talk about something with you.

 I'm a little confused. Didn't LQT already solve this problem? Why not
 just nest/thread things the same way it does, or how well-formatted
 wikitext conversations in general do? That seemed to work fine; the
 issues with LQT lay elsewhere, and the issue with wikitext really just
 seems to be it all needs to be done manually and users often don't get
 it right as a result, hence a good chunk of why we're trying to
 replace it in the first place.

 -I
Yes, Wikitext conversations did have a threading pattern.

From what I can see looking at a long discussion on a random FA talkpage
archive it goes like this:
Users indent after each message.
Then when it gets too deep someone starts their message with 0 indentation.
Conversations with larger messages end up reset quicker.

Unfortunately this model cannot be applied to LQT or Flow.

LQT just keeps indenting even when you would break because the indent is
too deep.

Flow tries to fix this by only indenting when replying in a spot where
you can't just append.

Frankly the WikiText indentation practice doesn't make sense in LQT or
Flow. As I understand we always change the indentation in WikiText in
part because it's hard to see where one user's message becomes another
with just a signature to break the paragraphs into messages.

That doesn't make sense in LQT or Flow where messages are structured and
have an interface to differentiate them.

~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

2015-03-19 Thread Isarra Yos

On 19/03/15 07:00, Daniel Friesen wrote:

On 2015-03-18 11:31 PM, Isarra Yos wrote:

On 19/03/15 01:42, Danny Horn wrote:

Brad: unfortunately, it's really hard to tell very much from a
conversation
with messages like 3: Post C: reply to Post A. You could do that
with the
old model, the new model or the perfect magic Nobel-Prize-winning
discussion threading still to be discovered, and it would probably look
like nonsense in all three.

We've tried in our testing to pretend that we're having real
conversations,
so we could see whether there's any logical way to get to eight
levels of
nested threading. It's not easy to organize make-believe
conversations, but
if you want to start a thread, I'd be happy to fire up a few sockpuppets
and pretend to talk about something with you.

I'm a little confused. Didn't LQT already solve this problem? Why not
just nest/thread things the same way it does, or how well-formatted
wikitext conversations in general do? That seemed to work fine; the
issues with LQT lay elsewhere, and the issue with wikitext really just
seems to be it all needs to be done manually and users often don't get
it right as a result, hence a good chunk of why we're trying to
replace it in the first place.

-I

Yes, Wikitext conversations did have a threading pattern.

 From what I can see looking at a long discussion on a random FA talkpage
archive it goes like this:
Users indent after each message.
Then when it gets too deep someone starts their message with 0 indentation.
Conversations with larger messages end up reset quicker.

Unfortunately this model cannot be applied to LQT or Flow.



Um... LQT has exactly that model. Yes, you can keep going, but you can 
keep going in wikitext, too, even off the side of the page (which is 
exactly what uncyclopedians do sometimes precisely because they want to 
go off the side of the page because they think it's funny, because let's 
face it, it is funny), but normally you just start a new 
conversation/thread/topic/whatever you want to call it if it goes too far.


There's no way to solve the threading problem for long complex 
conversations directly because while you need that threading in order to 
discern who is responding to whom, or even what is going on in general, 
there is always only so much space on the screen. We accept this, we 
outdent, or we refocus with a new section after it gets too long/we feel 
like putting our usernames in the ToC, or we even wind up just having 
everyone involved creating their own thread from the start (because 
really, we all want our usernames in the ToC), but the problem of how to 
handle it has been solved in practice.


-I

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

2015-03-19 Thread Isarra Yos

On 19/03/15 01:42, Danny Horn wrote:

Brad: unfortunately, it's really hard to tell very much from a conversation
with messages like 3: Post C: reply to Post A. You could do that with the
old model, the new model or the perfect magic Nobel-Prize-winning
discussion threading still to be discovered, and it would probably look
like nonsense in all three.

We've tried in our testing to pretend that we're having real conversations,
so we could see whether there's any logical way to get to eight levels of
nested threading. It's not easy to organize make-believe conversations, but
if you want to start a thread, I'd be happy to fire up a few sockpuppets
and pretend to talk about something with you.


I'm a little confused. Didn't LQT already solve this problem? Why not 
just nest/thread things the same way it does, or how well-formatted 
wikitext conversations in general do? That seemed to work fine; the 
issues with LQT lay elsewhere, and the issue with wikitext really just 
seems to be it all needs to be done manually and users often don't get 
it right as a result, hence a good chunk of why we're trying to replace 
it in the first place.


-I

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

2015-03-19 Thread Helder .
On Thu, Mar 19, 2015 at 4:42 AM, Isarra Yos zhoris...@gmail.com wrote:
 ...
 Um... LQT has exactly that model. Yes, you can keep going, but you can keep
 going in wikitext, too, even off the side of the page (which is exactly what
 uncyclopedians do sometimes precisely because they want to go off the side
 of the page because they think it's funny, because let's face it, it is
 funny), but normally you just start a new conversation/thread/topic/whatever
 you want to call it if it goes too far.

 There's no way to solve the threading problem for long complex conversations
 directly because while you need that threading in order to discern who is
 responding to whom, or even what is going on in general, there is always
 only so much space on the screen. We accept this, we outdent, or we refocus
 with a new section after it gets too long/we feel like putting our usernames
 in the ToC, or we even wind up just having everyone involved creating their
 own thread from the start (because really, we all want our usernames in the
 ToC), but the problem of how to handle it has been solved in practice.

LQT works well for the part of showing who is replying to who.
As for the cases where one would need to use {{outdent}} so that
each message has more horizontal space, I think it is possible for LQT/Flow
to have a system similar to this: when someone is reading a talkpage where there
is too many indentation, the user should be allowed to click in a given message
so that messages above it get collapsed, and its left margin is
reduced near to zero,
so that all replies (to replies (to replies...)) of that message now
have more space.
If reading this thread one gets too much indentation again, just
click in another message,
to focus on it, reset the margin again, and hide the previous comments.

On Thu, Mar 19, 2015 at 5:21 AM, Daniel Friesen
dan...@nadir-seen-fire.com wrote:
 Perhaps the Flow interface needs high level support for something like
 that. Something like how Discourse lets you fork a message into a new
 topic and displays an interface bit that links to the new topic.

LQT already allows that. One just need to click on More  Drag to
new location
and move it to a top level position. This will open a popup with this message:

To complete the following actions, please fill in a reason and click Confirm.
* Adjust post's position on the page
* Move post to its own thread
Reason: [__]
Subject for new thread (mandatory): [___]
[Confirm]

I've used this many times on Portuguese Wikibooks and it works well
for discussing new off-topic ideas which come up in the middle of
other discussions.

Best regards,
Helder

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

2015-03-19 Thread Ryan Lane
On Thu, Mar 19, 2015 at 8:18 AM, Risker risker...@gmail.com wrote:


 The dogfooding has been happening for a while on WMF's own office-wiki.  We
 haven't heard any results about that.  Is the system being used more than
 the wikitext system?  (i.e., are there more talk page comments now than
 there were before?)  Have users expressed satisfaction/dissatisfaction with
 the system?  Have they been surveyed?  Do they break down into groups
 (e.g., engineering loves it, grants hates it, etc...)?  I hear some stories
 (including stories that suggest some groups of staff have pretty much
 abandoned talk pages on office-wiki and are now reverting to emails
 instead) but without any documentary evidence or analysis it's unreasonable
 to think that it is either a net positive OR a net negative.


From what I remember officewiki is pretty unused by most of the staff, so
I'd doubt you'd get much usable feedback there.

As someone who's used mediawiki for 10+ years I can say that *anything* is
better than wikitext for discussion. I have a certain bias towards LQT and
such, but that's because I actually want to use discussion pages for
discussion and wikitext is basically the worst user experience in the world
in this regard. You have a bias towards wikitext because it's been the only
option and Wikimedia wikis have weirdly embraced the functionality and
freedom it provides. Having that freedom hampered is surely painful to
powerusers, but the new user experience isn't even comparable it's so much
better.

- Ryan
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

2015-03-19 Thread Quim Gil
On Thu, Mar 19, 2015 at 4:29 PM, Gerard Meijssen gerard.meijs...@gmail.com
wrote:

 If you want to have a real world population of editors moving over to flow,
 try translatewiki.net when FLOW is ready.


Check https://phabricator.wikimedia.org/T88102
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

2015-03-19 Thread Risker
On 19 March 2015 at 13:28, Ryan Lane rlan...@gmail.com wrote:

 On Thu, Mar 19, 2015 at 8:18 AM, Risker risker...@gmail.com wrote:

 
  The dogfooding has been happening for a while on WMF's own office-wiki.
 We
  haven't heard any results about that.  Is the system being used more than
  the wikitext system?  (i.e., are there more talk page comments now than
  there were before?)  Have users expressed satisfaction/dissatisfaction
 with
  the system?  Have they been surveyed?  Do they break down into groups
  (e.g., engineering loves it, grants hates it, etc...)?  I hear some
 stories
  (including stories that suggest some groups of staff have pretty much
  abandoned talk pages on office-wiki and are now reverting to emails
  instead) but without any documentary evidence or analysis it's
 unreasonable
  to think that it is either a net positive OR a net negative.
 
 
 From what I remember officewiki is pretty unused by most of the staff, so
 I'd doubt you'd get much usable feedback there.

 As someone who's used mediawiki for 10+ years I can say that *anything* is
 better than wikitext for discussion. I have a certain bias towards LQT and
 such, but that's because I actually want to use discussion pages for
 discussion and wikitext is basically the worst user experience in the world
 in this regard. You have a bias towards wikitext because it's been the only
 option and Wikimedia wikis have weirdly embraced the functionality and
 freedom it provides. Having that freedom hampered is surely painful to
 powerusers, but the new user experience isn't even comparable it's so much
 better.


I think you're mistaking me for someone else.  I too have used wikitext for
10+ years - even though today I do the majority of my mainspace edits using
Visual Editor.  I get the idea of a better way of having discussions, and I
also am happy that VE is well on its way. But quite honestly, what I'm
seeing with Flow is...well, it reminds me of nothing more than the kinds of
discussion systems that seemed old-fashioned and clunky even before I
started editing Wikipedia.  It wasn't envisioned as a discussion system, it
was envisioned as a workflow system, and it shows. I routinely cannot
tell who is responding to whom in Flow threads today on seldom-used and
seldom-edited pages (I've never seen it used at all in any fast-moving
discussions) and I'm hardly stupid - I've been participating in online
discussion forums since the 1990s too.

I am not married to the idea of using Wikitext, but I don't see the benefit
in making an irreversible change in discussion software to a forum that is
intended to be a core, Wikimedia/Mediawiki-wide site (comparable to Meta
and Commons and Wikidata) by applying software that isn't ready for prime
time.

Risker/Anne
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

2015-03-19 Thread Jon Robson
On Thu, Mar 19, 2015 at 8:18 AM, Risker risker...@gmail.com wrote:

 On 19 March 2015 at 11:08, Jon Robson jdlrob...@gmail.com wrote:

  On 19 Mar 2015 7:55 am, Brad Jorsch (Anomie) bjor...@wikimedia.org
  wrote:
  
   On Wed, Mar 18, 2015 at 9:42 PM, Danny Horn dh...@wikimedia.org
 wrote:
  
Brad: unfortunately, it's really hard to tell very much from a
  conversation
with messages like 3: Post C: reply to Post A. You could do that
 with
  the
old model, the new model or the perfect magic Nobel-Prize-winning
discussion threading still to be discovered, and it would probably
 look
like nonsense in all three.
   
  
   I shouldn't have used both numbers and post-names, but once I realized
  that
   it was already a bit late and it won't let me edit those posts. Someone
   with appropriate permissions is free to go back and edit them all to
  remove
   the number prefix and let the alphabetical order of the post-names
  suffice
   to indicate the chronological order of the postings, if that would make
  it
   less confusing for you.
  
   The point is the structure you're displaying doesn't make any sense,
 not
   that the content of my messages isn't anything that might make sense on
  its
   own. My content is explicitly simplified to illustrate the failings
 in
   the displayed structure. Structure should *facilitate* understanding,
 but
   in your demo I'd find that understanding the underlying structure of
 the
   conversation would be *despite* the broken display-structure.
  
   Nor is the point that people can screw up wikitext talk pages in ways
  that
   are even more confusing. That's a given, but Flow is supposed to do
  better.
   Right now it's worse than a well-formatted wikitext talk page (which
 has
   the advantage that human users can *fix* the structure when a newbie
  breaks
   it).
  
   Comparing http://flow-tests.wmflabs.org/wiki/Wikitext version of
   Topic:Sdrqdcffddyz0jeo to
  
 
 
 http://flow-tests.wmflabs.org/wiki/Wikitext_version_of_Topic:Sdrqdcffddyz0jeo
  ,
   I find it much easier in the latter to see what is a reply to what.
  
  
We've tried in our testing to pretend that we're having real
  conversations,
so we could see whether there's any logical way to get to eight
 levels
  of
nested threading. It's not easy to organize make-believe
 conversations,
but if you want to start a thread, I'd be happy to fire up a few
sockpuppets and pretend to talk about something with you.
   
  
   No thanks. Pretend real conversations are ok for a first assessment
 at
   usability, but by nature they're likely to be vapid and unlikely to
 have
   the inter-post complexity of actual conversations on-wiki where people
  are
   concentrating on actually communicating rather than on forcing a
   conversation for the sake of testing.
  
 
  Let's all be happy then that we are replacing an unloved broken talk
  extension with Flow on a wiki where we have real conversations then ...?
 :)
  actually dogfooding will make it much easier for us to communicate errors
  with the Flow team and help improve the software.
 
  I truly hope that soon we can get to a point where we can enable flow on
  all pages on mediawiki.org and this seems like the obvious first step.
 
 
 The dogfooding has been happening for a while on WMF's own office-wiki.  We
 haven't heard any results about that.  Is the system being used more than
 the wikitext system?  (i.e., are there more talk page comments now than
 there were before?)  Have users expressed satisfaction/dissatisfaction with
 the system?  Have they been surveyed?  Do they break down into groups
 (e.g., engineering loves it, grants hates it, etc...)?  I hear some stories
 (including stories that suggest some groups of staff have pretty much
 abandoned talk pages on office-wiki and are now reverting to emails
 instead) but without any documentary evidence or analysis it's unreasonable
 to think that it is either a net positive OR a net negative.


Really? This is news to me and if true, I really ponder why paid staff
members would not be actively trying to feed back to their team mates on
why it is not working for them.

In general this thread is really veering off topic in various directions.
It would be great if people could start new conversations and phabricator
discussions around particular bugs so that they don't get lost in the void
of the ramblings of wikitech.




 Risker/Anne
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Jon Robson
* http://jonrobson.me.uk
* https://www.facebook.com/jonrobson
* @rakugojon
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

2015-03-19 Thread Risker
On 18 March 2015 at 21:42, Danny Horn dh...@wikimedia.org wrote:

 Brad: unfortunately, it's really hard to tell very much from a conversation
 with messages like 3: Post C: reply to Post A. You could do that with the
 old model, the new model or the perfect magic Nobel-Prize-winning
 discussion threading still to be discovered, and it would probably look
 like nonsense in all three.

 We've tried in our testing to pretend that we're having real conversations,
 so we could see whether there's any logical way to get to eight levels of
 nested threading. It's not easy to organize make-believe conversations, but
 if you want to start a thread, I'd be happy to fire up a few sockpuppets
 and pretend to talk about something with you.


The problem with your testing process is that it is entirely possible for
a response to one comment to also make sense as a response to other
comments - which leads to miscommunication, confusion and difficulty
figuring out who is saying what to whom.

Risker/Anne
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

2015-03-19 Thread Brad Jorsch (Anomie)
On Wed, Mar 18, 2015 at 9:42 PM, Danny Horn dh...@wikimedia.org wrote:

 Brad: unfortunately, it's really hard to tell very much from a conversation
 with messages like 3: Post C: reply to Post A. You could do that with the
 old model, the new model or the perfect magic Nobel-Prize-winning
 discussion threading still to be discovered, and it would probably look
 like nonsense in all three.


I shouldn't have used both numbers and post-names, but once I realized that
it was already a bit late and it won't let me edit those posts. Someone
with appropriate permissions is free to go back and edit them all to remove
the number prefix and let the alphabetical order of the post-names suffice
to indicate the chronological order of the postings, if that would make it
less confusing for you.

The point is the structure you're displaying doesn't make any sense, not
that the content of my messages isn't anything that might make sense on its
own. My content is explicitly simplified to illustrate the failings in
the displayed structure. Structure should *facilitate* understanding, but
in your demo I'd find that understanding the underlying structure of the
conversation would be *despite* the broken display-structure.

Nor is the point that people can screw up wikitext talk pages in ways that
are even more confusing. That's a given, but Flow is supposed to do better.
Right now it's worse than a well-formatted wikitext talk page (which has
the advantage that human users can *fix* the structure when a newbie breaks
it).

Comparing http://flow-tests.wmflabs.org/wiki/Wikitext version of
Topic:Sdrqdcffddyz0jeo to
http://flow-tests.wmflabs.org/wiki/Wikitext_version_of_Topic:Sdrqdcffddyz0jeo,
I find it much easier in the latter to see what is a reply to what.


 We've tried in our testing to pretend that we're having real conversations,
 so we could see whether there's any logical way to get to eight levels of
 nested threading. It's not easy to organize make-believe conversations,
 but if you want to start a thread, I'd be happy to fire up a few
 sockpuppets and pretend to talk about something with you.


No thanks. Pretend real conversations are ok for a first assessment at
usability, but by nature they're likely to be vapid and unlikely to have
the inter-post complexity of actual conversations on-wiki where people are
concentrating on actually communicating rather than on forcing a
conversation for the sake of testing.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

2015-03-19 Thread Jon Robson
On 19 Mar 2015 7:55 am, Brad Jorsch (Anomie) bjor...@wikimedia.org
wrote:

 On Wed, Mar 18, 2015 at 9:42 PM, Danny Horn dh...@wikimedia.org wrote:

  Brad: unfortunately, it's really hard to tell very much from a
conversation
  with messages like 3: Post C: reply to Post A. You could do that with
the
  old model, the new model or the perfect magic Nobel-Prize-winning
  discussion threading still to be discovered, and it would probably look
  like nonsense in all three.
 

 I shouldn't have used both numbers and post-names, but once I realized
that
 it was already a bit late and it won't let me edit those posts. Someone
 with appropriate permissions is free to go back and edit them all to
remove
 the number prefix and let the alphabetical order of the post-names suffice
 to indicate the chronological order of the postings, if that would make it
 less confusing for you.

 The point is the structure you're displaying doesn't make any sense, not
 that the content of my messages isn't anything that might make sense on
its
 own. My content is explicitly simplified to illustrate the failings in
 the displayed structure. Structure should *facilitate* understanding, but
 in your demo I'd find that understanding the underlying structure of the
 conversation would be *despite* the broken display-structure.

 Nor is the point that people can screw up wikitext talk pages in ways that
 are even more confusing. That's a given, but Flow is supposed to do
better.
 Right now it's worse than a well-formatted wikitext talk page (which has
 the advantage that human users can *fix* the structure when a newbie
breaks
 it).

 Comparing http://flow-tests.wmflabs.org/wiki/Wikitext version of
 Topic:Sdrqdcffddyz0jeo to

http://flow-tests.wmflabs.org/wiki/Wikitext_version_of_Topic:Sdrqdcffddyz0jeo
,
 I find it much easier in the latter to see what is a reply to what.


  We've tried in our testing to pretend that we're having real
conversations,
  so we could see whether there's any logical way to get to eight levels
of
  nested threading. It's not easy to organize make-believe conversations,
  but if you want to start a thread, I'd be happy to fire up a few
  sockpuppets and pretend to talk about something with you.
 

 No thanks. Pretend real conversations are ok for a first assessment at
 usability, but by nature they're likely to be vapid and unlikely to have
 the inter-post complexity of actual conversations on-wiki where people are
 concentrating on actually communicating rather than on forcing a
 conversation for the sake of testing.


Let's all be happy then that we are replacing an unloved broken talk
extension with Flow on a wiki where we have real conversations then ...? :)
actually dogfooding will make it much easier for us to communicate errors
with the Flow team and help improve the software.

I truly hope that soon we can get to a point where we can enable flow on
all pages on mediawiki.org and this seems like the obvious first step.

___enable __
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

2015-03-19 Thread Helder .
On Thu, Mar 19, 2015 at 3:19 PM, Risker risker...@gmail.com wrote:
 I am not married to the idea of using Wikitext, but I don't see the benefit
 in making an irreversible change in discussion software to a forum that is
 intended to be a core, Wikimedia/Mediawiki-wide site (comparable to Meta
 and Commons and Wikidata) by applying software that isn't ready for prime
 time.

As long as the structure of the conversation is stored by the new
system (and I think both LQT and Flow do that - using a graph of what
is a reply to what?) the presentation we have for this structure can
be improved over time, or we can even have multiple ways for viewing a
given conversation (e.g. with infinite indentation, completelly plain,
limited indentation, flow's-new style, whatever). This is like the
four View by options at
https://lists.wikimedia.org/pipermail/wikitech-l/

I don't like the current limited indentation view implemented in
Flow, but I like even less the lack of (semantic) structure of
wikitext conversations. The :s are converted to dls and dts by
MediaWiki, and this breaks every time someone adds an extra new line
between comments (to tell apart one comment from the next) or when
someone whants to discuss a table or a template.

Best regards,
Helder

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

2015-03-19 Thread Helder .
On Thu, Mar 19, 2015 at 1:35 PM, John phoenixoverr...@gmail.com wrote:
 If it's not clear ask for clarification. I am posting from my mobile, so I
 don't have pretty screenshots handy. I am by no means suggesting that flow
 should use a template. Instead when it detects a reply above a specific
 indent level  it uses the same functionality that od fulfilles

I don't see how that could work when someone wants to reply to a
comment which was made before the outdent template was added. In the
example below, the numbers indicate the time at which each commnent is
added. Once someone makes the 11th reply (in response to 9th comment),
it goest to the left, but then if someone makes a 12th comment
replying to the 1st comment, the formatting doesn't indicate this
anymore (it will appear that 12 is a reply to 11). The same problem
happens for each new reply to previous comments like 13 (which could
be a reply to 2, or to 12).

1
:2
::3
::6
:::7
8
:9
{{outdent|:}}11
:12
::13
:4
::10
:5

My suggestion on this aspect is
https://phabricator.wikimedia.org/T93238

Best regards,
Helder

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

2015-03-19 Thread John
Ok stop being condescending and dismissive. I was proposing that type of
functionality be added to flow as an option for dealing with reply level
excessnes. It is a simple graphic to de-indent a discussion without much
disruption and it improves readability

On Thursday, March 19, 2015, Gerard Meijssen gerard.meijs...@gmail.com
wrote:

 Hoi,
 It does not scale in two ways:

- you do not get everybody to know about such trivia; there are more
relevant things to learn
- it may work on one wiki but how about the next ?

 Remember this is Wikimedia-l not en.wikipedia-l

 Thanks,

   GerardM

 On 19 March 2015 at 17:05, John phoenixoverr...@gmail.com javascript:;
 wrote:

  What do you mean it doesn't scale?
 
  On Thursday, March 19, 2015, Gerard Meijssen gerard.meijs...@gmail.com
 javascript:;
  wrote:
 
   Hoi,
   REALLY .. never ever heard about that template ... and it does not
 scale
   Thanks,
GerardM
  
   On 19 March 2015 at 16:39, John phoenixoverr...@gmail.com
 javascript:;
  javascript:;
   wrote:
  
I think my post might have gotten lost. But what is normal on wiki
 when
   we
hit a reasonable indentation level is to use a template like {{od}}
  that
has a return and an arrow showing that the conversation is continued
unindented
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org javascript:; javascript:;
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
   
   ___
   Wikitech-l mailing list
   Wikitech-l@lists.wikimedia.org javascript:; javascript:;
   https://lists.wikimedia.org/mailman/listinfo/wikitech-l
  ___
  Wikitech-l mailing list
  Wikitech-l@lists.wikimedia.org javascript:;
  https://lists.wikimedia.org/mailman/listinfo/wikitech-l
 
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org javascript:;
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

2015-03-19 Thread Gerard Meijssen
Hoi,
Sorry if you feel that I am condescending. What you said was not clear at
all. For me it was not put in a way that made me understand that you were
proposing a solution. It came across as: look how great Wiki synax is; we
have templates..

I hate templates with a vengeance. They obfuscate what is being said, they
do not transcend the limits of a wiki and it makes people believe that the
templates in use are best practice. Maybe for them but not when you have a
profile on over 100 wikis like me.
Thanks,
 GerardM

On 19 March 2015 at 17:17, John phoenixoverr...@gmail.com wrote:

 Ok stop being condescending and dismissive. I was proposing that type of
 functionality be added to flow as an option for dealing with reply level
 excessnes. It is a simple graphic to de-indent a discussion without much
 disruption and it improves readability

 On Thursday, March 19, 2015, Gerard Meijssen gerard.meijs...@gmail.com
 wrote:

  Hoi,
  It does not scale in two ways:
 
 - you do not get everybody to know about such trivia; there are more
 relevant things to learn
 - it may work on one wiki but how about the next ?
 
  Remember this is Wikimedia-l not en.wikipedia-l
 
  Thanks,
 
GerardM
 
  On 19 March 2015 at 17:05, John phoenixoverr...@gmail.com
 javascript:;
  wrote:
 
   What do you mean it doesn't scale?
  
   On Thursday, March 19, 2015, Gerard Meijssen 
 gerard.meijs...@gmail.com
  javascript:;
   wrote:
  
Hoi,
REALLY .. never ever heard about that template ... and it does not
  scale
Thanks,
 GerardM
   
On 19 March 2015 at 16:39, John phoenixoverr...@gmail.com
  javascript:;
   javascript:;
wrote:
   
 I think my post might have gotten lost. But what is normal on wiki
  when
we
 hit a reasonable indentation level is to use a template like {{od}}
   that
 has a return and an arrow showing that the conversation is
 continued
 unindented
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org javascript:; javascript:;
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org javascript:; javascript:;
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
   ___
   Wikitech-l mailing list
   Wikitech-l@lists.wikimedia.org javascript:;
   https://lists.wikimedia.org/mailman/listinfo/wikitech-l
  
  ___
  Wikitech-l mailing list
  Wikitech-l@lists.wikimedia.org javascript:;
  https://lists.wikimedia.org/mailman/listinfo/wikitech-l
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

2015-03-19 Thread John
What do you mean it doesn't scale?

On Thursday, March 19, 2015, Gerard Meijssen gerard.meijs...@gmail.com
wrote:

 Hoi,
 REALLY .. never ever heard about that template ... and it does not scale
 Thanks,
  GerardM

 On 19 March 2015 at 16:39, John phoenixoverr...@gmail.com javascript:;
 wrote:

  I think my post might have gotten lost. But what is normal on wiki when
 we
  hit a reasonable indentation level is to use a template like {{od}} that
  has a return and an arrow showing that the conversation is continued
  unindented
  ___
  Wikitech-l mailing list
  Wikitech-l@lists.wikimedia.org javascript:;
  https://lists.wikimedia.org/mailman/listinfo/wikitech-l
 
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org javascript:;
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

2015-03-19 Thread Gerard Meijssen
Hoi,
It does not scale in two ways:

   - you do not get everybody to know about such trivia; there are more
   relevant things to learn
   - it may work on one wiki but how about the next ?

Remember this is Wikimedia-l not en.wikipedia-l

Thanks,

  GerardM

On 19 March 2015 at 17:05, John phoenixoverr...@gmail.com wrote:

 What do you mean it doesn't scale?

 On Thursday, March 19, 2015, Gerard Meijssen gerard.meijs...@gmail.com
 wrote:

  Hoi,
  REALLY .. never ever heard about that template ... and it does not scale
  Thanks,
   GerardM
 
  On 19 March 2015 at 16:39, John phoenixoverr...@gmail.com
 javascript:;
  wrote:
 
   I think my post might have gotten lost. But what is normal on wiki when
  we
   hit a reasonable indentation level is to use a template like {{od}}
 that
   has a return and an arrow showing that the conversation is continued
   unindented
   ___
   Wikitech-l mailing list
   Wikitech-l@lists.wikimedia.org javascript:;
   https://lists.wikimedia.org/mailman/listinfo/wikitech-l
  
  ___
  Wikitech-l mailing list
  Wikitech-l@lists.wikimedia.org javascript:;
  https://lists.wikimedia.org/mailman/listinfo/wikitech-l
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

2015-03-19 Thread John
I think my post might have gotten lost. But what is normal on wiki when we
hit a reasonable indentation level is to use a template like {{od}} that
has a return and an arrow showing that the conversation is continued
unindented
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

2015-03-19 Thread Risker
On 19 March 2015 at 11:08, Jon Robson jdlrob...@gmail.com wrote:

 On 19 Mar 2015 7:55 am, Brad Jorsch (Anomie) bjor...@wikimedia.org
 wrote:
 
  On Wed, Mar 18, 2015 at 9:42 PM, Danny Horn dh...@wikimedia.org wrote:
 
   Brad: unfortunately, it's really hard to tell very much from a
 conversation
   with messages like 3: Post C: reply to Post A. You could do that with
 the
   old model, the new model or the perfect magic Nobel-Prize-winning
   discussion threading still to be discovered, and it would probably look
   like nonsense in all three.
  
 
  I shouldn't have used both numbers and post-names, but once I realized
 that
  it was already a bit late and it won't let me edit those posts. Someone
  with appropriate permissions is free to go back and edit them all to
 remove
  the number prefix and let the alphabetical order of the post-names
 suffice
  to indicate the chronological order of the postings, if that would make
 it
  less confusing for you.
 
  The point is the structure you're displaying doesn't make any sense, not
  that the content of my messages isn't anything that might make sense on
 its
  own. My content is explicitly simplified to illustrate the failings in
  the displayed structure. Structure should *facilitate* understanding, but
  in your demo I'd find that understanding the underlying structure of the
  conversation would be *despite* the broken display-structure.
 
  Nor is the point that people can screw up wikitext talk pages in ways
 that
  are even more confusing. That's a given, but Flow is supposed to do
 better.
  Right now it's worse than a well-formatted wikitext talk page (which has
  the advantage that human users can *fix* the structure when a newbie
 breaks
  it).
 
  Comparing http://flow-tests.wmflabs.org/wiki/Wikitext version of
  Topic:Sdrqdcffddyz0jeo to
 

 http://flow-tests.wmflabs.org/wiki/Wikitext_version_of_Topic:Sdrqdcffddyz0jeo
 ,
  I find it much easier in the latter to see what is a reply to what.
 
 
   We've tried in our testing to pretend that we're having real
 conversations,
   so we could see whether there's any logical way to get to eight levels
 of
   nested threading. It's not easy to organize make-believe conversations,
   but if you want to start a thread, I'd be happy to fire up a few
   sockpuppets and pretend to talk about something with you.
  
 
  No thanks. Pretend real conversations are ok for a first assessment at
  usability, but by nature they're likely to be vapid and unlikely to have
  the inter-post complexity of actual conversations on-wiki where people
 are
  concentrating on actually communicating rather than on forcing a
  conversation for the sake of testing.
 

 Let's all be happy then that we are replacing an unloved broken talk
 extension with Flow on a wiki where we have real conversations then ...? :)
 actually dogfooding will make it much easier for us to communicate errors
 with the Flow team and help improve the software.

 I truly hope that soon we can get to a point where we can enable flow on
 all pages on mediawiki.org and this seems like the obvious first step.


The dogfooding has been happening for a while on WMF's own office-wiki.  We
haven't heard any results about that.  Is the system being used more than
the wikitext system?  (i.e., are there more talk page comments now than
there were before?)  Have users expressed satisfaction/dissatisfaction with
the system?  Have they been surveyed?  Do they break down into groups
(e.g., engineering loves it, grants hates it, etc...)?  I hear some stories
(including stories that suggest some groups of staff have pretty much
abandoned talk pages on office-wiki and are now reverting to emails
instead) but without any documentary evidence or analysis it's unreasonable
to think that it is either a net positive OR a net negative.



Risker/Anne
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

2015-03-19 Thread Brad Jorsch (Anomie)
On Thu, Mar 19, 2015 at 11:08 AM, Jon Robson jdlrob...@gmail.com wrote:

 Let's all be happy then that we are replacing an unloved broken talk
 extension with Flow on a wiki where we have real conversations then ...? :)
 actually dogfooding will make it much easier for us to communicate errors
 with the Flow team and help improve the software.


On the other hand, forcing people to dogfood a product with known issues is
a sure way to piss people off and make them hate your product even after
the issues are fixed. Without getting too specific, we know that from
experience.

I'm glad of the initial approach taken here, with the team reaching out to
wikitech-l to ask about known issues before trying a deployment. I'll be
even happier if I learn they have a plan for dealing with Murphy's law that
isn't beg for patience while we rush to fix it.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

2015-03-19 Thread Gerard Meijssen
Hoi,
If you want to have a real world population of editors moving over to flow,
try translatewiki.net when FLOW is ready. It is exclusively LQT and it has
localisation in any languages always.You will not have any religious rants
about Wikitext; there is none and, you will not have official bias.
Thanks,
  GerardM

On 19 March 2015 at 16:18, Risker risker...@gmail.com wrote:

 On 19 March 2015 at 11:08, Jon Robson jdlrob...@gmail.com wrote:

  On 19 Mar 2015 7:55 am, Brad Jorsch (Anomie) bjor...@wikimedia.org
  wrote:
  
   On Wed, Mar 18, 2015 at 9:42 PM, Danny Horn dh...@wikimedia.org
 wrote:
  
Brad: unfortunately, it's really hard to tell very much from a
  conversation
with messages like 3: Post C: reply to Post A. You could do that
 with
  the
old model, the new model or the perfect magic Nobel-Prize-winning
discussion threading still to be discovered, and it would probably
 look
like nonsense in all three.
   
  
   I shouldn't have used both numbers and post-names, but once I realized
  that
   it was already a bit late and it won't let me edit those posts. Someone
   with appropriate permissions is free to go back and edit them all to
  remove
   the number prefix and let the alphabetical order of the post-names
  suffice
   to indicate the chronological order of the postings, if that would make
  it
   less confusing for you.
  
   The point is the structure you're displaying doesn't make any sense,
 not
   that the content of my messages isn't anything that might make sense on
  its
   own. My content is explicitly simplified to illustrate the failings
 in
   the displayed structure. Structure should *facilitate* understanding,
 but
   in your demo I'd find that understanding the underlying structure of
 the
   conversation would be *despite* the broken display-structure.
  
   Nor is the point that people can screw up wikitext talk pages in ways
  that
   are even more confusing. That's a given, but Flow is supposed to do
  better.
   Right now it's worse than a well-formatted wikitext talk page (which
 has
   the advantage that human users can *fix* the structure when a newbie
  breaks
   it).
  
   Comparing http://flow-tests.wmflabs.org/wiki/Wikitext version of
   Topic:Sdrqdcffddyz0jeo to
  
 
 
 http://flow-tests.wmflabs.org/wiki/Wikitext_version_of_Topic:Sdrqdcffddyz0jeo
  ,
   I find it much easier in the latter to see what is a reply to what.
  
  
We've tried in our testing to pretend that we're having real
  conversations,
so we could see whether there's any logical way to get to eight
 levels
  of
nested threading. It's not easy to organize make-believe
 conversations,
but if you want to start a thread, I'd be happy to fire up a few
sockpuppets and pretend to talk about something with you.
   
  
   No thanks. Pretend real conversations are ok for a first assessment
 at
   usability, but by nature they're likely to be vapid and unlikely to
 have
   the inter-post complexity of actual conversations on-wiki where people
  are
   concentrating on actually communicating rather than on forcing a
   conversation for the sake of testing.
  
 
  Let's all be happy then that we are replacing an unloved broken talk
  extension with Flow on a wiki where we have real conversations then ...?
 :)
  actually dogfooding will make it much easier for us to communicate errors
  with the Flow team and help improve the software.
 
  I truly hope that soon we can get to a point where we can enable flow on
  all pages on mediawiki.org and this seems like the obvious first step.
 
 
 The dogfooding has been happening for a while on WMF's own office-wiki.  We
 haven't heard any results about that.  Is the system being used more than
 the wikitext system?  (i.e., are there more talk page comments now than
 there were before?)  Have users expressed satisfaction/dissatisfaction with
 the system?  Have they been surveyed?  Do they break down into groups
 (e.g., engineering loves it, grants hates it, etc...)?  I hear some stories
 (including stories that suggest some groups of staff have pretty much
 abandoned talk pages on office-wiki and are now reverting to emails
 instead) but without any documentary evidence or analysis it's unreasonable
 to think that it is either a net positive OR a net negative.



 Risker/Anne
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

2015-03-19 Thread Gerard Meijssen
Hoi,
REALLY .. never ever heard about that template ... and it does not scale
Thanks,
 GerardM

On 19 March 2015 at 16:39, John phoenixoverr...@gmail.com wrote:

 I think my post might have gotten lost. But what is normal on wiki when we
 hit a reasonable indentation level is to use a template like {{od}} that
 has a return and an arrow showing that the conversation is continued
 unindented
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

2015-03-19 Thread John
If it's not clear ask for clarification. I am posting from my mobile, so I
don't have pretty screenshots handy. I am by no means suggesting that flow
should use a template. Instead when it detects a reply above a specific
indent level  it uses the same functionality that od fulfilles
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

2015-03-18 Thread Quim Gil
On Wed, Mar 18, 2015 at 5:42 AM, Kevin Wayne Williams 
kwwilli...@kwwilliams.com wrote:

 Danny Horn schreef op 2015/03/17 om 21:08:

  And I'm glad to hear that this thread has come close to almost inspiring
 optimism. That's what I'm here for.


 In a sample of one. Still, I guess one finds solace where one can.



While this feature has encountered and keeps encountering resistance and
opposition, it is also collecting adoption and enthusiasm, both in the
editing [1] and technical communities. Looking only at the dark or the
bright side of the picture helps nobody.

mediawiki.org has always been a place for technical experimentation and for
eating our own food. This is why LiquidThreads became a thing there, and
this is also why it makes sense to keep pushing Flow in that space. I
really care about newcomers and I think Flow is an essential piece for
onboarding them [1], but as a self-proclaimed experienced user of online
discussion tools, I also like Flow by its own merit. I praised wikitext
discussions, and I praised LQT discussions, but each on their own decade so
to say. Even if Flow is not perfect today, it improves every month, and I'd
rather help improving it than stopping it. [2]

This thread is clearly not a sample of one. I am personally delighted (and
I'm choosing carefully this word) with the work the Flow/Collaboration team
has been doing identifying what is an objective problem, pushing firmly but
flexibly a vision, and communicating (listening/speaking/acting) with all
their surroundings, release after release. They are listening and
responsive in an array of channels that probably none of us can enumerate.
I don't think there is any single relevant piece of feedback in all these
conversations that hasn't been translated to a Phabricator task, and I
don't think there is any relevant comment in any Flow task of Phabricator
that the maintainers haven't replied to, explaining their thoughts and
plans.

[1] For instance, last Autumn I participated with my volunteer hat in
Amical Wikimedia's annual meeting. This is a small but very active and well
organized community, and reaching out to new editors is their top priority.
They said that VisualEditor is now the essential piece in the many
workshops they organize, and they explaned that the new moment of confusion
is when they introduce the importance of discussions and collaboration.
Having to move from VisualEditor's familiar features and UI to a blank
space where equal signs, colons, and tildes are an essential requirement,
systematically confuses new editors. For this reason, and because
experienced editors can get away with some details when their primary goal
is to onboard future experienced editors, ca.wiki has been testing Flow for
a few months now, and they want it deployed to more pages and namespaces.
There, it's basically the Flow maintainers who are pushing the break.

[2] https://phabricator.wikimedia.org/maniphest/query/OouIbfQn0iB8/#R
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

2015-03-18 Thread Brad Jorsch (Anomie)
On Wed, Mar 18, 2015 at 10:12 AM, Brad Jorsch (Anomie) 
bjor...@wikimedia.org wrote:

 On Tue, Mar 17, 2015 at 8:27 PM, Danny Horn dh...@wikimedia.org wrote:

 So we've figured out a new reply/indentation model that separates those
 two
 functions. We've been testing it out on the flow-tests server [1], and
 we're going to release it to Mediawiki soon.


 I ran some tests at
 http://flow-tests.wmflabs.org/wiki/Topic:Sdrqdcffddyz0jeo. Here are my
 observations:

- Posts B, C, and I all reply to A, but the ordering is C, I, B. I'd
expect replies to the same parent to be ordered chronologically (and I'd
personally expect earliest first).
- Posts B and C both reply to A, but are confusingly at different
indentation levels. I'd expect replies to the same parent to be indented
the same.
- Posts I and E are at the same indentation level, despite I being a
direct reply to A while E is at the end of the chain A→C→D→E. Similar
confusion exists elsewhere. I'd expect two posts at the first indentation
level under the same parent to both be replies to that parent.
- Things are even weirder with post J: Even though D and its reply E
are at the same indentation level, J is suddenly indented more because of
an unrelated post I.
- Things go completely wrong once we hit the maximum depth, it's
impossible to have (or only to be seen as having?) tangents at all. The
reply box doesn't even show up under the post where I actually clicked
Reply.

 All in all, I personally find the resulting structure to be very confusing
 as to what's actually replying to what since the same reply-structure might
 be displayed in different ways (depending on the order the replies were
 entered) and different reply-structures can give rise to the same
 display-structure.


(sorry for the self-reply)

Some of these might be solved by simply abandoning the idea that first
reply = main thread, all others = tangent in favor of displaying flat if
this post and its parent both have no sibling post.

That /would/ mean, though, that a single reply could result in a major
change to display-structure. For example, a reply-chain A→B→C→D→E→F→G would
be displayed flat, and then when someone posts B2 as a reply to A we'd have
A, then indented under it B and B2, then indented under B we'd have
C→D→E→F→G (which might still be displayed flat).

And there'd still be the case that a chain of replies and a single post
with multiple direct replies (none of which were replied to) could be
displayed the same in some cases, but that seems less likely to be
confusing to a reader.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

2015-03-18 Thread Ricordisamoa

Also, some nice-to-have features:

 * provide View Source (showing the wikitext) of someone's post
   https://phabricator.wikimedia.org/T62465
 * post-edit diffs need a Thank link
   https://phabricator.wikimedia.org/T85846
 * Have WhatLinksHere show full information for Flow content
   https://phabricator.wikimedia.org/T92571


Il 17/03/2015 11:05, Ricordisamoa ha scritto:

Hi Nick,
I'm glad the Foundation is finally valuing a usable discussion system.

Unfortunately, there are some serious issues with Flow which will 
prevent my use of it in production if not addressed in full:


 * Administrators *must* be able to to see a deleted Flow board without
   undeleting it (T90972 https://phabricator.wikimedia.org/T90972)
 * Ordinary users *must* be able to move topics between boards (T88140
https://phabricator.wikimedia.org/T88140)
 * Ordinary users *must* be able to edit AND move AND indent AND dedent
   other users' comments (T78253
https://phabricator.wikimedia.org/T78253)
 * An arbitrary indentation level *must* be allowed, with optional
   facilitations for adding an {{outdent}}-like marker
 * Every basic functionality (including but not limited to the
   preview button) *must* work without relying on JavaScript (T60019
https://phabricator.wikimedia.org/T60019)

I see that the implementation of many features was delayed at the 
initial stage of development, but they can't be ignored when trying to 
deploy such a software in production. Thank you.


Il 17/03/2015 01:51, Nick Wilson (Quiddity) ha scritto:

LiquidThreads (LQT) has not been well-supported in a long time. Flow
is in active development, and more real-world use-cases will help
focus attention on the higher-priority features that are needed. To
that end, LQT pages at mediawiki.org will start being converted to
Flow in the next couple of weeks.

There are about 1,600 existing LQT pages on Mediawiki, and the three
most active pages are VisualEditor/Feedback, Project:Support_desk, and
Help_talk:CirrusSearch.[1] The Collaboration team has been running
test conversions of those three pages, and fixing issues that have
come up. Those fixes are almost complete, and the team will be ready
to start converting LQT threads to Flow topics soon. (If you’re
interested in the progress, check out phab:T90788[2] and linked
tasks.) The latest set is visible at a labs test server.[3] See an
example topic comparison here: Flow vs LQT.[4])

The VisualEditor/Feedback page will be converted first (per James'
request), around the middle of next week. We’ll pause to assess any
high-priority changes required. After that, we will start converting
more pages. This process may take a couple of weeks to fully run.

The last page to be converted will be Project:Support_desk, as that is
the largest and most active LQT Board.

LQT Threads that are currently on your watchlist, will still be
watchlisted as Flow Topics. New Topics created at Flow Boards on your
watchlist will appear in your Echo notifications, and you can choose
whether or not to watchlist them.

The LQT namespaces will continue to exist. Links to posts/topics will
redirect appropriately, and the LQT history will remain available at
the original location, as well as being mirrored in the Flow history.

There’s a queue of new features in Flow that will be shipped over the
next month or so:

* Table of Contents is done
* Category support for Flow Header and Topics is done
* VE with editing toolbar coming last week of March (phab:T90763) [5]
* Editing other people’s comments coming last week of March 
(phab:T91086)

* Ability to change the width  side rail in progress, probably out in
April (phab:T88114])
* Search is in progress (no ETA yet) (phab:T76823)
* The ability to choose which Flow notifications end up in Echo,
watchlist, or both, and other more powerful options, will be coming up
next (no ETA yet)

That being said -- there are some LiquidThreads features that don’t
exist in Flow yet.
We’d like to hear which features you use on the current LQT boards,
and that you’re concerned about losing in the Flow conversion. At the
same time, we’d like further suggestions on how we could improve upon
that (or other) features from LQT.

Please give us feedback at
https://www.mediawiki.org/wiki/Topic:Sdoatsbslsafx6lw to keep it
centralized, and test freely at the sandbox.[6]

Much thanks, on behalf of the Collaboration Team,
Quiddity (WMF)

[1] https://www.mediawiki.org/wiki/VisualEditor/Feedback and
https://www.mediawiki.org/wiki/Help_talk:CirrusSearch and
https://www.mediawiki.org/wiki/Project:Support_desk
[2] https://phabricator.wikimedia.org/T90788
[3] http://flow-tests.wmflabs.org/wiki/Testwiki:Support_desk and
http://flow-tests.wmflabs.org/wiki/VisualEditor/Feedback
[4] http://flow-tests.wmflabs.org/wiki/Topic:Qmkwqmp0wfcazy9c and
https://www.mediawiki.org/wiki/Thread:Project:Support_desk/Error_creating_thumbnail:_Unable_to_save_thumbnail_to_destination 


[5] https://phabricator.wikimedia.org/T90763 ,

Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

2015-03-18 Thread Brad Jorsch (Anomie)
On Tue, Mar 17, 2015 at 8:27 PM, Danny Horn dh...@wikimedia.org wrote:

 So we've figured out a new reply/indentation model that separates those two
 functions. We've been testing it out on the flow-tests server [1], and
 we're going to release it to Mediawiki soon.


I ran some tests at
http://flow-tests.wmflabs.org/wiki/Topic:Sdrqdcffddyz0jeo. Here are my
observations:

   - Posts B, C, and I all reply to A, but the ordering is C, I, B. I'd
   expect replies to the same parent to be ordered chronologically (and I'd
   personally expect earliest first).
   - Posts B and C both reply to A, but are confusingly at different
   indentation levels. I'd expect replies to the same parent to be indented
   the same.
   - Posts I and E are at the same indentation level, despite I being a
   direct reply to A while E is at the end of the chain A→C→D→E. Similar
   confusion exists elsewhere. I'd expect two posts at the first indentation
   level under the same parent to both be replies to that parent.
   - Things are even weirder with post J: Even though D and its reply E are
   at the same indentation level, J is suddenly indented more because of an
   unrelated post I.
   - Things go completely wrong once we hit the maximum depth, it's
   impossible to have (or only to be seen as having?) tangents at all. The
   reply box doesn't even show up under the post where I actually clicked
   Reply.

All in all, I personally find the resulting structure to be very confusing
as to what's actually replying to what since the same reply-structure might
be displayed in different ways (depending on the order the replies were
entered) and different reply-structures can give rise to the same
display-structure.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

2015-03-18 Thread Helder .
On Wed, Mar 18, 2015 at 11:12 AM, Brad Jorsch (Anomie)
bjor...@wikimedia.org wrote:
 On Tue, Mar 17, 2015 at 8:27 PM, Danny Horn dh...@wikimedia.org wrote:

 So we've figured out a new reply/indentation model that separates those two
 functions. We've been testing it out on the flow-tests server [1], and
 we're going to release it to Mediawiki soon.


 I ran some tests at
 http://flow-tests.wmflabs.org/wiki/Topic:Sdrqdcffddyz0jeo. Here are my
 observations:
 ...

These look like the same problems reported last week on this thread:
https://pt.wikipedia.org/w/index.php?title=WP:Esplanada/propostas/Flow_na_Wikip%C3%A9dia:Contato_%285mar2015%29oldid=41541009

Best regards,
Helder

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

2015-03-18 Thread Danny Horn
Brad: unfortunately, it's really hard to tell very much from a conversation
with messages like 3: Post C: reply to Post A. You could do that with the
old model, the new model or the perfect magic Nobel-Prize-winning
discussion threading still to be discovered, and it would probably look
like nonsense in all three.

We've tried in our testing to pretend that we're having real conversations,
so we could see whether there's any logical way to get to eight levels of
nested threading. It's not easy to organize make-believe conversations, but
if you want to start a thread, I'd be happy to fire up a few sockpuppets
and pretend to talk about something with you.



On Wed, Mar 18, 2015 at 7:35 AM, Brad Jorsch (Anomie) bjor...@wikimedia.org
 wrote:

 On Wed, Mar 18, 2015 at 10:12 AM, Brad Jorsch (Anomie) 
 bjor...@wikimedia.org wrote:

  On Tue, Mar 17, 2015 at 8:27 PM, Danny Horn dh...@wikimedia.org wrote:
 
  So we've figured out a new reply/indentation model that separates those
  two
  functions. We've been testing it out on the flow-tests server [1], and
  we're going to release it to Mediawiki soon.
 
 
  I ran some tests at
  http://flow-tests.wmflabs.org/wiki/Topic:Sdrqdcffddyz0jeo. Here are my
  observations:
 
 - Posts B, C, and I all reply to A, but the ordering is C, I, B. I'd
 expect replies to the same parent to be ordered chronologically (and
 I'd
 personally expect earliest first).
 - Posts B and C both reply to A, but are confusingly at different
 indentation levels. I'd expect replies to the same parent to be
 indented
 the same.
 - Posts I and E are at the same indentation level, despite I being a
 direct reply to A while E is at the end of the chain A→C→D→E. Similar
 confusion exists elsewhere. I'd expect two posts at the first
 indentation
 level under the same parent to both be replies to that parent.
 - Things are even weirder with post J: Even though D and its reply E
 are at the same indentation level, J is suddenly indented more
 because of
 an unrelated post I.
 - Things go completely wrong once we hit the maximum depth, it's
 impossible to have (or only to be seen as having?) tangents at all.
 The
 reply box doesn't even show up under the post where I actually clicked
 Reply.
 
  All in all, I personally find the resulting structure to be very
 confusing
  as to what's actually replying to what since the same reply-structure
 might
  be displayed in different ways (depending on the order the replies were
  entered) and different reply-structures can give rise to the same
  display-structure.
 

 (sorry for the self-reply)

 Some of these might be solved by simply abandoning the idea that first
 reply = main thread, all others = tangent in favor of displaying flat if
 this post and its parent both have no sibling post.

 That /would/ mean, though, that a single reply could result in a major
 change to display-structure. For example, a reply-chain A→B→C→D→E→F→G would
 be displayed flat, and then when someone posts B2 as a reply to A we'd have
 A, then indented under it B and B2, then indented under B we'd have
 C→D→E→F→G (which might still be displayed flat).

 And there'd still be the case that a chain of replies and a single post
 with multiple direct replies (none of which were replied to) could be
 displayed the same in some cases, but that seems less likely to be
 confusing to a reader.
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

2015-03-17 Thread Brad Jorsch (Anomie)
On Tue, Mar 17, 2015 at 11:17 AM, Marc A. Pelletier m...@uberbox.org
wrote:

 Indentation is a crappy workaround for when your communication system
 does not support a sane threading model - it isn't a threading model or
 a substitute for one.


Err, what's the threading model in Flow's UI? Or Facebook, phpbb, and so
on, or whatever other site you were referring to that knitting grandmothers
use? Can you really call not having any (user-visible) threading model a
threading model?

From what I've seen of those types of discussions, people have to either
explicitly refer back to whatever they're replying to (e.g. Twitter tries
to, and doesn't very well from what I've seen), quote whatever they're
replying to (e.g. phpbb, email (especially how Gmail renders it)), and/or
just deal with having to dig through an undifferentiated pile of replies to
find the ones that might be replying to the post they're interested in
(phpbb, Facebook).
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

2015-03-17 Thread Brad Jorsch (Anomie)
On Tue, Mar 17, 2015 at 10:56 AM, Risker risker...@gmail.com wrote:

 On 17 March 2015 at 10:49, Brad Jorsch (Anomie) bjor...@wikimedia.org
 wrote:

  On Tue, Mar 17, 2015 at 10:35 AM, Risker risker...@gmail.com wrote:
 
   On 17 March 2015 at 09:45, Brad Jorsch (Anomie) bjor...@wikimedia.org
 
   wrote:
  
On Tue, Mar 17, 2015 at 9:37 AM, Ricordisamoa 
ricordisa...@openmailbox.org
wrote:
   
Software cannot understand which post a message replies to.

   
It can, and more easily than with raw wikitext, as long as the
 correct
reply button is used, i.e. if people actually click reply instead
 of
using the already-there box for creating a new top-level post in
 the
topic.
   
   
  
   The software can tell, but visually it is nearly impossible to
 determine
   which message is being responded to when everything has essentially the
   same indent level.
  
 
  Granted, but that's because the output format is poor rather than the
  software being unable to tell.
 
 

 Thank you, Brad.  Is the output format not determined by the parameters in
 the software?


The software knows the reply structure, but when outputting it ignores that
structure beyond the maximum depth.


 It just strikes me as weird that the software that we keep being told will
 improve communication and collaboration is deliberately designed in such a
 way that it is difficult for the human users (as opposed to the software)
 to be able to immediately discern who is responding to whom.


A summary of their rationale seems to be at
https://www.mediawiki.org/wiki/Flow/User_to_User_Discussions#Thread_Depth_Models.
I think I'll refrain from commenting on it.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

2015-03-17 Thread Marc A. Pelletier
On 15-03-17 10:56 AM, Risker wrote:
 It just strikes me as weird that the software that we keep being told will
 improve communication and collaboration is deliberately designed in such a
 way that it is difficult for the human users (as opposed to the software)
 to be able to immediately discern who is responding to whom.

[...] that it is difficuly for [a very small subset of] human users
[used to a different, baroque system] to be able to [...]

I see, day in and day out, literally thouands upon thousands of fora on
Internet where millions of people from grandmothers sharing their latest
knitting tricks to software developers manage to communicate effectively
and figure out who is talking despite the lack of indentation pushing
everything in small boxes to the right margin, and without the ability
(or need!) to work around the flaws of that system with horrid hacks
like manual outdents.

Indentation is a crappy workaround for when your communication system
does not support a sane threading model - it isn't a threading model or
a substitute for one.

-- Marc


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

2015-03-17 Thread Danny Horn
Yes, the plan is for editing posts to go everywhere. We want to go a little
bit extra slow with deploying that feature just to make sure that the
pieces we've put in place actually work properly. So it's rolling out to
Mediawiki.org next week, and then English and Russian WP the week after.
(The people at Russian WP that we've been talking to said that they weren't
even interested in test pages until we had editing posts, because Russian
is hardcore.)

Having the ability to edit other people's posts can be very useful, but
there's also a strong cultural tradition that says that we basically don't
do it, except under certain circumstances. People using Flow won't
necessarily come to it with that same tradition, so we want to see that the
feature set encourages the useful editing, and doesn't encourage people to
mess with the wording or intent of someone else's post. Once we've seen it
in action for a little while, it'll go live to all the other languages.

And I'm glad to hear that this thread has come close to almost inspiring
optimism. That's what I'm here for.


On Tue, Mar 17, 2015 at 8:00 PM, MZMcBride z...@mzmcbride.com wrote:

 Ricordisamoa wrote:
 Il 17/03/2015 23:29, Danny Horn ha scritto:
  -- The ability to edit other people's posts will be out on Mediawiki by
the end of next week. We’ve made a few interface changes to support
that. Posts that have been edited by someone that isn’t the original
poster now say “Edited by Username 3 minutes ago”, so that it’s easy
for everyone to see what’s happened. When someone edits an existing
post, we fixed the diff pages so that you can browse between previous
and next changes. [1]
 
 By Mediawiki, do you mean www.mediawiki.org?
 I would like to stress the importance of such ability for *all* wikis.
 On Wikimedia, unlike most other sites, nothing is 'owned' by someone,
 and protection is only a precautionary measure. Flow is supposed to work
 with this model.

 Agreed. The ability of anyone to revert bad edits also acts a major
 anti-abuse feature. As has been pointed out many times, there's a very
 real spam concern if only the author and admins can edit posts.

  -- Make the links to threads look nicer -- Yeah, this is annoying. It’s
not in our top five list of annoyances at the moment, but we’ll keep
checking off annoying items. Nicer links will get its turn. [5]
 [5] Less ugly topic page links: https://phabricator.wikimedia.org/T59154

 Erik B. says on that task that the deployment of ContentHandler should
 help. This is excellent news.

 Thanks for the detailed and timely reply.

 My thanks as well! This e-mail really helped alleviate some of my concerns
 with Flow's development. I have too much experience with Flow's
 predecessor LiquidThreads to say that I'm optimistic, but I'm definitely
 less concerned now about Flow's future than I was when I started the day.

 MZMcBride



 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

2015-03-17 Thread Ricordisamoa

Il 18/03/2015 05:08, Danny Horn ha scritto:

Yes, the plan is for editing posts to go everywhere. We want to go a little
bit extra slow with deploying that feature just to make sure that the
pieces we've put in place actually work properly. So it's rolling out to
Mediawiki.org next week, and then English and Russian WP the week after.
(The people at Russian WP that we've been talking to said that they weren't
even interested in test pages until we had editing posts, because Russian
is hardcore.)

Having the ability to edit other people's posts can be very useful, but
there's also a strong cultural tradition that says that we basically don't
do it, except under certain circumstances. People using Flow won't
necessarily come to it with that same tradition, so we want to see that the
feature set encourages the useful editing, and doesn't encourage people to
mess with the wording or intent of someone else's post. Once we've seen it
in action for a little while, it'll go live to all the other languages.


Of course it should be used carefully and for minor changes only. I 
agree with T91086 https://phabricator.wikimedia.org/T91086.




And I'm glad to hear that this thread has come close to almost inspiring
optimism. That's what I'm here for.


On Tue, Mar 17, 2015 at 8:00 PM, MZMcBride z...@mzmcbride.com wrote:


Ricordisamoa wrote:

Il 17/03/2015 23:29, Danny Horn ha scritto:

-- The ability to edit other people's posts will be out on Mediawiki by
   the end of next week. We’ve made a few interface changes to support
   that. Posts that have been edited by someone that isn’t the original
   poster now say “Edited by Username 3 minutes ago”, so that it’s easy
   for everyone to see what’s happened. When someone edits an existing
   post, we fixed the diff pages so that you can browse between previous
   and next changes. [1]

By Mediawiki, do you mean www.mediawiki.org?
I would like to stress the importance of such ability for *all* wikis.
On Wikimedia, unlike most other sites, nothing is 'owned' by someone,
and protection is only a precautionary measure. Flow is supposed to work
with this model.

Agreed. The ability of anyone to revert bad edits also acts a major
anti-abuse feature. As has been pointed out many times, there's a very
real spam concern if only the author and admins can edit posts.


-- Make the links to threads look nicer -- Yeah, this is annoying. It’s
   not in our top five list of annoyances at the moment, but we’ll keep
   checking off annoying items. Nicer links will get its turn. [5]
[5] Less ugly topic page links: https://phabricator.wikimedia.org/T59154

Erik B. says on that task that the deployment of ContentHandler should
help. This is excellent news.


Thanks for the detailed and timely reply.

My thanks as well! This e-mail really helped alleviate some of my concerns
with Flow's development. I have too much experience with Flow's
predecessor LiquidThreads to say that I'm optimistic, but I'm definitely
less concerned now about Flow's future than I was when I started the day.

MZMcBride



___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

2015-03-17 Thread Kevin Wayne Williams

Danny Horn schreef op 2015/03/17 om 21:08:


And I'm glad to hear that this thread has come close to almost inspiring
optimism. That's what I'm here for.


In a sample of one. Still, I guess one finds solace where one can.

KWW

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

2015-03-17 Thread Kevin Wayne Williams

Nick Wilson (Quiddity) schreef op 2015/03/16 om 19:03:

On Mon, Mar 16, 2015 at 6:02 PM, Risker risker...@gmail.com wrote:

How about just converting those threads back to Wikitext, instead?  That
script already exists, I've seen it used on Mediawiki. Will it mess up the
pages that have already been converted using that script?

Bottom line, it makes no sense to replace software that was considered
barely suitable when it was first developed with new software that can't
even do what that old, long-neglected software could do...and in several
cases, there is no intention to ever add the features already available
using Wikitext.

As expectations increase for project users to post their
comments/concerns/ideas/observations on Mediawiki, the use of Flow will
become a barrier for participation.

Risker/Anne



Converting LQT to Wikitext would lose the major benefits of:
* per-Topic watchlisting,
* per-Topic category support,
* Sortable views (with Filterable views on the roadmap [1]),
as well as the immensely easier process for new-editors to be able to
participate in discussions, and be notified about replies.[2]



But it would provide the advantage of using the standardized discussion 
technique used in virtually all Wikimedia installations. There doesn't 
seem to be any particular user demand to adopt Flow, so there's no 
reason to believe it will gain any more traction than LQT ever did.


KWW


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

2015-03-17 Thread Pine W
Pardon me if I missed an announcement, but will there be any office hours
about Flow in the near future? I have a few general questions about
cross-wiki discussions and the relationship of Flow to VE. (I'm mostly
focused on VE right now.)

Thanks,
Pine
On Mar 16, 2015 11:21 PM, Kevin Wayne Williams kwwilli...@kwwilliams.com
wrote:

 Nick Wilson (Quiddity) schreef op 2015/03/16 om 19:03:

 On Mon, Mar 16, 2015 at 6:02 PM, Risker risker...@gmail.com wrote:

 How about just converting those threads back to Wikitext, instead?  That
 script already exists, I've seen it used on Mediawiki. Will it mess up
 the
 pages that have already been converted using that script?

 Bottom line, it makes no sense to replace software that was considered
 barely suitable when it was first developed with new software that
 can't
 even do what that old, long-neglected software could do...and in several
 cases, there is no intention to ever add the features already available
 using Wikitext.

 As expectations increase for project users to post their
 comments/concerns/ideas/observations on Mediawiki, the use of Flow will
 become a barrier for participation.

 Risker/Anne


 Converting LQT to Wikitext would lose the major benefits of:
 * per-Topic watchlisting,
 * per-Topic category support,
 * Sortable views (with Filterable views on the roadmap [1]),
 as well as the immensely easier process for new-editors to be able to
 participate in discussions, and be notified about replies.[2]


 But it would provide the advantage of using the standardized discussion
 technique used in virtually all Wikimedia installations. There doesn't seem
 to be any particular user demand to adopt Flow, so there's no reason to
 believe it will gain any more traction than LQT ever did.

 KWW


 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

2015-03-17 Thread Gerard Meijssen
Hoi,
Sorry but Wikitext is of such a nature that I do not use it as much as
possible. LiquidThreads was a huge step forward and I still find it
astonishing that it was left to rot for such a long time.I really welcome
the move towards Flow.

Flow is not an  inadequate substitute, it is what will replace wikitext
hopefully soon for discussions. I cannot wait.
Thanks,
  GerardM

On 17 March 2015 at 06:43, Kevin Wayne Williams kwwilli...@kwwilliams.com
wrote:

 Nick Wilson (Quiddity) schreef op 2015/03/16 om 17:51:

 LiquidThreads (LQT) has not been well-supported in a long time. Flow
 is in active development, and more real-world use-cases will help
 focus attention on the higher-priority features that are needed. To
 that end, LQT pages at mediawiki.org will start being converted to
 Flow in the next couple of weeks.


 I assume that the intention is to greater increase the divide between
 Wikipedia editors and the Wikimedia Foundation? It would be nice if the WMF
 would focus on becoming good with the tools that editors use instead of
 attempting to convince them that inadequate substitutes are adequate.

 KWW



 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

2015-03-17 Thread Erik Moeller
On Mon, Mar 16, 2015 at 11:21 PM, Kevin Wayne Williams
kwwilli...@kwwilliams.com wrote:
 There doesn't seem to be any particular user demand to adopt Flow,
 so there's no reason to believe it will gain any more traction than LQT ever 
 did.

There was significant community interest and momentum behind LQT
including various votes to enable it [1], and there is significant
interest in Flow now [2]. The main thing that prevented LQT from wider
adoption was not lack of community interest, it was our decision to
put the project on hold due to both major architectural concerns and
resource constraints at the time. We've committed to providing an
upgrade path, and this is our follow-through to that commitment.

Our main objective in Flow development is to solve for progressively
more challenging collaboration/conversation use cases well, and to
demonstrate positive impact at increasing scale, with the goal of
providing a better experience for new and experienced editors alike.
We recognize that we still have a long way to go, but we can already
demonstrate that the system does one thing well, which is to make the
process of using talk pages much more understandable for new users:

https://www.mediawiki.org/wiki/Flow/Moderated_Testing,_November,_2014:_talk_pages_and_Flow

We're also seeing, as Nick pointed out, that users in a mentorship use
case are more likely to follow-up with their mentors. This is a pretty
big deal -- quantitative research shows that this type of mentorship
improves engagement and retention of new users. [3]

So mentorship is an obvious early stage use case, even if the rest of
a community functions through traditional talk pages. Village pump
type pages that are fairly distinct from article talk pages are
another obvious use case where a more forum-like system can relatively
quickly outperform the talk page based approach that is rife with edit
conflicts and other annoyances. We are trialing the first such use
case in Catalan with lots of community participation.

As for inconsistency and fragmentation of mediawiki.org, if anything,
the conversion of LQT pages on mediawiki.org will create greater
consistency as we're already using Flow on Beta Features talk pages (
https://www.mediawiki.org/wiki/Talk:Content_translation is a nice
example of a feedback page with lots of continuous and substantive
comments from experienced users).

Flow may not serve major use cases on English Wikipedia today, or
tomorrow; that's okay. Smaller projects are often happy to adopt
technologies that may not meet the expectations of a large, mature
community like en.wp yet, because they may be more concerned with the
experience of new users than with the risks or inconveniences
associated with features in earlier stages of development. (I am not
dismissing either risks or inconveniences in saying so, as the
requirements do of course differ at different scale.)

We, in turn, remain committed to building tools that serve users well,
continuously improving, and continuously demonstrating value through
data and qualitative validation. [4] This is but a small step, but
it's an important one.

Erik

[1] https://phabricator.wikimedia.org/search/query/radjv9rJZNLU/#R
[2] https://www.mediawiki.org/wiki/Flow/Rollout
[3] http://arxiv.org/pdf/1409.1496v1.pdf
[4] What we learn is summarized in our quarterly reviews, most
recently: 
https://upload.wikimedia.org/wikipedia/commons/5/5f/Collaboration_Q3_2014-15_WMF_Quarterly_Review.pdf

-- 
Erik Möller
VP of Product  Strategy, Wikimedia Foundation

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

2015-03-17 Thread Nick Wilson (Quiddity)
Now done. (I'd meant to earlier, along with the Tech/News entry). Thanks
for the reminder, and the general support. Specific suggestions/requests
are much appreciated. Please do tell me which elements of LQT you (all)
regularly use and can't see in the Sandbox or short-term roadmap.
I'll respond to some of the other questions when I awake.
On Mar 16, 2015 10:33 PM, Florian Schmidt 
florian.schmidt.wel...@t-online.de wrote:

 I fully upport and welcome this, but at least for Project:Support_desk you
 should communicate this on this LQT board, too, that it will be converted
 (if you didn't do hat already, i haven't looked now, because LQT ist
 terrible on mobile :P). There are probably very active supporters, who
 haven't subscribed this list, but they should have the possibility to post
 their needs and opinions about that.

 Best,
 Florian

 Gesendet mit meinem HTC

 - Reply message -
 Von: Nick Wilson (Quiddity) nwil...@wikimedia.org
 An: Wikimedia developers wikitech-l@lists.wikimedia.org
 Betreff: [Wikitech-l] Starting conversion of LiquidThreads to Flow at
 mediawiki.org
 Datum: Di., März 17, 2015 01:51

 LiquidThreads (LQT) has not been well-supported in a long time. Flow
 is in active development, and more real-world use-cases will help
 focus attention on the higher-priority features that are needed. To
 that end, LQT pages at mediawiki.org will start being converted to
 Flow in the next couple of weeks.

 There are about 1,600 existing LQT pages on Mediawiki, and the three
 most active pages are VisualEditor/Feedback, Project:Support_desk, and
 Help_talk:CirrusSearch.[1] The Collaboration team has been running
 test conversions of those three pages, and fixing issues that have
 come up. Those fixes are almost complete, and the team will be ready
 to start converting LQT threads to Flow topics soon. (If you’re
 interested in the progress, check out phab:T90788[2] and linked
 tasks.) The latest set is visible at a labs test server.[3] See an
 example topic comparison here: Flow vs LQT.[4])

 The VisualEditor/Feedback page will be converted first (per James'
 request), around the middle of next week. We’ll pause to assess any
 high-priority changes required. After that, we will start converting
 more pages. This process may take a couple of weeks to fully run.

 The last page to be converted will be Project:Support_desk, as that is
 the largest and most active LQT Board.

 LQT Threads that are currently on your watchlist, will still be
 watchlisted as Flow Topics. New Topics created at Flow Boards on your
 watchlist will appear in your Echo notifications, and you can choose
 whether or not to watchlist them.

 The LQT namespaces will continue to exist. Links to posts/topics will
 redirect appropriately, and the LQT history will remain available at
 the original location, as well as being mirrored in the Flow history.

 There’s a queue of new features in Flow that will be shipped over the
 next month or so:

 * Table of Contents is done
 * Category support for Flow Header and Topics is done
 * VE with editing toolbar coming last week of March (phab:T90763) [5]
 * Editing other people’s comments coming last week of March (phab:T91086)
 * Ability to change the width  side rail in progress, probably out in
 April (phab:T88114])
 * Search is in progress (no ETA yet) (phab:T76823)
 * The ability to choose which Flow notifications end up in Echo,
 watchlist, or both, and other more powerful options, will be coming up
 next (no ETA yet)

 That being said -- there are some LiquidThreads features that don’t
 exist in Flow yet.
 We’d like to hear which features you use on the current LQT boards,
 and that you’re concerned about losing in the Flow conversion. At the
 same time, we’d like further suggestions on how we could improve upon
 that (or other) features from LQT.

 Please give us feedback at
 https://www.mediawiki.org/wiki/Topic:Sdoatsbslsafx6lw to keep it
 centralized, and test freely at the sandbox.[6]

 Much thanks, on behalf of the Collaboration Team,
 Quiddity (WMF)

 [1] https://www.mediawiki.org/wiki/VisualEditor/Feedback and
 https://www.mediawiki.org/wiki/Help_talk:CirrusSearch and
 https://www.mediawiki.org/wiki/Project:Support_desk
 [2] https://phabricator.wikimedia.org/T90788
 [3] http://flow-tests.wmflabs.org/wiki/Testwiki:Support_desk and
 http://flow-tests.wmflabs.org/wiki/VisualEditor/Feedback
 [4] http://flow-tests.wmflabs.org/wiki/Topic:Qmkwqmp0wfcazy9c and

 https://www.mediawiki.org/wiki/Thread:Project:Support_desk/Error_creating_thumbnail:_Unable_to_save_thumbnail_to_destination
 [5] https://phabricator.wikimedia.org/T90763 ,
 https://phabricator.wikimedia.org/T91086 ,
 https://phabricator.wikimedia.org/T88114 ,
 https://phabricator.wikimedia.org/T76823
 [6] https://www.mediawiki.org/wiki/Talk:Sandbox


 --
 Nick Wilson (Quiddity)
 Community Liaison
 Wikimedia Foundation

 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org

Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

2015-03-17 Thread Ricordisamoa

Hi Nick,
I'm glad the Foundation is finally valuing a usable discussion system.

Unfortunately, there are some serious issues with Flow which will 
prevent my use of it in production if not addressed in full:


 * Administrators *must* be able to to see a deleted Flow board without
   undeleting it (T90972 https://phabricator.wikimedia.org/T90972)
 * Ordinary users *must* be able to move topics between boards (T88140
   https://phabricator.wikimedia.org/T88140)
 * Ordinary users *must* be able to edit AND move AND indent AND dedent
   other users' comments (T78253
   https://phabricator.wikimedia.org/T78253)
 * An arbitrary indentation level *must* be allowed, with optional
   facilitations for adding an {{outdent}}-like marker
 * Every basic functionality (including but not limited to the
   preview button) *must* work without relying on JavaScript (T60019
   https://phabricator.wikimedia.org/T60019)

I see that the implementation of many features was delayed at the 
initial stage of development, but they can't be ignored when trying to 
deploy such a software in production. Thank you.


Il 17/03/2015 01:51, Nick Wilson (Quiddity) ha scritto:

LiquidThreads (LQT) has not been well-supported in a long time. Flow
is in active development, and more real-world use-cases will help
focus attention on the higher-priority features that are needed. To
that end, LQT pages at mediawiki.org will start being converted to
Flow in the next couple of weeks.

There are about 1,600 existing LQT pages on Mediawiki, and the three
most active pages are VisualEditor/Feedback, Project:Support_desk, and
Help_talk:CirrusSearch.[1] The Collaboration team has been running
test conversions of those three pages, and fixing issues that have
come up. Those fixes are almost complete, and the team will be ready
to start converting LQT threads to Flow topics soon. (If you’re
interested in the progress, check out phab:T90788[2] and linked
tasks.) The latest set is visible at a labs test server.[3] See an
example topic comparison here: Flow vs LQT.[4])

The VisualEditor/Feedback page will be converted first (per James'
request), around the middle of next week. We’ll pause to assess any
high-priority changes required. After that, we will start converting
more pages. This process may take a couple of weeks to fully run.

The last page to be converted will be Project:Support_desk, as that is
the largest and most active LQT Board.

LQT Threads that are currently on your watchlist, will still be
watchlisted as Flow Topics. New Topics created at Flow Boards on your
watchlist will appear in your Echo notifications, and you can choose
whether or not to watchlist them.

The LQT namespaces will continue to exist. Links to posts/topics will
redirect appropriately, and the LQT history will remain available at
the original location, as well as being mirrored in the Flow history.

There’s a queue of new features in Flow that will be shipped over the
next month or so:

* Table of Contents is done
* Category support for Flow Header and Topics is done
* VE with editing toolbar coming last week of March (phab:T90763) [5]
* Editing other people’s comments coming last week of March (phab:T91086)
* Ability to change the width  side rail in progress, probably out in
April (phab:T88114])
* Search is in progress (no ETA yet) (phab:T76823)
* The ability to choose which Flow notifications end up in Echo,
watchlist, or both, and other more powerful options, will be coming up
next (no ETA yet)

That being said -- there are some LiquidThreads features that don’t
exist in Flow yet.
We’d like to hear which features you use on the current LQT boards,
and that you’re concerned about losing in the Flow conversion. At the
same time, we’d like further suggestions on how we could improve upon
that (or other) features from LQT.

Please give us feedback at
https://www.mediawiki.org/wiki/Topic:Sdoatsbslsafx6lw to keep it
centralized, and test freely at the sandbox.[6]

Much thanks, on behalf of the Collaboration Team,
Quiddity (WMF)

[1] https://www.mediawiki.org/wiki/VisualEditor/Feedback and
https://www.mediawiki.org/wiki/Help_talk:CirrusSearch and
https://www.mediawiki.org/wiki/Project:Support_desk
[2] https://phabricator.wikimedia.org/T90788
[3] http://flow-tests.wmflabs.org/wiki/Testwiki:Support_desk and
http://flow-tests.wmflabs.org/wiki/VisualEditor/Feedback
[4] http://flow-tests.wmflabs.org/wiki/Topic:Qmkwqmp0wfcazy9c and
https://www.mediawiki.org/wiki/Thread:Project:Support_desk/Error_creating_thumbnail:_Unable_to_save_thumbnail_to_destination
[5] https://phabricator.wikimedia.org/T90763 ,
https://phabricator.wikimedia.org/T91086 ,
https://phabricator.wikimedia.org/T88114 ,
https://phabricator.wikimedia.org/T76823
[6] https://www.mediawiki.org/wiki/Talk:Sandbox




___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

2015-03-17 Thread MZMcBride
Ricordisamoa wrote:
Il 17/03/2015 23:29, Danny Horn ha scritto:
 -- The ability to edit other people's posts will be out on Mediawiki by
   the end of next week. We’ve made a few interface changes to support
   that. Posts that have been edited by someone that isn’t the original
   poster now say “Edited by Username 3 minutes ago”, so that it’s easy
   for everyone to see what’s happened. When someone edits an existing
   post, we fixed the diff pages so that you can browse between previous
   and next changes. [1]

By Mediawiki, do you mean www.mediawiki.org?
I would like to stress the importance of such ability for *all* wikis.
On Wikimedia, unlike most other sites, nothing is 'owned' by someone,
and protection is only a precautionary measure. Flow is supposed to work
with this model.

Agreed. The ability of anyone to revert bad edits also acts a major
anti-abuse feature. As has been pointed out many times, there's a very
real spam concern if only the author and admins can edit posts.

 -- Make the links to threads look nicer -- Yeah, this is annoying. It’s
   not in our top five list of annoyances at the moment, but we’ll keep
   checking off annoying items. Nicer links will get its turn. [5]
[5] Less ugly topic page links: https://phabricator.wikimedia.org/T59154

Erik B. says on that task that the deployment of ContentHandler should
help. This is excellent news.

Thanks for the detailed and timely reply.

My thanks as well! This e-mail really helped alleviate some of my concerns
with Flow's development. I have too much experience with Flow's
predecessor LiquidThreads to say that I'm optimistic, but I'm definitely
less concerned now about Flow's future than I was when I started the day.

MZMcBride



___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

2015-03-17 Thread Ricordisamoa

Il 17/03/2015 23:29, Danny Horn ha scritto:

Thanks for all of the questions and suggestions. Flow is still in active
development, and there's a lot of feature work being done right now. Some
of the features that have been mentioned in this thread are actually just
about to be released, and some are coming up over the next month or so.

Here's how it breaks down:

Coming out very soon:

-- The ability to edit other people's posts will be out on Mediawiki by the
end of next week. We’ve made a few interface changes to support that. Posts
that have been edited by someone that isn’t the original poster now say
“Edited by Username 3 minutes ago”, so that it’s easy for everyone to see
what’s happened. When someone edits an existing post, we fixed the diff
pages so that you can browse between previous and next changes. [1]


By Mediawiki, do you mean www.mediawiki.org?
I would like to stress the importance of such ability for *all* wikis. 
On Wikimedia, unlike most other sites, nothing is 'owned' by someone, 
and protection is only a precautionary measure. Flow is supposed to work 
with this model.




-- Sane threading model, with more levels for replies and tangents -- also
coming out next week. Talking about this feature gets super lengthy and
complicated, so I’ll write another post right after this one that will give
all the details for people who are interested. [2]

-- Admins viewing deleted boards without undeleting it -- coming out in
three weeks. [3]


Working on these next:

-- Moving topics between boards -- We’ve got designs and estimates for
this, and I’m expecting that to come out in April. [4]

-- More powerful watchlist/notification functionality -- This is a very
important feature that will be getting a lot of team attention over the
next month. We need to re-read the mountain of requests that have
accumulated, and reach out again to you for fresh feedback. Improvements
will aim to be continuous and incremental.


Future plans, not scheduled yet:

-- Full wikitext toolbar -- We’re going to release v1 of a VisualEditor
toolbar in the next couple of weeks. This version will just have three
functions: Bold/Italics, Links and Mentions. (Mentions will have
autocomplete with user names that have already participated in the thread.)
We’ll definitely be doing more work on toolbars coming up, but we want to
see how this first one works before we make any solid plans.

-- Make the links to threads look nicer -- Yeah, this is annoying. It’s not
in our top five list of annoyances at the moment, but we’ll keep checking
off annoying items. Nicer links will get its turn. [5]

-- No-JS and accessibility -- We’ve done some work on this, and there will
be more coming up. [6]


So there's a lot of work still to be done, but we're adding a lot of
features. I hope this helps explain where we are in the process.

We’re going to have an Office Hours Google Hangout on Monday at 19:00 UTC,
so we can answer questions and talk about the project. If people are
interested, we can schedule more of these.

Thanks again for all the specific feature requests and concerns. We’ll be
requesting larger and wider quantities of feedback in the near future, as
some of the upcoming features are planned and built.

Danny


Phabricator tickets mentioned above:
[1] Flow post editing for autoconfirmed users:
https://phabricator.wikimedia.org/T90670
[2] Prototype for new indentation model:
https://phabricator.wikimedia.org/T88501
[3] Admins viewing deleted boards: https://phabricator.wikimedia.org/T90972
[4] Moving topics between boards: https://phabricator.wikimedia.org/T88140
[5] Less ugly topic page links: https://phabricator.wikimedia.org/T59154
[6] No-JS tracking: https://phabricator.wikimedia.org/T60019


Thanks for the detailed and timely reply.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

2015-03-17 Thread Danny Horn
Thanks for all of the questions and suggestions. Flow is still in active
development, and there's a lot of feature work being done right now. Some
of the features that have been mentioned in this thread are actually just
about to be released, and some are coming up over the next month or so.

Here's how it breaks down:

Coming out very soon:

-- The ability to edit other people's posts will be out on Mediawiki by the
end of next week. We’ve made a few interface changes to support that. Posts
that have been edited by someone that isn’t the original poster now say
“Edited by Username 3 minutes ago”, so that it’s easy for everyone to see
what’s happened. When someone edits an existing post, we fixed the diff
pages so that you can browse between previous and next changes. [1]

-- Sane threading model, with more levels for replies and tangents -- also
coming out next week. Talking about this feature gets super lengthy and
complicated, so I’ll write another post right after this one that will give
all the details for people who are interested. [2]

-- Admins viewing deleted boards without undeleting it -- coming out in
three weeks. [3]


Working on these next:

-- Moving topics between boards -- We’ve got designs and estimates for
this, and I’m expecting that to come out in April. [4]

-- More powerful watchlist/notification functionality -- This is a very
important feature that will be getting a lot of team attention over the
next month. We need to re-read the mountain of requests that have
accumulated, and reach out again to you for fresh feedback. Improvements
will aim to be continuous and incremental.


Future plans, not scheduled yet:

-- Full wikitext toolbar -- We’re going to release v1 of a VisualEditor
toolbar in the next couple of weeks. This version will just have three
functions: Bold/Italics, Links and Mentions. (Mentions will have
autocomplete with user names that have already participated in the thread.)
We’ll definitely be doing more work on toolbars coming up, but we want to
see how this first one works before we make any solid plans.

-- Make the links to threads look nicer -- Yeah, this is annoying. It’s not
in our top five list of annoyances at the moment, but we’ll keep checking
off annoying items. Nicer links will get its turn. [5]

-- No-JS and accessibility -- We’ve done some work on this, and there will
be more coming up. [6]


So there's a lot of work still to be done, but we're adding a lot of
features. I hope this helps explain where we are in the process.

We’re going to have an Office Hours Google Hangout on Monday at 19:00 UTC,
so we can answer questions and talk about the project. If people are
interested, we can schedule more of these.

Thanks again for all the specific feature requests and concerns. We’ll be
requesting larger and wider quantities of feedback in the near future, as
some of the upcoming features are planned and built.

Danny


Phabricator tickets mentioned above:
[1] Flow post editing for autoconfirmed users:
https://phabricator.wikimedia.org/T90670
[2] Prototype for new indentation model:
https://phabricator.wikimedia.org/T88501
[3] Admins viewing deleted boards: https://phabricator.wikimedia.org/T90972
[4] Moving topics between boards: https://phabricator.wikimedia.org/T88140
[5] Less ugly topic page links: https://phabricator.wikimedia.org/T59154
[6] No-JS tracking: https://phabricator.wikimedia.org/T60019





On Tue, Mar 17, 2015 at 12:51 PM, Derk-Jan Hartman 
d.j.hartman+wmf...@gmail.com wrote:


  On 17 mrt. 2015, at 19:45, Isarra Yos zhoris...@gmail.com wrote:
 
  On 17/03/15 15:32, Brad Jorsch (Anomie) wrote:
  On Tue, Mar 17, 2015 at 11:17 AM, Marc A. Pelletier m...@uberbox.org
  wrote:
 
  Indentation is a crappy workaround for when your communication system
  does not support a sane threading model - it isn't a threading model or
  a substitute for one.
 
  Err, what's the threading model in Flow's UI? Or Facebook, phpbb, and so
  on, or whatever other site you were referring to that knitting
 grandmothers
  use? Can you really call not having any (user-visible) threading model a
  threading model?
 
  From what I've seen of those types of discussions, people have to either
  explicitly refer back to whatever they're replying to (e.g. Twitter
 tries
  to, and doesn't very well from what I've seen), quote whatever they're
  replying to (e.g. phpbb, email (especially how Gmail renders it)),
 and/or
  just deal with having to dig through an undifferentiated pile of
 replies to
  find the ones that might be replying to the post they're interested in
  (phpbb, Facebook).
 
  On a lot of sites they can also get away with a lack of threading
 because the discussions themselves are relatively inactive, where you don't
 have multiple people jumping in and replying to different points. Such
 inactivity isn't the case on many wikis, where discussion is more key to
 their functionality, and certainly shouldn't be an assumption here.
 

 I still think that a 

Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

2015-03-17 Thread John
Instead of dropping indents use something like {{od}}

On Tuesday, March 17, 2015, Danny Horn dh...@wikimedia.org wrote:

 (sorry for reposting, the first version had attachments and wasn't
 appearing in the archive)

 As a PS to that long post, here's another long post. I mentioned above that
 I'd get into more detail about indents and tangents.

 Wikitext talk pages use indentation for two different reasons -- to create
 visual separation between people's posts, and to create spin-off tangents
 that follow a different path than the main flow of conversation in a
 thread. They're both important functions, but they don't need the same
 mechanism, and I'd argue that trying to do both with indentations makes
 wikitext talk pages harder to participate in and understand.

 Big, complicated Village pump conversations need lots of room for tangents
 and subthreads. A simple back-and-forth conversation between two people
 doesn't need that. But we've spent years counting colons and fixing other
 people's indentations, to the point where it feels like a conversation can
 only be worthwhile if it's diagonal.

 The indentation model that we've been using on Flow is kind of an unhappy
 compromise between the two different functions, and I don't think anybody
 likes it much. It retains the idea that a reply should be indented just
 because, but then it only goes to two levels of indentation. Once a thread
 reaches the second indentation level, you can't create an out-of-synch
 tangent even if you want to.

 So we've figured out a new reply/indentation model that separates those two
 functions. We've been testing it out on the flow-tests server [1], and
 we're going to release it to Mediawiki soon.

 Here's how it works:

 If you're replying to the most recent post, then your reply just lines up
 under the previous message. A two-person back and forth conversation just
 looks flat, and the visual separation is noted with the user name and
 timestamp.

 If you're specifically replying to a previous post, then your reply creates
 an indented tangent. If everybody responding on that tangent replies to the
 last message in that subthread, then it'll stay at the same indentation
 level. But if someone replies to an older message within the subthread,
 then that creates a third indentation level. I think we've got it set to a
 maximum of 8 possible indentation levels, and we just stop it there because
 there's a point where you can't fit a lot of text in each line.

 The big idea of the new system is that the indentation should actually mean
 something. You should be able to tell the difference between a simple
 conversation and a complicated conversation at a glance, and using indented
 tangents helps you to spot the places in a conversation where there's a
 disagreement or a deeper level of detail.

 We've been running tests comparing the old and new indentation models with
 several groups, and I think it's promising. You can check out the two
 models here:

 -- New model: http://flow-tests.wmflabs.org/wiki/Talk:Something
 -- Old model (with 8 levels of indentation):
 http://ee-flow.wmflabs.org/wiki/Talk:SomethingElse

 So that is the Grand Unified Theory of Flow Indentation, in theory and
 practice. I would be happy to hear what you think about it. There is a very
 good chance that this model will continue the Flow tradition of pleasing
 exactly nobody, and if that's the case, then we can keep talking about it
 and making more changes. But there's also a chance that this is brilliant
 and solves everything, so I want to give it a shot and see what happens.




 On Tue, Mar 17, 2015 at 3:29 PM, Danny Horn dh...@wikimedia.org
 javascript:; wrote:

  Thanks for all of the questions and suggestions. Flow is still in active
  development, and there's a lot of feature work being done right now. Some
  of the features that have been mentioned in this thread are actually just
  about to be released, and some are coming up over the next month or so.
 
  Here's how it breaks down:
 
  Coming out very soon:
 
  -- The ability to edit other people's posts will be out on Mediawiki by
  the end of next week. We’ve made a few interface changes to support that.
  Posts that have been edited by someone that isn’t the original poster now
  say “Edited by Username 3 minutes ago”, so that it’s easy for everyone to
  see what’s happened. When someone edits an existing post, we fixed the
 diff
  pages so that you can browse between previous and next changes. [1]
 
  -- Sane threading model, with more levels for replies and tangents --
 also
  coming out next week. Talking about this feature gets super lengthy and
  complicated, so I’ll write another post right after this one that will
 give
  all the details for people who are interested. [2]
 
  -- Admins viewing deleted boards without undeleting it -- coming out in
  three weeks. [3]
 
 
  Working on these next:
 
  -- Moving topics between boards -- We’ve got designs and estimates for
  

Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

2015-03-17 Thread Helder .
On Tue, Mar 17, 2015 at 10:43 AM, Petr Bena benap...@gmail.com wrote:
 I think you all missed some old good rants. So here is one :) why the
 hell is the URL Topic:Sdoatsbslsafx6lw and not something easy to read
 and remember?
See https://phabricator.wikimedia.org/T59154.

On Tue, Mar 17, 2015 at 3:45 PM, Isarra Yos zhoris...@gmail.com wrote:
 On a lot of sites they can also get away with a lack of threading because
 the discussions themselves are relatively inactive, where you don't have
 multiple people jumping in and replying to different points. Such inactivity
 isn't the case on many wikis, where discussion is more key to their
 functionality, and certainly shouldn't be an assumption here.
Since the level of activity varies from wiki to wiki, a toggle to
change the view mode of the discussion (plain vs indented) would be welcome:
https://phabricator.wikimedia.org/T93024

Best regards,
Helder

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

2015-03-17 Thread Danny Horn
(sorry for reposting, the first version had attachments and wasn't
appearing in the archive)

As a PS to that long post, here's another long post. I mentioned above that
I'd get into more detail about indents and tangents.

Wikitext talk pages use indentation for two different reasons -- to create
visual separation between people's posts, and to create spin-off tangents
that follow a different path than the main flow of conversation in a
thread. They're both important functions, but they don't need the same
mechanism, and I'd argue that trying to do both with indentations makes
wikitext talk pages harder to participate in and understand.

Big, complicated Village pump conversations need lots of room for tangents
and subthreads. A simple back-and-forth conversation between two people
doesn't need that. But we've spent years counting colons and fixing other
people's indentations, to the point where it feels like a conversation can
only be worthwhile if it's diagonal.

The indentation model that we've been using on Flow is kind of an unhappy
compromise between the two different functions, and I don't think anybody
likes it much. It retains the idea that a reply should be indented just
because, but then it only goes to two levels of indentation. Once a thread
reaches the second indentation level, you can't create an out-of-synch
tangent even if you want to.

So we've figured out a new reply/indentation model that separates those two
functions. We've been testing it out on the flow-tests server [1], and
we're going to release it to Mediawiki soon.

Here's how it works:

If you're replying to the most recent post, then your reply just lines up
under the previous message. A two-person back and forth conversation just
looks flat, and the visual separation is noted with the user name and
timestamp.

If you're specifically replying to a previous post, then your reply creates
an indented tangent. If everybody responding on that tangent replies to the
last message in that subthread, then it'll stay at the same indentation
level. But if someone replies to an older message within the subthread,
then that creates a third indentation level. I think we've got it set to a
maximum of 8 possible indentation levels, and we just stop it there because
there's a point where you can't fit a lot of text in each line.

The big idea of the new system is that the indentation should actually mean
something. You should be able to tell the difference between a simple
conversation and a complicated conversation at a glance, and using indented
tangents helps you to spot the places in a conversation where there's a
disagreement or a deeper level of detail.

We've been running tests comparing the old and new indentation models with
several groups, and I think it's promising. You can check out the two
models here:

-- New model: http://flow-tests.wmflabs.org/wiki/Talk:Something
-- Old model (with 8 levels of indentation):
http://ee-flow.wmflabs.org/wiki/Talk:SomethingElse

So that is the Grand Unified Theory of Flow Indentation, in theory and
practice. I would be happy to hear what you think about it. There is a very
good chance that this model will continue the Flow tradition of pleasing
exactly nobody, and if that's the case, then we can keep talking about it
and making more changes. But there's also a chance that this is brilliant
and solves everything, so I want to give it a shot and see what happens.




On Tue, Mar 17, 2015 at 3:29 PM, Danny Horn dh...@wikimedia.org wrote:

 Thanks for all of the questions and suggestions. Flow is still in active
 development, and there's a lot of feature work being done right now. Some
 of the features that have been mentioned in this thread are actually just
 about to be released, and some are coming up over the next month or so.

 Here's how it breaks down:

 Coming out very soon:

 -- The ability to edit other people's posts will be out on Mediawiki by
 the end of next week. We’ve made a few interface changes to support that.
 Posts that have been edited by someone that isn’t the original poster now
 say “Edited by Username 3 minutes ago”, so that it’s easy for everyone to
 see what’s happened. When someone edits an existing post, we fixed the diff
 pages so that you can browse between previous and next changes. [1]

 -- Sane threading model, with more levels for replies and tangents -- also
 coming out next week. Talking about this feature gets super lengthy and
 complicated, so I’ll write another post right after this one that will give
 all the details for people who are interested. [2]

 -- Admins viewing deleted boards without undeleting it -- coming out in
 three weeks. [3]


 Working on these next:

 -- Moving topics between boards -- We’ve got designs and estimates for
 this, and I’m expecting that to come out in April. [4]

 -- More powerful watchlist/notification functionality -- This is a very
 important feature that will be getting a lot of team attention over the
 next month. We need 

Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

2015-03-17 Thread Derk-Jan Hartman

 On 17 mrt. 2015, at 19:45, Isarra Yos zhoris...@gmail.com wrote:
 
 On 17/03/15 15:32, Brad Jorsch (Anomie) wrote:
 On Tue, Mar 17, 2015 at 11:17 AM, Marc A. Pelletier m...@uberbox.org
 wrote:
 
 Indentation is a crappy workaround for when your communication system
 does not support a sane threading model - it isn't a threading model or
 a substitute for one.
 
 Err, what's the threading model in Flow's UI? Or Facebook, phpbb, and so
 on, or whatever other site you were referring to that knitting grandmothers
 use? Can you really call not having any (user-visible) threading model a
 threading model?
 
 From what I've seen of those types of discussions, people have to either
 explicitly refer back to whatever they're replying to (e.g. Twitter tries
 to, and doesn't very well from what I've seen), quote whatever they're
 replying to (e.g. phpbb, email (especially how Gmail renders it)), and/or
 just deal with having to dig through an undifferentiated pile of replies to
 find the ones that might be replying to the post they're interested in
 (phpbb, Facebook).
 
 On a lot of sites they can also get away with a lack of threading because the 
 discussions themselves are relatively inactive, where you don't have multiple 
 people jumping in and replying to different points. Such inactivity isn't the 
 case on many wikis, where discussion is more key to their functionality, and 
 certainly shouldn't be an assumption here.
 

I still think that a threading and collapsing model as in 
http://tweakers.net/nieuws/101962/google-maakt-leeftijdsrating-verplicht-voor-android-apps.html#reacties
 
http://tweakers.net/nieuws/101962/google-maakt-leeftijdsrating-verplicht-voor-android-apps.html#reacties
 makes a lot more sense.

It’s limited in width, readable, collapsible, has threading with indenting, has 
a maximum amount of indenting, and is a tech website that is also very 
intensive, and all over the place.

DJ


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

2015-03-17 Thread Isarra Yos

On 17/03/15 15:32, Brad Jorsch (Anomie) wrote:

On Tue, Mar 17, 2015 at 11:17 AM, Marc A. Pelletier m...@uberbox.org
wrote:


Indentation is a crappy workaround for when your communication system
does not support a sane threading model - it isn't a threading model or
a substitute for one.


Err, what's the threading model in Flow's UI? Or Facebook, phpbb, and so
on, or whatever other site you were referring to that knitting grandmothers
use? Can you really call not having any (user-visible) threading model a
threading model?

 From what I've seen of those types of discussions, people have to either
explicitly refer back to whatever they're replying to (e.g. Twitter tries
to, and doesn't very well from what I've seen), quote whatever they're
replying to (e.g. phpbb, email (especially how Gmail renders it)), and/or
just deal with having to dig through an undifferentiated pile of replies to
find the ones that might be replying to the post they're interested in
(phpbb, Facebook).


On a lot of sites they can also get away with a lack of threading 
because the discussions themselves are relatively inactive, where you 
don't have multiple people jumping in and replying to different points. 
Such inactivity isn't the case on many wikis, where discussion is more 
key to their functionality, and certainly shouldn't be an assumption here.


- I


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

2015-03-17 Thread Petr Bena
Ok, here I copy my message

Petrb (talkcontribsblock)

Hi,

I think you all missed some old good rants. So here is one :) why the
hell is the URL Topic:Sdoatsbslsafx6lw and not something easy to read
and remember?


On Tue, Mar 17, 2015 at 2:42 PM, Brad Jorsch (Anomie)
bjor...@wikimedia.org wrote:
 On Mon, Mar 16, 2015 at 8:51 PM, Nick Wilson (Quiddity) 
 nwil...@wikimedia.org wrote:

 We’d like to hear which features you use on the current LQT boards,
 and that you’re concerned about losing in the Flow conversion.


 Working watchlist functionality, see
 https://phabricator.wikimedia.org/T76862 and
 https://phabricator.wikimedia.org/T68876. Yes, LQT's inventing of their own
 pseudo-watchlist rather sucks, but at least it functions correctly.

 Please give us feedback at
 https://www.mediawiki.org/wiki/Topic:Sdoatsbslsafx6lw to keep it
 centralized, and test freely at the sandbox.[6]


 No thanks, I prefer this mailing list thread. Feel free to copy this there
 if you want, but please reply here too
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

2015-03-17 Thread Brad Jorsch (Anomie)
On Mon, Mar 16, 2015 at 8:51 PM, Nick Wilson (Quiddity) 
nwil...@wikimedia.org wrote:

 We’d like to hear which features you use on the current LQT boards,
 and that you’re concerned about losing in the Flow conversion.


Working watchlist functionality, see
https://phabricator.wikimedia.org/T76862 and
https://phabricator.wikimedia.org/T68876. Yes, LQT's inventing of their own
pseudo-watchlist rather sucks, but at least it functions correctly.

Please give us feedback at
 https://www.mediawiki.org/wiki/Topic:Sdoatsbslsafx6lw to keep it
 centralized, and test freely at the sandbox.[6]


No thanks, I prefer this mailing list thread. Feel free to copy this there
if you want, but please reply here too
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

2015-03-17 Thread Max Semenik
On Tue, Mar 17, 2015 at 3:05 AM, Ricordisamoa ricordisa...@openmailbox.org
wrote:

  * An arbitrary indentation level *must* be allowed, with optional
facilitations for adding an {{outdent}}-like marker


Why? Manual indentation just leads to you having to decode these levels
sometimes. Soulless machines are better at indenting consistently than us
meatbags. Also, my personal opinion is that indenting is just silly and
needs to die, not accumulate more cruft.


  * Every basic functionality (including but not limited to the
preview button) *must* work without relying on JavaScript (T60019
https://phabricator.wikimedia.org/T60019)


Surprise! It's 2015, and web doesn't quite work without JS. Some basics
still need to work without it, but very basics.

-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

2015-03-17 Thread Ricordisamoa

Il 17/03/2015 14:05, Max Semenik ha scritto:

On Tue, Mar 17, 2015 at 3:05 AM, Ricordisamoa ricordisa...@openmailbox.org
wrote:


  * An arbitrary indentation level *must* be allowed, with optional
facilitations for adding an {{outdent}}-like marker


Why? Manual indentation just leads to you having to decode these levels
sometimes. Soulless machines are better at indenting consistently than us
meatbags. Also, my personal opinion is that indenting is just silly and
needs to die, not accumulate more cruft.


Software cannot understand which post a message replies to.
In case a sensible way of reducing clutter in the interface without 
limiting indenting options can be found, I'll favor it.






  * Every basic functionality (including but not limited to the
preview button) *must* work without relying on JavaScript (T60019
https://phabricator.wikimedia.org/T60019)


Surprise! It's 2015, and web doesn't quite work without JS. Some basics
still need to work without it, but very basics.



I have always been proud of contributing to projects that value 
accessibility more than fancy animations.

Flow is a regression in regard to this.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

2015-03-17 Thread Ricordisamoa

Il 17/03/2015 14:34, Brad Jorsch (Anomie) ha scritto:

On Tue, Mar 17, 2015 at 9:05 AM, Max Semenik maxsem.w...@gmail.com wrote:


On Tue, Mar 17, 2015 at 3:05 AM, Ricordisamoa 
ricordisa...@openmailbox.org
wrote:


  * An arbitrary indentation level *must* be allowed, with optional
facilitations for adding an {{outdent}}-like marker


Why? Manual indentation just leads to you having to decode these levels
sometimes. Soulless machines are better at indenting consistently than us
meatbags. Also, my personal opinion is that indenting is just silly and
needs to die, not accumulate more cruft.


I suspect this is referring to the misfeature where (in the current
configuration) it just stops indenting entirely after two levels, making it
impossible to follow the reply structure if it's not trivially simple.


Exactly.





  * Every basic functionality (including but not limited to the
preview button) *must* work without relying on JavaScript (T60019
https://phabricator.wikimedia.org/T60019)


Surprise! It's 2015, and web doesn't quite work without JS. Some basics
still need to work without it, but very basics.


Just because too many websites allow themselves to be broken without
JavaScript doesn't mean we should too. If you want you could try to debate
that preview isn't basic functionality, but a dismissal like this is
simply uncalled for.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l



___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

2015-03-17 Thread Brad Jorsch (Anomie)
On Tue, Mar 17, 2015 at 9:37 AM, Ricordisamoa ricordisa...@openmailbox.org
wrote:

Software cannot understand which post a message replies to.


It can, and more easily than with raw wikitext, as long as the correct
reply button is used, i.e. if people actually click reply instead of
using the already-there box for creating a new top-level post in the
topic.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

2015-03-17 Thread Ricordisamoa

Il 17/03/2015 14:45, Brad Jorsch (Anomie) ha scritto:

On Tue, Mar 17, 2015 at 9:37 AM, Ricordisamoa ricordisa...@openmailbox.org
wrote:

Software cannot understand which post a message replies to.
It can, and more easily than with raw wikitext, as long as the correct
reply button is used, i.e. if people actually click reply instead of
using the already-there box for creating a new top-level post in the
topic.

Of course. I was referring to an hypothetical single reply button.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

2015-03-17 Thread florian.schmidt.wel...@t-online.de
 No thanks, I prefer this mailing list thread

Hmm, but there are other people who use LQT all over the day and are very 
active in contributing (at least on Project:Support_desk), so they would have 
the chance to discuss with us there, if they aren't subscribers of this list 
(and don't want to be one). :)

Best,
Florian

Freundliche Grüße
Florian Schmidt
-Original-Nachricht-
Betreff: Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at 
mediawiki.org
Datum: Tue, 17 Mar 2015 14:43:17 +0100
Von: Brad Jorsch (Anomie) bjor...@wikimedia.org
An: Wikimedia developers wikitech-l@lists.wikimedia.org

On Mon, Mar 16, 2015 at 8:51 PM, Nick Wilson (Quiddity) 
nwil...@wikimedia.org wrote:

 We’d like to hear which features you use on the current LQT boards,
 and that you’re concerned about losing in the Flow conversion.


Working watchlist functionality, see
https://phabricator.wikimedia.org/T76862 and
https://phabricator.wikimedia.org/T68876. Yes, LQT's inventing of their own
pseudo-watchlist rather sucks, but at least it functions correctly.

Please give us feedback at
 https://www.mediawiki.org/wiki/Topic:Sdoatsbslsafx6lw to keep it
 centralized, and test freely at the sandbox.[6]


No thanks, I prefer this mailing list thread. Feel free to copy this there
if you want, but please reply here too
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l



___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

2015-03-17 Thread pi zero
For my perspective (sorry if this is covered somewhere I've missed), who
made the decision to do this conversion?  One of my reasons for interest is
that at en.wn we have LQT and *do not want* Flow.  (A fairly good summary
of the sense of the en.wn community is (1) we would rather LQT than Flow
for our comments pages, (2) our comments pages, which are meant to hold up
well when edited by people who are utterly clueless about wiki markup, are
better off with LQT than as ordinary wiki pages, and (3) we mostly detest
LQT and want straight wiki markup for all pages that are part of our
project's primary function.)

On Mon, Mar 16, 2015 at 8:51 PM, Nick Wilson (Quiddity) 
nwil...@wikimedia.org wrote:

 LiquidThreads (LQT) has not been well-supported in a long time. Flow
 is in active development, and more real-world use-cases will help
 focus attention on the higher-priority features that are needed. To
 that end, LQT pages at mediawiki.org will start being converted to
 Flow in the next couple of weeks.

 There are about 1,600 existing LQT pages on Mediawiki, and the three
 most active pages are VisualEditor/Feedback, Project:Support_desk, and
 Help_talk:CirrusSearch.[1] The Collaboration team has been running
 test conversions of those three pages, and fixing issues that have
 come up. Those fixes are almost complete, and the team will be ready
 to start converting LQT threads to Flow topics soon. (If you’re
 interested in the progress, check out phab:T90788[2] and linked
 tasks.) The latest set is visible at a labs test server.[3] See an
 example topic comparison here: Flow vs LQT.[4])

 The VisualEditor/Feedback page will be converted first (per James'
 request), around the middle of next week. We’ll pause to assess any
 high-priority changes required. After that, we will start converting
 more pages. This process may take a couple of weeks to fully run.

 The last page to be converted will be Project:Support_desk, as that is
 the largest and most active LQT Board.

 LQT Threads that are currently on your watchlist, will still be
 watchlisted as Flow Topics. New Topics created at Flow Boards on your
 watchlist will appear in your Echo notifications, and you can choose
 whether or not to watchlist them.

 The LQT namespaces will continue to exist. Links to posts/topics will
 redirect appropriately, and the LQT history will remain available at
 the original location, as well as being mirrored in the Flow history.

 There’s a queue of new features in Flow that will be shipped over the
 next month or so:

 * Table of Contents is done
 * Category support for Flow Header and Topics is done
 * VE with editing toolbar coming last week of March (phab:T90763) [5]
 * Editing other people’s comments coming last week of March (phab:T91086)
 * Ability to change the width  side rail in progress, probably out in
 April (phab:T88114])
 * Search is in progress (no ETA yet) (phab:T76823)
 * The ability to choose which Flow notifications end up in Echo,
 watchlist, or both, and other more powerful options, will be coming up
 next (no ETA yet)

 That being said -- there are some LiquidThreads features that don’t
 exist in Flow yet.
 We’d like to hear which features you use on the current LQT boards,
 and that you’re concerned about losing in the Flow conversion. At the
 same time, we’d like further suggestions on how we could improve upon
 that (or other) features from LQT.

 Please give us feedback at
 https://www.mediawiki.org/wiki/Topic:Sdoatsbslsafx6lw to keep it
 centralized, and test freely at the sandbox.[6]

 Much thanks, on behalf of the Collaboration Team,
 Quiddity (WMF)

 [1] https://www.mediawiki.org/wiki/VisualEditor/Feedback and
 https://www.mediawiki.org/wiki/Help_talk:CirrusSearch and
 https://www.mediawiki.org/wiki/Project:Support_desk
 [2] https://phabricator.wikimedia.org/T90788
 [3] http://flow-tests.wmflabs.org/wiki/Testwiki:Support_desk and
 http://flow-tests.wmflabs.org/wiki/VisualEditor/Feedback
 [4] http://flow-tests.wmflabs.org/wiki/Topic:Qmkwqmp0wfcazy9c and

 https://www.mediawiki.org/wiki/Thread:Project:Support_desk/Error_creating_thumbnail:_Unable_to_save_thumbnail_to_destination
 [5] https://phabricator.wikimedia.org/T90763 ,
 https://phabricator.wikimedia.org/T91086 ,
 https://phabricator.wikimedia.org/T88114 ,
 https://phabricator.wikimedia.org/T76823
 [6] https://www.mediawiki.org/wiki/Talk:Sandbox


 --
 Nick Wilson (Quiddity)
 Community Liaison
 Wikimedia Foundation

 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

2015-03-17 Thread Brad Jorsch (Anomie)
On Tue, Mar 17, 2015 at 9:05 AM, Max Semenik maxsem.w...@gmail.com wrote:

 On Tue, Mar 17, 2015 at 3:05 AM, Ricordisamoa 
 ricordisa...@openmailbox.org
 wrote:

   * An arbitrary indentation level *must* be allowed, with optional
 facilitations for adding an {{outdent}}-like marker
 

 Why? Manual indentation just leads to you having to decode these levels
 sometimes. Soulless machines are better at indenting consistently than us
 meatbags. Also, my personal opinion is that indenting is just silly and
 needs to die, not accumulate more cruft.


I suspect this is referring to the misfeature where (in the current
configuration) it just stops indenting entirely after two levels, making it
impossible to follow the reply structure if it's not trivially simple.


   * Every basic functionality (including but not limited to the
 preview button) *must* work without relying on JavaScript (T60019
 https://phabricator.wikimedia.org/T60019)


 Surprise! It's 2015, and web doesn't quite work without JS. Some basics
 still need to work without it, but very basics.


Just because too many websites allow themselves to be broken without
JavaScript doesn't mean we should too. If you want you could try to debate
that preview isn't basic functionality, but a dismissal like this is
simply uncalled for.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

2015-03-17 Thread Risker
On 17 March 2015 at 09:45, Brad Jorsch (Anomie) bjor...@wikimedia.org
wrote:

 On Tue, Mar 17, 2015 at 9:37 AM, Ricordisamoa 
 ricordisa...@openmailbox.org
 wrote:

 Software cannot understand which post a message replies to.
 

 It can, and more easily than with raw wikitext, as long as the correct
 reply button is used, i.e. if people actually click reply instead of
 using the already-there box for creating a new top-level post in the
 topic.



The software can tell, but visually it is nearly impossible to determine
which message is being responded to when everything has essentially the
same indent level.

There's also the huge waste of screen real estate - I knew it was bad on
desktop, but I was surprised to see it looks almost as bad on a tablet when
I had an opportunity to take a look.

Risker/Anne
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

2015-03-17 Thread Risker
On 17 March 2015 at 10:49, Brad Jorsch (Anomie) bjor...@wikimedia.org
wrote:

 On Tue, Mar 17, 2015 at 10:35 AM, Risker risker...@gmail.com wrote:

  On 17 March 2015 at 09:45, Brad Jorsch (Anomie) bjor...@wikimedia.org
  wrote:
 
   On Tue, Mar 17, 2015 at 9:37 AM, Ricordisamoa 
   ricordisa...@openmailbox.org
   wrote:
  
   Software cannot understand which post a message replies to.
   
  
   It can, and more easily than with raw wikitext, as long as the correct
   reply button is used, i.e. if people actually click reply instead of
   using the already-there box for creating a new top-level post in the
   topic.
  
  
 
  The software can tell, but visually it is nearly impossible to determine
  which message is being responded to when everything has essentially the
  same indent level.
 

 Granted, but that's because the output format is poor rather than the
 software being unable to tell.



Thank you, Brad.  Is the output format not determined by the parameters in
the software?

It just strikes me as weird that the software that we keep being told will
improve communication and collaboration is deliberately designed in such a
way that it is difficult for the human users (as opposed to the software)
to be able to immediately discern who is responding to whom.

Risker/Anne
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

2015-03-17 Thread Brad Jorsch (Anomie)
On Tue, Mar 17, 2015 at 10:35 AM, Risker risker...@gmail.com wrote:

 On 17 March 2015 at 09:45, Brad Jorsch (Anomie) bjor...@wikimedia.org
 wrote:

  On Tue, Mar 17, 2015 at 9:37 AM, Ricordisamoa 
  ricordisa...@openmailbox.org
  wrote:
 
  Software cannot understand which post a message replies to.
  
 
  It can, and more easily than with raw wikitext, as long as the correct
  reply button is used, i.e. if people actually click reply instead of
  using the already-there box for creating a new top-level post in the
  topic.
 
 

 The software can tell, but visually it is nearly impossible to determine
 which message is being responded to when everything has essentially the
 same indent level.


Granted, but that's because the output format is poor rather than the
software being unable to tell.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

2015-03-17 Thread Kevin Wayne Williams

Erik Moeller schreef op 2015/03/17 om 1:39:

On Mon, Mar 16, 2015 at 11:21 PM, Kevin Wayne Williams
kwwilli...@kwwilliams.com wrote:

There doesn't seem to be any particular user demand to adopt Flow,
so there's no reason to believe it will gain any more traction than LQT ever 
did.


There was significant community interest and momentum behind LQT
including various votes to enable it [1], and there is significant
interest in Flow now [2]. The main thing that prevented LQT from wider
adoption was not lack of community interest, it was our decision to
put the project on hold due to both major architectural concerns and
resource constraints at the time. We've committed to providing an
upgrade path, and this is our follow-through to that commitment.


[snip]


As for inconsistency and fragmentation of mediawiki.org, if anything,
the conversion of LQT pages on mediawiki.org will create greater
consistency as we're already using Flow on Beta Features talk pages (
https://www.mediawiki.org/wiki/Talk:Content_translation is a nice
example of a feedback page with lots of continuous and substantive
comments from experienced users).



I'm not arguing that nuking LQT isn't a good idea: that most certainly 
is. What I object to is this apparent intent to create two tiers of 
users: one tier that knows how to use the software and another tier that 
gets accustomed to a partially functional easy layer that provides no 
experience or training in how to maintain the actual project content, 
with no apparent bridge between the two. Between VE and LQT, newbies get 
provided with no experience in handling the easy cases of editing until 
they hit something that the simple tools can't handle, at which time 
they are suddenly faced with a wall of text that they have no experience 
in dissecting, parsing, and understanding and are expected to make a 
change in one of the hard parts. Much better to get them gradually 
accustomed to wikitext by performing small tasks than to just toss them 
in the deep end after their crutches break. Yes, there are at least five 
mixed metaphors in that last sentence, buy you get the drift.


KWW


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

2015-03-16 Thread Nick Wilson (Quiddity)
On Mon, Mar 16, 2015 at 6:02 PM, Risker risker...@gmail.com wrote:
 How about just converting those threads back to Wikitext, instead?  That
 script already exists, I've seen it used on Mediawiki. Will it mess up the
 pages that have already been converted using that script?

 Bottom line, it makes no sense to replace software that was considered
 barely suitable when it was first developed with new software that can't
 even do what that old, long-neglected software could do...and in several
 cases, there is no intention to ever add the features already available
 using Wikitext.

 As expectations increase for project users to post their
 comments/concerns/ideas/observations on Mediawiki, the use of Flow will
 become a barrier for participation.

 Risker/Anne


Converting LQT to Wikitext would lose the major benefits of:
* per-Topic watchlisting,
* per-Topic category support,
* Sortable views (with Filterable views on the roadmap [1]),
as well as the immensely easier process for new-editors to be able to
participate in discussions, and be notified about replies.[2]

[1] See Pau's design notes at
https://docs.google.com/presentation/d/1DQabV3mjE9ReV9zs1qAi8u_A5560QEVX4aK95pc0Whs/edit#slide=id.p
and Hhhippo's ideas/notes at
https://en.wikipedia.org/wiki/User:Hhhippo/Flow/TOC_and_filters
[2] The feedback from the ongoing trial at the Frwiki newcomers'
helpdesk, is that the Flow version has better engagement, with more
editors returning to give further information, or ask a followup
question, or just to say thanks.
https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Forum_des_nouveaux/Flow
https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Forum_des_nouveaux

Flow has been improving over the months. I hope you'll give it a try
at the sandbox, check out the list of upcoming features (in 1st
message), and let the
team know what feature(s) you're most concerned about. The more
specific the feedback, the more it will help influence the order new
features are developed in.

Thanks, as always :)
Quiddity (WMF)

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

2015-03-16 Thread Nick Wilson (Quiddity)
LiquidThreads (LQT) has not been well-supported in a long time. Flow
is in active development, and more real-world use-cases will help
focus attention on the higher-priority features that are needed. To
that end, LQT pages at mediawiki.org will start being converted to
Flow in the next couple of weeks.

There are about 1,600 existing LQT pages on Mediawiki, and the three
most active pages are VisualEditor/Feedback, Project:Support_desk, and
Help_talk:CirrusSearch.[1] The Collaboration team has been running
test conversions of those three pages, and fixing issues that have
come up. Those fixes are almost complete, and the team will be ready
to start converting LQT threads to Flow topics soon. (If you’re
interested in the progress, check out phab:T90788[2] and linked
tasks.) The latest set is visible at a labs test server.[3] See an
example topic comparison here: Flow vs LQT.[4])

The VisualEditor/Feedback page will be converted first (per James'
request), around the middle of next week. We’ll pause to assess any
high-priority changes required. After that, we will start converting
more pages. This process may take a couple of weeks to fully run.

The last page to be converted will be Project:Support_desk, as that is
the largest and most active LQT Board.

LQT Threads that are currently on your watchlist, will still be
watchlisted as Flow Topics. New Topics created at Flow Boards on your
watchlist will appear in your Echo notifications, and you can choose
whether or not to watchlist them.

The LQT namespaces will continue to exist. Links to posts/topics will
redirect appropriately, and the LQT history will remain available at
the original location, as well as being mirrored in the Flow history.

There’s a queue of new features in Flow that will be shipped over the
next month or so:

* Table of Contents is done
* Category support for Flow Header and Topics is done
* VE with editing toolbar coming last week of March (phab:T90763) [5]
* Editing other people’s comments coming last week of March (phab:T91086)
* Ability to change the width  side rail in progress, probably out in
April (phab:T88114])
* Search is in progress (no ETA yet) (phab:T76823)
* The ability to choose which Flow notifications end up in Echo,
watchlist, or both, and other more powerful options, will be coming up
next (no ETA yet)

That being said -- there are some LiquidThreads features that don’t
exist in Flow yet.
We’d like to hear which features you use on the current LQT boards,
and that you’re concerned about losing in the Flow conversion. At the
same time, we’d like further suggestions on how we could improve upon
that (or other) features from LQT.

Please give us feedback at
https://www.mediawiki.org/wiki/Topic:Sdoatsbslsafx6lw to keep it
centralized, and test freely at the sandbox.[6]

Much thanks, on behalf of the Collaboration Team,
Quiddity (WMF)

[1] https://www.mediawiki.org/wiki/VisualEditor/Feedback and
https://www.mediawiki.org/wiki/Help_talk:CirrusSearch and
https://www.mediawiki.org/wiki/Project:Support_desk
[2] https://phabricator.wikimedia.org/T90788
[3] http://flow-tests.wmflabs.org/wiki/Testwiki:Support_desk and
http://flow-tests.wmflabs.org/wiki/VisualEditor/Feedback
[4] http://flow-tests.wmflabs.org/wiki/Topic:Qmkwqmp0wfcazy9c and
https://www.mediawiki.org/wiki/Thread:Project:Support_desk/Error_creating_thumbnail:_Unable_to_save_thumbnail_to_destination
[5] https://phabricator.wikimedia.org/T90763 ,
https://phabricator.wikimedia.org/T91086 ,
https://phabricator.wikimedia.org/T88114 ,
https://phabricator.wikimedia.org/T76823
[6] https://www.mediawiki.org/wiki/Talk:Sandbox


-- 
Nick Wilson (Quiddity)
Community Liaison
Wikimedia Foundation

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

2015-03-16 Thread Risker
On 16 March 2015 at 21:20, Ryan Lane rlan...@gmail.com wrote:

 On Mon, Mar 16, 2015 at 6:02 PM, Risker risker...@gmail.com wrote:

  How about just converting those threads back to Wikitext, instead?  That
  script already exists, I've seen it used on Mediawiki. Will it mess up
 the
  pages that have already been converted using that script?
 
  Bottom line, it makes no sense to replace software that was considered
  barely suitable when it was first developed with new software that
 can't
  even do what that old, long-neglected software could do...and in several
  cases, there is no intention to ever add the features already available
  using Wikitext.
 
  As expectations increase for project users to post their
  comments/concerns/ideas/observations on Mediawiki, the use of Flow will
  become a barrier for participation.
 
 
 As someone who used LQT a lot, I'd say I'd much rather flow replace the
 pages I maintained using LQT. Maybe you dislike flow, but it's *way* more
 useful than wikitext for discussion. I never want to go back to the days
 where I needed to discuss things with wikitext ever again. Wikitext
 discussion pages are just the absolute worst.



I hear what you are saying, Ryan.  I'm also reflecting on the fact that as
there is increasing pressure on ordinary editors to post their
discussions about Mediawiki on the Mediawikiwiki, they would then
encountering *another* new interface that doesn't operate in anything
similar to what they've experienced before, and that we know isn't up to
handling stuff that even LQT handled without blinking.  On the other hand,
based on what I'm hearing about the success of  installing Flow on
Office-wiki, the end result may very well be fewer people coming to
complain about something else, which might be viewed as a net positive.

Risker/Anne
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

2015-03-16 Thread Risker
How about just converting those threads back to Wikitext, instead?  That
script already exists, I've seen it used on Mediawiki. Will it mess up the
pages that have already been converted using that script?

Bottom line, it makes no sense to replace software that was considered
barely suitable when it was first developed with new software that can't
even do what that old, long-neglected software could do...and in several
cases, there is no intention to ever add the features already available
using Wikitext.

As expectations increase for project users to post their
comments/concerns/ideas/observations on Mediawiki, the use of Flow will
become a barrier for participation.

Risker/Anne


On 16 March 2015 at 20:51, Nick Wilson (Quiddity) nwil...@wikimedia.org
wrote:

 LiquidThreads (LQT) has not been well-supported in a long time. Flow
 is in active development, and more real-world use-cases will help
 focus attention on the higher-priority features that are needed. To
 that end, LQT pages at mediawiki.org will start being converted to
 Flow in the next couple of weeks.

 There are about 1,600 existing LQT pages on Mediawiki, and the three
 most active pages are VisualEditor/Feedback, Project:Support_desk, and
 Help_talk:CirrusSearch.[1] The Collaboration team has been running
 test conversions of those three pages, and fixing issues that have
 come up. Those fixes are almost complete, and the team will be ready
 to start converting LQT threads to Flow topics soon. (If you’re
 interested in the progress, check out phab:T90788[2] and linked
 tasks.) The latest set is visible at a labs test server.[3] See an
 example topic comparison here: Flow vs LQT.[4])

 The VisualEditor/Feedback page will be converted first (per James'
 request), around the middle of next week. We’ll pause to assess any
 high-priority changes required. After that, we will start converting
 more pages. This process may take a couple of weeks to fully run.

 The last page to be converted will be Project:Support_desk, as that is
 the largest and most active LQT Board.

 LQT Threads that are currently on your watchlist, will still be
 watchlisted as Flow Topics. New Topics created at Flow Boards on your
 watchlist will appear in your Echo notifications, and you can choose
 whether or not to watchlist them.

 The LQT namespaces will continue to exist. Links to posts/topics will
 redirect appropriately, and the LQT history will remain available at
 the original location, as well as being mirrored in the Flow history.

 There’s a queue of new features in Flow that will be shipped over the
 next month or so:

 * Table of Contents is done
 * Category support for Flow Header and Topics is done
 * VE with editing toolbar coming last week of March (phab:T90763) [5]
 * Editing other people’s comments coming last week of March (phab:T91086)
 * Ability to change the width  side rail in progress, probably out in
 April (phab:T88114])
 * Search is in progress (no ETA yet) (phab:T76823)
 * The ability to choose which Flow notifications end up in Echo,
 watchlist, or both, and other more powerful options, will be coming up
 next (no ETA yet)

 That being said -- there are some LiquidThreads features that don’t
 exist in Flow yet.
 We’d like to hear which features you use on the current LQT boards,
 and that you’re concerned about losing in the Flow conversion. At the
 same time, we’d like further suggestions on how we could improve upon
 that (or other) features from LQT.

 Please give us feedback at
 https://www.mediawiki.org/wiki/Topic:Sdoatsbslsafx6lw to keep it
 centralized, and test freely at the sandbox.[6]

 Much thanks, on behalf of the Collaboration Team,
 Quiddity (WMF)

 [1] https://www.mediawiki.org/wiki/VisualEditor/Feedback and
 https://www.mediawiki.org/wiki/Help_talk:CirrusSearch and
 https://www.mediawiki.org/wiki/Project:Support_desk
 [2] https://phabricator.wikimedia.org/T90788
 [3] http://flow-tests.wmflabs.org/wiki/Testwiki:Support_desk and
 http://flow-tests.wmflabs.org/wiki/VisualEditor/Feedback
 [4] http://flow-tests.wmflabs.org/wiki/Topic:Qmkwqmp0wfcazy9c and

 https://www.mediawiki.org/wiki/Thread:Project:Support_desk/Error_creating_thumbnail:_Unable_to_save_thumbnail_to_destination
 [5] https://phabricator.wikimedia.org/T90763 ,
 https://phabricator.wikimedia.org/T91086 ,
 https://phabricator.wikimedia.org/T88114 ,
 https://phabricator.wikimedia.org/T76823
 [6] https://www.mediawiki.org/wiki/Talk:Sandbox


 --
 Nick Wilson (Quiddity)
 Community Liaison
 Wikimedia Foundation

 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

2015-03-16 Thread Jon Robson
Fiayy!
So happy to hear this is happening :)
 On 16 Mar 2015 17:52, Nick Wilson (Quiddity) nwil...@wikimedia.org
wrote:

 LiquidThreads (LQT) has not been well-supported in a long time. Flow
 is in active development, and more real-world use-cases will help
 focus attention on the higher-priority features that are needed. To
 that end, LQT pages at mediawiki.org will start being converted to
 Flow in the next couple of weeks.

 There are about 1,600 existing LQT pages on Mediawiki, and the three
 most active pages are VisualEditor/Feedback, Project:Support_desk, and
 Help_talk:CirrusSearch.[1] The Collaboration team has been running
 test conversions of those three pages, and fixing issues that have
 come up. Those fixes are almost complete, and the team will be ready
 to start converting LQT threads to Flow topics soon. (If you’re
 interested in the progress, check out phab:T90788[2] and linked
 tasks.) The latest set is visible at a labs test server.[3] See an
 example topic comparison here: Flow vs LQT.[4])

 The VisualEditor/Feedback page will be converted first (per James'
 request), around the middle of next week. We’ll pause to assess any
 high-priority changes required. After that, we will start converting
 more pages. This process may take a couple of weeks to fully run.

 The last page to be converted will be Project:Support_desk, as that is
 the largest and most active LQT Board.

 LQT Threads that are currently on your watchlist, will still be
 watchlisted as Flow Topics. New Topics created at Flow Boards on your
 watchlist will appear in your Echo notifications, and you can choose
 whether or not to watchlist them.

 The LQT namespaces will continue to exist. Links to posts/topics will
 redirect appropriately, and the LQT history will remain available at
 the original location, as well as being mirrored in the Flow history.

 There’s a queue of new features in Flow that will be shipped over the
 next month or so:

 * Table of Contents is done
 * Category support for Flow Header and Topics is done
 * VE with editing toolbar coming last week of March (phab:T90763) [5]
 * Editing other people’s comments coming last week of March (phab:T91086)
 * Ability to change the width  side rail in progress, probably out in
 April (phab:T88114])
 * Search is in progress (no ETA yet) (phab:T76823)
 * The ability to choose which Flow notifications end up in Echo,
 watchlist, or both, and other more powerful options, will be coming up
 next (no ETA yet)

 That being said -- there are some LiquidThreads features that don’t
 exist in Flow yet.
 We’d like to hear which features you use on the current LQT boards,
 and that you’re concerned about losing in the Flow conversion. At the
 same time, we’d like further suggestions on how we could improve upon
 that (or other) features from LQT.

 Please give us feedback at
 https://www.mediawiki.org/wiki/Topic:Sdoatsbslsafx6lw to keep it
 centralized, and test freely at the sandbox.[6]

 Much thanks, on behalf of the Collaboration Team,
 Quiddity (WMF)

 [1] https://www.mediawiki.org/wiki/VisualEditor/Feedback and
 https://www.mediawiki.org/wiki/Help_talk:CirrusSearch and
 https://www.mediawiki.org/wiki/Project:Support_desk
 [2] https://phabricator.wikimedia.org/T90788
 [3] http://flow-tests.wmflabs.org/wiki/Testwiki:Support_desk and
 http://flow-tests.wmflabs.org/wiki/VisualEditor/Feedback
 [4] http://flow-tests.wmflabs.org/wiki/Topic:Qmkwqmp0wfcazy9c and

 https://www.mediawiki.org/wiki/Thread:Project:Support_desk/Error_creating_thumbnail:_Unable_to_save_thumbnail_to_destination
 [5] https://phabricator.wikimedia.org/T90763 ,
 https://phabricator.wikimedia.org/T91086 ,
 https://phabricator.wikimedia.org/T88114 ,
 https://phabricator.wikimedia.org/T76823
 [6] https://www.mediawiki.org/wiki/Talk:Sandbox


 --
 Nick Wilson (Quiddity)
 Community Liaison
 Wikimedia Foundation

 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

2015-03-16 Thread Ryan Lane
On Mon, Mar 16, 2015 at 6:02 PM, Risker risker...@gmail.com wrote:

 How about just converting those threads back to Wikitext, instead?  That
 script already exists, I've seen it used on Mediawiki. Will it mess up the
 pages that have already been converted using that script?

 Bottom line, it makes no sense to replace software that was considered
 barely suitable when it was first developed with new software that can't
 even do what that old, long-neglected software could do...and in several
 cases, there is no intention to ever add the features already available
 using Wikitext.

 As expectations increase for project users to post their
 comments/concerns/ideas/observations on Mediawiki, the use of Flow will
 become a barrier for participation.


As someone who used LQT a lot, I'd say I'd much rather flow replace the
pages I maintained using LQT. Maybe you dislike flow, but it's *way* more
useful than wikitext for discussion. I never want to go back to the days
where I needed to discuss things with wikitext ever again. Wikitext
discussion pages are just the absolute worst.

- Ryan
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

2015-03-16 Thread Kevin Wayne Williams

Nick Wilson (Quiddity) schreef op 2015/03/16 om 17:51:

LiquidThreads (LQT) has not been well-supported in a long time. Flow
is in active development, and more real-world use-cases will help
focus attention on the higher-priority features that are needed. To
that end, LQT pages at mediawiki.org will start being converted to
Flow in the next couple of weeks.


I assume that the intention is to greater increase the divide between 
Wikipedia editors and the Wikimedia Foundation? It would be nice if the 
WMF would focus on becoming good with the tools that editors use instead 
of attempting to convince them that inadequate substitutes are adequate.


KWW


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

2015-03-16 Thread Florian Schmidt
I fully upport and welcome this, but at least for Project:Support_desk you 
should communicate this on this LQT board, too, that it will be converted (if 
you didn't do hat already, i haven't looked now, because LQT ist terrible on 
mobile :P). There are probably very active supporters, who haven't subscribed 
this list, but they should have the possibility to post their needs and 
opinions about that.

Best,
Florian

Gesendet mit meinem HTC

- Reply message -
Von: Nick Wilson (Quiddity) nwil...@wikimedia.org
An: Wikimedia developers wikitech-l@lists.wikimedia.org
Betreff: [Wikitech-l] Starting conversion of LiquidThreads to Flow at 
mediawiki.org
Datum: Di., März 17, 2015 01:51

LiquidThreads (LQT) has not been well-supported in a long time. Flow
is in active development, and more real-world use-cases will help
focus attention on the higher-priority features that are needed. To
that end, LQT pages at mediawiki.org will start being converted to
Flow in the next couple of weeks.

There are about 1,600 existing LQT pages on Mediawiki, and the three
most active pages are VisualEditor/Feedback, Project:Support_desk, and
Help_talk:CirrusSearch.[1] The Collaboration team has been running
test conversions of those three pages, and fixing issues that have
come up. Those fixes are almost complete, and the team will be ready
to start converting LQT threads to Flow topics soon. (If you’re
interested in the progress, check out phab:T90788[2] and linked
tasks.) The latest set is visible at a labs test server.[3] See an
example topic comparison here: Flow vs LQT.[4])

The VisualEditor/Feedback page will be converted first (per James'
request), around the middle of next week. We’ll pause to assess any
high-priority changes required. After that, we will start converting
more pages. This process may take a couple of weeks to fully run.

The last page to be converted will be Project:Support_desk, as that is
the largest and most active LQT Board.

LQT Threads that are currently on your watchlist, will still be
watchlisted as Flow Topics. New Topics created at Flow Boards on your
watchlist will appear in your Echo notifications, and you can choose
whether or not to watchlist them.

The LQT namespaces will continue to exist. Links to posts/topics will
redirect appropriately, and the LQT history will remain available at
the original location, as well as being mirrored in the Flow history.

There’s a queue of new features in Flow that will be shipped over the
next month or so:

* Table of Contents is done
* Category support for Flow Header and Topics is done
* VE with editing toolbar coming last week of March (phab:T90763) [5]
* Editing other people’s comments coming last week of March (phab:T91086)
* Ability to change the width  side rail in progress, probably out in
April (phab:T88114])
* Search is in progress (no ETA yet) (phab:T76823)
* The ability to choose which Flow notifications end up in Echo,
watchlist, or both, and other more powerful options, will be coming up
next (no ETA yet)

That being said -- there are some LiquidThreads features that don’t
exist in Flow yet.
We’d like to hear which features you use on the current LQT boards,
and that you’re concerned about losing in the Flow conversion. At the
same time, we’d like further suggestions on how we could improve upon
that (or other) features from LQT.

Please give us feedback at
https://www.mediawiki.org/wiki/Topic:Sdoatsbslsafx6lw to keep it
centralized, and test freely at the sandbox.[6]

Much thanks, on behalf of the Collaboration Team,
Quiddity (WMF)

[1] https://www.mediawiki.org/wiki/VisualEditor/Feedback and
https://www.mediawiki.org/wiki/Help_talk:CirrusSearch and
https://www.mediawiki.org/wiki/Project:Support_desk
[2] https://phabricator.wikimedia.org/T90788
[3] http://flow-tests.wmflabs.org/wiki/Testwiki:Support_desk and
http://flow-tests.wmflabs.org/wiki/VisualEditor/Feedback
[4] http://flow-tests.wmflabs.org/wiki/Topic:Qmkwqmp0wfcazy9c and
https://www.mediawiki.org/wiki/Thread:Project:Support_desk/Error_creating_thumbnail:_Unable_to_save_thumbnail_to_destination
[5] https://phabricator.wikimedia.org/T90763 ,
https://phabricator.wikimedia.org/T91086 ,
https://phabricator.wikimedia.org/T88114 ,
https://phabricator.wikimedia.org/T76823
[6] https://www.mediawiki.org/wiki/Talk:Sandbox


-- 
Nick Wilson (Quiddity)
Community Liaison
Wikimedia Foundation

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l