Mailing List Archive

Re: [Wikimedia-l] To Flow or not to Flow [ In reply to ]
Hi,

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

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

Cheers,
Craig

On 6 September 2014 14:49, Erik Moeller <erik@wikimedia.org> wrote:

> Hi all,
>
> I'm breaking out this discussion about Flow/talk pages (apologies for
> repeatedly breaking the megathread, but this is a well-scoped subject
> which deserves its own thread).
>
> Fundamentally, there's one key question to answer for talk pages in
> Wikimedia projects: Do we want discussions to occur in document mode,
> or in a structured comment mode? All else flows from there (pun
> intended).
>
> == Document mode ==
>
> There are not many examples of document mode discussion systems beyond
> wikis. You sometimes see people use collaborative realtime editors as
> such, because people want to talk in the same space where they work,
> but Google Docs provided alternatives (a pretty powerful
> comments/margin system and built-in chat) early on, for example.
>
> The current talk page system is a document mode system. Individual
> comments have unclear boundaries (a single transaction can result in
> multiple comments, signed or unsigned; indentation levels are
> unpredictable and often inconsistent). All the joys and pain points of
> working on the same document are present (a heavily trafficked talk
> page will see many edit conflicts). You can't easily show comments in
> multiple contexts (cross-wiki, via email, as a notification, etc.)
> because of the boundary problem.
>
> You could try to make a document mode system work better. On the basis
> of wikitext, you can do some very basic things, like the "new section"
> link I added to MediaWiki back in July 2003 [1], when I wrote: "This
> feature could also be the first stage of a more sophisticated
> discussion system, where the next stage would be auto-appending
> signatures and providing a 'Reply to this' link after each comment."
>
> But due to the aforementioned unpredictability, even making a "reply"
> link work consistently (and do the right thing) is non-trivial. You
> can get some of the way there, and the Wikipedia Teahouse actually has
> a gadget, written by Andrew Garrett (more on him below) that does
> precisely that.
>
> https://en.wikipedia.org/wiki/Wikipedia:Teahouse/Questions
>
> Note the "Join this discussion" link. It does give you a pop-up, and
> posts the comment for you in the right place, with indentation (it
> does not auto-sign, but instead tries to teach users the signature
> habit which they'll need to use on other talk pages).
>
> It may be worth doing more research and development on this, to see
> just how far we can get without changing the fundamentals, since a
> wholly new system may still be years out for wide use. However, there
> are inherent limitations due to the lack of a predictable and
> consistent structure.
>
> You could go further down the road of a document mode or hybrid
> system, but IMO not without introducing fully predictable comment
> markers (think <comment id="234234">Bla ~~~</comment>) -- which would
> pollute the wikitext, be fragile (e.g. accidental or deliberate
> corruption of identifiers), and probably be considered unacceptable in
> a system that still supports unlimited wikitext editing for those
> reasons.
>
> == Structured ==
>
> I personally gave up on patchwork on top of talk pages about 10 years
> ago. The advantages of having comments clearly identified as such are
> many:
>
> - Display comments in arbitrary order, arbitrary threading style
> - Search comments across date ranges
> - Search comments by author
> - Track comments as comments, not as diffs
> - Monitor changes at any part of a comment thread
> - Display comments independent of a given document (e.g. email,
> cross-wiki, etc.)
> - Display comment metadata in different formats easily (e.g. timestamps)
> - Update author names after a username change without having to update
> documents
> - Enables third parties to build new UIs (think Wikiwand for comments)
> more easily
> - Ability to tag/categorize individual comments/threads
> - and more.
>
> I identified some of these reasons when I wrote the proposal for
> LiquidThreads in October 2004 [2]. At that point, the Wikimedia
> Foundation had 0 employees, and this was too large an effort to likely
> get traction just from ad hoc volunteering. So after some time, I
> managed to persuade third parties to fund development, including
> Wikicities and WikiEducator, and found a developer to do the initial
> work, David McCabe. David did a good initial job but the system had
> many known issues and was only deployed at a small scale.
>
> At the same time, I think there were many things about even the
> original design that were good (and aren't found in most other forum
> systems):
>
> - It preserved "headers" on top of the threaded conversation as
> community-editable wiki-like spaces
> - It had a full history model for the thread itself, not just comments
> - It preserved comments essentially as individual wiki pages, with
> their own history
> - It had a built-in notion of thread summaries, collaboratively
> written, for closing comments
>
> As WMF started to grow, it took on development of LiquidThreads --
> with one developer, Andrew Garrett, who did an amazing job cleaning up
> the codebase and rethinking many of the assumptions David had made.
> LQT got to a point where some Wikimedia wikis actually requested for
> it to be enabled and traction started to build in favor of it. To this
> date, it is still found in some nooks and crannies in the Wikimedia
> universe.
>
> translatewiki.net still uses it for its support page, and
> MediaWiki.org for its support desk, which are probably the highest
> profile uses left, and both get a fair bit of comment traffic.
>
> Andrew did a ton of work on the project, but he himself recognized
> many architectural issues he wanted to address, and there are also UI
> assumptions we wanted to revisit. The project didn't have a team
> behind it at that time -- just one very talented part-time developer
> who was still at university! This was when WMF was barely growing to
> do development work, picking up some stuff (like LQT and FlaggedRevs)
> that had been simmering at a smaller scale before then.
>
> In 2011, Brandon Harris, the first person at WMF ever to be tasked
> exclusively with design responsibilities, took a crack at some initial
> redesign drafts [5][6], which still contain many ideas worth looking
> at. But we pulled the plug at that time, because we recognized that we
> simply didn't have the personpower to put the resources behind the
> project to actually get it anywhere near completion -- and that a
> major architectural overhaul was required to do so.
>
> A new effort was launched about a year ago, now resourcing a full team
> including design, development, product management, community support.
> (We're still pretty short staffed on UX research, QA, and data analyst
> support, but we make do.) As the team (including Andrew with his LQT
> experience under his belt) thought through the architectural needs of
> a modern discussion system, they decided that the LQT architecture was
> not salvageable. A migration script [7] is in development by Andrew
> himself.
>
> The Flow architecture [8] differs in some important ways from LQT,
> including:
>
> - Flow doesn't pretend that comments are "pages", instead using its
> own separate tables to manage them. This is architecturally important
> to give us more flexibility on how to store, version, query, search,
> and describe comments.
>
> - Flow is built from the start to store comments in a central
> datastore, to make it easier to display comments and relevant
> notifications cross-wiki.
>
> - Flow users Parsoid's HTML underneath, to prepare it for VisualEditor.
>
> I don't think the architecture is perfect, but it should be a
> reasonable foundation to build on and iterate from.
>
> The Flow UI, similarly, represents a first pass at this point. A lot
> of basic functionality is still missing. Things we know will make
> users happy (like cross-wiki features) are still ways out. It doesn't
> support VisualEditor yet, and yet its wikitext input suffers from any
> issues Parsoid does -- decisions made to future-proof the architecture
> have negative short term impact.
>
> And like any brand-new UI, it could use lots of micro-optimization --
> glitches here and there, which you may not even consciously notice,
> but which give you the feeling that you're using not-quite-ready
> software. Which you are.
>
> At the same time, we know from user studies that talk pages are
> incredibly hard for new users to figure out. The semantics are just
> extremely different from anything else on the web. So we think a
> support forum like the Teahouse, and its equivalent in other languages
> may be a good place to start -- provided the hosts agree that there
> are no dealbreaker issues for them. This parallels the long adoption
> of LQT for support desk type forums.
>
> In this context, we also want to do some systematic measurement: How
> does such a system affect the # of comments posted, and the quality of
> the discussion?
>
> We expect that we'd need to focus in on this use case in production
> for quite some time to get it right and really get people to fall in
> love with the system as it improves. At the same time, there may be
> other use cases that are less contentious and could serve as
> additional trials -- like talk pages in Wikidata.
>
> We're not pushing an aggressive schedule on Flow -- we understand it
> needs to happen at the pace of the communities, since you can't build
> an "opt-out" for this kind of system (unlike VisualEditor). So the
> schedule is going to have to give as needed.
>
> And as above, I'm open to us putting some short term effort into talk
> page improvements that can be made without Flow -- knowing it's still
> some time out. But based on the above long term functional and
> architectural considerations, I think a system that treats
> comments/threads as structured information, rather than as documents,
> is ultimately necessary, so I'd argue against procrastinating. It's
> going to be hard enough as it is to get this done without putting it
> on the backburner once more.
>
> Finally, any comment that is about specific Flow UI aspects should be
> treated with a massive block of salt. The UI will evolve dramatically
> as we learn what works for new and experienced users alike.
>
> Sincerely,
> Erik
>
> [1]
> https://lists.wikimedia.org/pipermail/wikipedia-l/2003-July/011069.html
> [2]
> https://meta.wikimedia.org/w/index.php?title=LiquidThreads&oldid=100760
> [3] https://translatewiki.net/wiki/Support
> [4] https://www.mediawiki.org/wiki/Project:Support_desk
> [5]
> https://upload.wikimedia.org/wikipedia/commons/5/5c/LQT-v2-TalkPage-Full.png
> [6] https://www.mediawiki.org/wiki/LiquidThreads_3.0/Design
> [7] https://gerrit.wikimedia.org/r/#/c/119243/
> [8] https://www.mediawiki.org/wiki/Flow/Architecture
> --
> Erik Möller
> VP of Engineering and Product Development, Wikimedia Foundation
>
> _______________________________________________
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
Re: [Wikimedia-l] To Flow or not to Flow [ In reply to ]
Let me begin with this: my preferences lie far closer to yours,
Gerard, than Diego's. I believe that we have a document oriented
system that works well for stuff like encyclopedic content. But I
think that we should be conducting our discussions in a discussion
oriented system. That doesn't necessarily mean more structure- after
all, Wikipedia pages are almost always highly structured documents-
but it certainly requires '''different''' structure that might be
enforced by software as opposed to editorial convention.

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

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

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

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

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

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

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

,Wil

_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
Re: [Wikimedia-l] To Flow or not to Flow [ In reply to ]
On 09/07/2014 01:57 AM, Diego Moya wrote:
> a major property of a document-centric architecture that is lost in a
> structured one is that it's open-ended, which means that end users can
> build new features and flows on top of it, without the need to request the
> platform developers to build support for them (sometimes even without
> writing new software at all; new workflows can be designed and maintained
> purely through social convention).

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

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

-- Marc


_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
Re: [Wikimedia-l] To Flow or not to Flow [ In reply to ]
On 7 September 2014 23:54, Marc A. Pelletier <marc@uberbox.org> wrote:

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

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

Risker/Anne
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
Re: [Wikimedia-l] To Flow or not to Flow [ In reply to ]
On Sun, Sep 7, 2014 at 9:54 PM, Marc A. Pelletier <marc@uberbox.org> wrote:

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

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


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


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


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

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

Todd
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
Re: [Wikimedia-l] To Flow or not to Flow [ In reply to ]
I composed the following as part of a longer message, but I decided
not to send it unless others were having similar issues since I'm on
track to exceed my monthly allowance of posts here ;):

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

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

I set out to answer this myself.

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

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

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

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

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

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

,Wil

On Sun, Sep 7, 2014 at 7:28 PM, Craig Franklin
<cfranklin@halonetwork.net> wrote:
> Hi,
>
> Is there a page somewhere where I can see a detailed functional
> specification of this product, showing how it'll work, what
> functions/features it will include in it's MVP state, and such? I know
> about the page on Mediawiki ( https://www.mediawiki.org/wiki/Flow ) that
> talks about things in generalities and answers some specific questions in
> the FAQ, but I've not been able to locate any document that tells me
> exactly what it will *do*.
>
> I have to confess that I'm not entirely confident that the rollout of Flow
> will be any smoother than the rollout of Visual Editor or MediaViewer,
> largely because I'm not entirely confident of what it is that I'm supposed
> to be getting. I'd be delighted to be corrected on this point if there is
> something out there that I've missed.
>
> Cheers,
> Craig
>
> On 6 September 2014 14:49, Erik Moeller <erik@wikimedia.org> wrote:
>
>> Hi all,
>>
>> I'm breaking out this discussion about Flow/talk pages (apologies for
>> repeatedly breaking the megathread, but this is a well-scoped subject
>> which deserves its own thread).
>>
>> Fundamentally, there's one key question to answer for talk pages in
>> Wikimedia projects: Do we want discussions to occur in document mode,
>> or in a structured comment mode? All else flows from there (pun
>> intended).
>>
>> == Document mode ==
>>
>> There are not many examples of document mode discussion systems beyond
>> wikis. You sometimes see people use collaborative realtime editors as
>> such, because people want to talk in the same space where they work,
>> but Google Docs provided alternatives (a pretty powerful
>> comments/margin system and built-in chat) early on, for example.
>>
>> The current talk page system is a document mode system. Individual
>> comments have unclear boundaries (a single transaction can result in
>> multiple comments, signed or unsigned; indentation levels are
>> unpredictable and often inconsistent). All the joys and pain points of
>> working on the same document are present (a heavily trafficked talk
>> page will see many edit conflicts). You can't easily show comments in
>> multiple contexts (cross-wiki, via email, as a notification, etc.)
>> because of the boundary problem.
>>
>> You could try to make a document mode system work better. On the basis
>> of wikitext, you can do some very basic things, like the "new section"
>> link I added to MediaWiki back in July 2003 [1], when I wrote: "This
>> feature could also be the first stage of a more sophisticated
>> discussion system, where the next stage would be auto-appending
>> signatures and providing a 'Reply to this' link after each comment."
>>
>> But due to the aforementioned unpredictability, even making a "reply"
>> link work consistently (and do the right thing) is non-trivial. You
>> can get some of the way there, and the Wikipedia Teahouse actually has
>> a gadget, written by Andrew Garrett (more on him below) that does
>> precisely that.
>>
>> https://en.wikipedia.org/wiki/Wikipedia:Teahouse/Questions
>>
>> Note the "Join this discussion" link. It does give you a pop-up, and
>> posts the comment for you in the right place, with indentation (it
>> does not auto-sign, but instead tries to teach users the signature
>> habit which they'll need to use on other talk pages).
>>
>> It may be worth doing more research and development on this, to see
>> just how far we can get without changing the fundamentals, since a
>> wholly new system may still be years out for wide use. However, there
>> are inherent limitations due to the lack of a predictable and
>> consistent structure.
>>
>> You could go further down the road of a document mode or hybrid
>> system, but IMO not without introducing fully predictable comment
>> markers (think <comment id="234234">Bla ~~~</comment>) -- which would
>> pollute the wikitext, be fragile (e.g. accidental or deliberate
>> corruption of identifiers), and probably be considered unacceptable in
>> a system that still supports unlimited wikitext editing for those
>> reasons.
>>
>> == Structured ==
>>
>> I personally gave up on patchwork on top of talk pages about 10 years
>> ago. The advantages of having comments clearly identified as such are
>> many:
>>
>> - Display comments in arbitrary order, arbitrary threading style
>> - Search comments across date ranges
>> - Search comments by author
>> - Track comments as comments, not as diffs
>> - Monitor changes at any part of a comment thread
>> - Display comments independent of a given document (e.g. email,
>> cross-wiki, etc.)
>> - Display comment metadata in different formats easily (e.g. timestamps)
>> - Update author names after a username change without having to update
>> documents
>> - Enables third parties to build new UIs (think Wikiwand for comments)
>> more easily
>> - Ability to tag/categorize individual comments/threads
>> - and more.
>>
>> I identified some of these reasons when I wrote the proposal for
>> LiquidThreads in October 2004 [2]. At that point, the Wikimedia
>> Foundation had 0 employees, and this was too large an effort to likely
>> get traction just from ad hoc volunteering. So after some time, I
>> managed to persuade third parties to fund development, including
>> Wikicities and WikiEducator, and found a developer to do the initial
>> work, David McCabe. David did a good initial job but the system had
>> many known issues and was only deployed at a small scale.
>>
>> At the same time, I think there were many things about even the
>> original design that were good (and aren't found in most other forum
>> systems):
>>
>> - It preserved "headers" on top of the threaded conversation as
>> community-editable wiki-like spaces
>> - It had a full history model for the thread itself, not just comments
>> - It preserved comments essentially as individual wiki pages, with
>> their own history
>> - It had a built-in notion of thread summaries, collaboratively
>> written, for closing comments
>>
>> As WMF started to grow, it took on development of LiquidThreads --
>> with one developer, Andrew Garrett, who did an amazing job cleaning up
>> the codebase and rethinking many of the assumptions David had made.
>> LQT got to a point where some Wikimedia wikis actually requested for
>> it to be enabled and traction started to build in favor of it. To this
>> date, it is still found in some nooks and crannies in the Wikimedia
>> universe.
>>
>> translatewiki.net still uses it for its support page, and
>> MediaWiki.org for its support desk, which are probably the highest
>> profile uses left, and both get a fair bit of comment traffic.
>>
>> Andrew did a ton of work on the project, but he himself recognized
>> many architectural issues he wanted to address, and there are also UI
>> assumptions we wanted to revisit. The project didn't have a team
>> behind it at that time -- just one very talented part-time developer
>> who was still at university! This was when WMF was barely growing to
>> do development work, picking up some stuff (like LQT and FlaggedRevs)
>> that had been simmering at a smaller scale before then.
>>
>> In 2011, Brandon Harris, the first person at WMF ever to be tasked
>> exclusively with design responsibilities, took a crack at some initial
>> redesign drafts [5][6], which still contain many ideas worth looking
>> at. But we pulled the plug at that time, because we recognized that we
>> simply didn't have the personpower to put the resources behind the
>> project to actually get it anywhere near completion -- and that a
>> major architectural overhaul was required to do so.
>>
>> A new effort was launched about a year ago, now resourcing a full team
>> including design, development, product management, community support.
>> (We're still pretty short staffed on UX research, QA, and data analyst
>> support, but we make do.) As the team (including Andrew with his LQT
>> experience under his belt) thought through the architectural needs of
>> a modern discussion system, they decided that the LQT architecture was
>> not salvageable. A migration script [7] is in development by Andrew
>> himself.
>>
>> The Flow architecture [8] differs in some important ways from LQT,
>> including:
>>
>> - Flow doesn't pretend that comments are "pages", instead using its
>> own separate tables to manage them. This is architecturally important
>> to give us more flexibility on how to store, version, query, search,
>> and describe comments.
>>
>> - Flow is built from the start to store comments in a central
>> datastore, to make it easier to display comments and relevant
>> notifications cross-wiki.
>>
>> - Flow users Parsoid's HTML underneath, to prepare it for VisualEditor.
>>
>> I don't think the architecture is perfect, but it should be a
>> reasonable foundation to build on and iterate from.
>>
>> The Flow UI, similarly, represents a first pass at this point. A lot
>> of basic functionality is still missing. Things we know will make
>> users happy (like cross-wiki features) are still ways out. It doesn't
>> support VisualEditor yet, and yet its wikitext input suffers from any
>> issues Parsoid does -- decisions made to future-proof the architecture
>> have negative short term impact.
>>
>> And like any brand-new UI, it could use lots of micro-optimization --
>> glitches here and there, which you may not even consciously notice,
>> but which give you the feeling that you're using not-quite-ready
>> software. Which you are.
>>
>> At the same time, we know from user studies that talk pages are
>> incredibly hard for new users to figure out. The semantics are just
>> extremely different from anything else on the web. So we think a
>> support forum like the Teahouse, and its equivalent in other languages
>> may be a good place to start -- provided the hosts agree that there
>> are no dealbreaker issues for them. This parallels the long adoption
>> of LQT for support desk type forums.
>>
>> In this context, we also want to do some systematic measurement: How
>> does such a system affect the # of comments posted, and the quality of
>> the discussion?
>>
>> We expect that we'd need to focus in on this use case in production
>> for quite some time to get it right and really get people to fall in
>> love with the system as it improves. At the same time, there may be
>> other use cases that are less contentious and could serve as
>> additional trials -- like talk pages in Wikidata.
>>
>> We're not pushing an aggressive schedule on Flow -- we understand it
>> needs to happen at the pace of the communities, since you can't build
>> an "opt-out" for this kind of system (unlike VisualEditor). So the
>> schedule is going to have to give as needed.
>>
>> And as above, I'm open to us putting some short term effort into talk
>> page improvements that can be made without Flow -- knowing it's still
>> some time out. But based on the above long term functional and
>> architectural considerations, I think a system that treats
>> comments/threads as structured information, rather than as documents,
>> is ultimately necessary, so I'd argue against procrastinating. It's
>> going to be hard enough as it is to get this done without putting it
>> on the backburner once more.
>>
>> Finally, any comment that is about specific Flow UI aspects should be
>> treated with a massive block of salt. The UI will evolve dramatically
>> as we learn what works for new and experienced users alike.
>>
>> Sincerely,
>> Erik
>>
>> [1]
>> https://lists.wikimedia.org/pipermail/wikipedia-l/2003-July/011069.html
>> [2]
>> https://meta.wikimedia.org/w/index.php?title=LiquidThreads&oldid=100760
>> [3] https://translatewiki.net/wiki/Support
>> [4] https://www.mediawiki.org/wiki/Project:Support_desk
>> [5]
>> https://upload.wikimedia.org/wikipedia/commons/5/5c/LQT-v2-TalkPage-Full.png
>> [6] https://www.mediawiki.org/wiki/LiquidThreads_3.0/Design
>> [7] https://gerrit.wikimedia.org/r/#/c/119243/
>> [8] https://www.mediawiki.org/wiki/Flow/Architecture
>> --
>> Erik Möller
>> VP of Engineering and Product Development, Wikimedia Foundation
>>
>> _______________________________________________
>> Wikimedia-l mailing list, guidelines at:
>> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
>> Wikimedia-l@lists.wikimedia.org
>> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
>> <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
> _______________________________________________
> Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>

_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
Re: [Wikimedia-l] To Flow or not to Flow [ In reply to ]
On Mon, Sep 8, 2014 at 1:54 PM, Marc A. Pelletier <marc@uberbox.org> wrote:
> On 09/07/2014 01:57 AM, Diego Moya wrote:
>> a major property of a document-centric architecture that is lost in a
>> structured one is that it's open-ended, which means that end users can
>> build new features and flows on top of it, without the need to request the
>> platform developers to build support for them (sometimes even without
>> writing new software at all; new workflows can be designed and maintained
>> purely through social convention).
>
> And yet, after over a decade of open-ended design through social
> convention, the end result is... our current talk pages. Perhaps
> another decade or two will be needed before that document-centric
> architecture gives us a half-decent discussion system?

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

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

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

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

This potential problematic deploy could be very easily de-escalated by
a WMF decision that Flow will not be forcibly deployed onto an
unwilling project, and can be deployed per-page. If it is good
software, the projects will *ask* for it to be deployed, like they did
with LiquidThreads, and users will want to use it on their user talk
even if the wider community isnt ready to migrate. e.g. once it is
beta quality, I am sure Jimmy Wales will want it enabled on his user
talk page, which would increase exposure to, and acceptance of, Flow.

--
John Vandenberg

_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
Re: [Wikimedia-l] To Flow or not to Flow [ In reply to ]
On 8 September 2014 00:46, John Mark Vandenberg <jayvdb@gmail.com> wrote:

<snip>


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

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

Risker/Anne
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
Re: [Wikimedia-l] To Flow or not to Flow [ In reply to ]
Hoi,
There are two ways to look at the talk systems. It served us so far to some
extend. It has been considered in need of replacement for a long time and
consequently we have systems like Liquid Threads that are arguably at least
as good in many use cases and fail in others.

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

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

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


On 8 September 2014 06:13, Risker <risker.wp@gmail.com> wrote:

> On 7 September 2014 23:54, Marc A. Pelletier <marc@uberbox.org> wrote:
>
> > On 09/07/2014 01:57 AM, Diego Moya wrote:
> > > a major property of a document-centric architecture that is lost in a
> > > structured one is that it's open-ended, which means that end users can
> > > build new features and flows on top of it, without the need to request
> > the
> > > platform developers to build support for them (sometimes even without
> > > writing new software at all; new workflows can be designed and
> maintained
> > > purely through social convention).
> >
> > And yet, after over a decade of open-ended design through social
> > convention, the end result is... our current talk pages. Perhaps
> > another decade or two will be needed before that document-centric
> > architecture gives us a half-decent discussion system?
> >
> > Sorry if that sound snarky, but I have difficulty buying an argument
> > that the current system has the potential to suffice when it has
> > demonstrably already failed. It does no good to have the hypothetical
> > capacity for a good system if, in practice, it's unusable.
> >
> > -- Marc
> >
> >
> I suppose the question really is, has it failed? On what basis are we
> saying that our current discussion system is unusable?
>
> Simply put, I'd suggest that the problem isn't the system, it's the
> discussion process itself that has points of failure. The replacement of
> actual discussion with templates is a point of failure, and that will not
> be improved by a change in the platform if all that happens is we use
> basically the same templates to have the same non-discussions. Nothing in
> the technology, either document-based or open-ended, will change the nature
> of the discourse itself; rude people will still be rude, erudite people
> will still be erudite, and none of will change the snark on Jimbo Wales's
> talk page. A significant percentage of Wikimedians rarely use talk pages at
> all (and a goodly number of those identify as exopedians), but no evidence
> that the percentage of Wikimedians who eschew social interaction has
> changed significantly, or that those with a low level of contribution to
> discussion space are doing so because they find the *technology*
> unappealing.
>
> Risker/Anne
> _______________________________________________
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
>
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
Re: [Wikimedia-l] To Flow or not to Flow [ In reply to ]
Hoi,
You missed the multiple discussion pages in all the "other" languages. They
are certainly as observant, as eloquent and they have different use cases
and issues as well.
Thanks,
GerardM


On 8 September 2014 06:26, Wil Sinclair <wllm@wllm.com> wrote:

> I composed the following as part of a longer message, but I decided
> not to send it unless others were having similar issues since I'm on
> track to exceed my monthly allowance of posts here ;):
>
> "
> There's one thing in this discussion that troubles me greatly.
>
> We've got a treasure trove of information/feedback in this thread from
> some of the people who are most knowledgable about the software and
> the problems it's trying to solve. Are we sure we're capturing all of
> the take-aways somewhere? How about the unresolved concerns? Is
> anything getting lost in transient discussions here or elsewhere?
>
> I set out to answer this myself.
>
> First, I looked for the talk page on Flow. Here it is:
>
> https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Flow&action=history
> The first things to strike me are that it is very long, very active,
> very unstructured, and archived across 10 pages and counting. Hmmm.
> Same questions as above, applied to exponentially more threads.
>
> Next, I went to bugzilla:
>
> https://bugzilla.wikimedia.org/buglist.cgi?component=Flow&list_id=342315&product=MediaWiki&product=MediaWiki%20extensions&product=Wikimedia
> . Much more structured and captures some requirements in a workflow.
> Not so good for discussing higher-level issues, however. Moreover,
> that doesn't seem to be what the development team is keeping their
> backlog in. Off to trello. . .
>
> I'm an experienced development manager that has been evangelizing
> agile programming of all stripes since 2001, and it took my searching
> the Flow talk page and clicking on a specific task to figure out how
> to list the backlog in trello. I think this is the right link in case
> you're looking for it yourself:
> https://trello.com/b/HD0lBssr/flow-backlog. A lot of these items link
> back to bugzilla and to another Flow discussion page. . .
>
> . . .on the MediaWiki site conducted in Flow itself:
> https://www.mediawiki.org/wiki/Talk:Flow. I think I'll stop here,
> although there are more places where Flow is discussed, and I haven't
> even gotten in to the mainspace pages that are edited by the Wikimedia
> and MediaWiki developers to communicate outwards to the broader
> community.
> "
>
> The summary of the tl;dr version is that it seems like there are
> opportunities to improve the discussion of Flow, starting with
> conducting it in fewer places and adding all takeaways as requirements
> to a workflow we can all track. The next step would be a discussion
> around prioritizing these requirements. Has this been done for Flow
> with full community involvement? If not, I think the WMF should take
> the lead on this one and show the community that it has taken the
> lessons from the recent MV experience and other poorly received
> rollouts to heart.
>
> WMF, I appeal to you directly when I ask you to get us more involved,
> and, moreover, get us more invested in the success of Flow starting
> now by leading a discussion too many on this list and elsewhere have
> said hasn't happened and/or hasn't been heeded.
>
> ,Wil
>
> On Sun, Sep 7, 2014 at 7:28 PM, Craig Franklin
> <cfranklin@halonetwork.net> wrote:
> > Hi,
> >
> > Is there a page somewhere where I can see a detailed functional
> > specification of this product, showing how it'll work, what
> > functions/features it will include in it's MVP state, and such? I know
> > about the page on Mediawiki ( https://www.mediawiki.org/wiki/Flow ) that
> > talks about things in generalities and answers some specific questions in
> > the FAQ, but I've not been able to locate any document that tells me
> > exactly what it will *do*.
> >
> > I have to confess that I'm not entirely confident that the rollout of
> Flow
> > will be any smoother than the rollout of Visual Editor or MediaViewer,
> > largely because I'm not entirely confident of what it is that I'm
> supposed
> > to be getting. I'd be delighted to be corrected on this point if there
> is
> > something out there that I've missed.
> >
> > Cheers,
> > Craig
> >
> > On 6 September 2014 14:49, Erik Moeller <erik@wikimedia.org> wrote:
> >
> >> Hi all,
> >>
> >> I'm breaking out this discussion about Flow/talk pages (apologies for
> >> repeatedly breaking the megathread, but this is a well-scoped subject
> >> which deserves its own thread).
> >>
> >> Fundamentally, there's one key question to answer for talk pages in
> >> Wikimedia projects: Do we want discussions to occur in document mode,
> >> or in a structured comment mode? All else flows from there (pun
> >> intended).
> >>
> >> == Document mode ==
> >>
> >> There are not many examples of document mode discussion systems beyond
> >> wikis. You sometimes see people use collaborative realtime editors as
> >> such, because people want to talk in the same space where they work,
> >> but Google Docs provided alternatives (a pretty powerful
> >> comments/margin system and built-in chat) early on, for example.
> >>
> >> The current talk page system is a document mode system. Individual
> >> comments have unclear boundaries (a single transaction can result in
> >> multiple comments, signed or unsigned; indentation levels are
> >> unpredictable and often inconsistent). All the joys and pain points of
> >> working on the same document are present (a heavily trafficked talk
> >> page will see many edit conflicts). You can't easily show comments in
> >> multiple contexts (cross-wiki, via email, as a notification, etc.)
> >> because of the boundary problem.
> >>
> >> You could try to make a document mode system work better. On the basis
> >> of wikitext, you can do some very basic things, like the "new section"
> >> link I added to MediaWiki back in July 2003 [1], when I wrote: "This
> >> feature could also be the first stage of a more sophisticated
> >> discussion system, where the next stage would be auto-appending
> >> signatures and providing a 'Reply to this' link after each comment."
> >>
> >> But due to the aforementioned unpredictability, even making a "reply"
> >> link work consistently (and do the right thing) is non-trivial. You
> >> can get some of the way there, and the Wikipedia Teahouse actually has
> >> a gadget, written by Andrew Garrett (more on him below) that does
> >> precisely that.
> >>
> >> https://en.wikipedia.org/wiki/Wikipedia:Teahouse/Questions
> >>
> >> Note the "Join this discussion" link. It does give you a pop-up, and
> >> posts the comment for you in the right place, with indentation (it
> >> does not auto-sign, but instead tries to teach users the signature
> >> habit which they'll need to use on other talk pages).
> >>
> >> It may be worth doing more research and development on this, to see
> >> just how far we can get without changing the fundamentals, since a
> >> wholly new system may still be years out for wide use. However, there
> >> are inherent limitations due to the lack of a predictable and
> >> consistent structure.
> >>
> >> You could go further down the road of a document mode or hybrid
> >> system, but IMO not without introducing fully predictable comment
> >> markers (think <comment id="234234">Bla ~~~</comment>) -- which would
> >> pollute the wikitext, be fragile (e.g. accidental or deliberate
> >> corruption of identifiers), and probably be considered unacceptable in
> >> a system that still supports unlimited wikitext editing for those
> >> reasons.
> >>
> >> == Structured ==
> >>
> >> I personally gave up on patchwork on top of talk pages about 10 years
> >> ago. The advantages of having comments clearly identified as such are
> >> many:
> >>
> >> - Display comments in arbitrary order, arbitrary threading style
> >> - Search comments across date ranges
> >> - Search comments by author
> >> - Track comments as comments, not as diffs
> >> - Monitor changes at any part of a comment thread
> >> - Display comments independent of a given document (e.g. email,
> >> cross-wiki, etc.)
> >> - Display comment metadata in different formats easily (e.g. timestamps)
> >> - Update author names after a username change without having to update
> >> documents
> >> - Enables third parties to build new UIs (think Wikiwand for comments)
> >> more easily
> >> - Ability to tag/categorize individual comments/threads
> >> - and more.
> >>
> >> I identified some of these reasons when I wrote the proposal for
> >> LiquidThreads in October 2004 [2]. At that point, the Wikimedia
> >> Foundation had 0 employees, and this was too large an effort to likely
> >> get traction just from ad hoc volunteering. So after some time, I
> >> managed to persuade third parties to fund development, including
> >> Wikicities and WikiEducator, and found a developer to do the initial
> >> work, David McCabe. David did a good initial job but the system had
> >> many known issues and was only deployed at a small scale.
> >>
> >> At the same time, I think there were many things about even the
> >> original design that were good (and aren't found in most other forum
> >> systems):
> >>
> >> - It preserved "headers" on top of the threaded conversation as
> >> community-editable wiki-like spaces
> >> - It had a full history model for the thread itself, not just comments
> >> - It preserved comments essentially as individual wiki pages, with
> >> their own history
> >> - It had a built-in notion of thread summaries, collaboratively
> >> written, for closing comments
> >>
> >> As WMF started to grow, it took on development of LiquidThreads --
> >> with one developer, Andrew Garrett, who did an amazing job cleaning up
> >> the codebase and rethinking many of the assumptions David had made.
> >> LQT got to a point where some Wikimedia wikis actually requested for
> >> it to be enabled and traction started to build in favor of it. To this
> >> date, it is still found in some nooks and crannies in the Wikimedia
> >> universe.
> >>
> >> translatewiki.net still uses it for its support page, and
> >> MediaWiki.org for its support desk, which are probably the highest
> >> profile uses left, and both get a fair bit of comment traffic.
> >>
> >> Andrew did a ton of work on the project, but he himself recognized
> >> many architectural issues he wanted to address, and there are also UI
> >> assumptions we wanted to revisit. The project didn't have a team
> >> behind it at that time -- just one very talented part-time developer
> >> who was still at university! This was when WMF was barely growing to
> >> do development work, picking up some stuff (like LQT and FlaggedRevs)
> >> that had been simmering at a smaller scale before then.
> >>
> >> In 2011, Brandon Harris, the first person at WMF ever to be tasked
> >> exclusively with design responsibilities, took a crack at some initial
> >> redesign drafts [5][6], which still contain many ideas worth looking
> >> at. But we pulled the plug at that time, because we recognized that we
> >> simply didn't have the personpower to put the resources behind the
> >> project to actually get it anywhere near completion -- and that a
> >> major architectural overhaul was required to do so.
> >>
> >> A new effort was launched about a year ago, now resourcing a full team
> >> including design, development, product management, community support.
> >> (We're still pretty short staffed on UX research, QA, and data analyst
> >> support, but we make do.) As the team (including Andrew with his LQT
> >> experience under his belt) thought through the architectural needs of
> >> a modern discussion system, they decided that the LQT architecture was
> >> not salvageable. A migration script [7] is in development by Andrew
> >> himself.
> >>
> >> The Flow architecture [8] differs in some important ways from LQT,
> >> including:
> >>
> >> - Flow doesn't pretend that comments are "pages", instead using its
> >> own separate tables to manage them. This is architecturally important
> >> to give us more flexibility on how to store, version, query, search,
> >> and describe comments.
> >>
> >> - Flow is built from the start to store comments in a central
> >> datastore, to make it easier to display comments and relevant
> >> notifications cross-wiki.
> >>
> >> - Flow users Parsoid's HTML underneath, to prepare it for VisualEditor.
> >>
> >> I don't think the architecture is perfect, but it should be a
> >> reasonable foundation to build on and iterate from.
> >>
> >> The Flow UI, similarly, represents a first pass at this point. A lot
> >> of basic functionality is still missing. Things we know will make
> >> users happy (like cross-wiki features) are still ways out. It doesn't
> >> support VisualEditor yet, and yet its wikitext input suffers from any
> >> issues Parsoid does -- decisions made to future-proof the architecture
> >> have negative short term impact.
> >>
> >> And like any brand-new UI, it could use lots of micro-optimization --
> >> glitches here and there, which you may not even consciously notice,
> >> but which give you the feeling that you're using not-quite-ready
> >> software. Which you are.
> >>
> >> At the same time, we know from user studies that talk pages are
> >> incredibly hard for new users to figure out. The semantics are just
> >> extremely different from anything else on the web. So we think a
> >> support forum like the Teahouse, and its equivalent in other languages
> >> may be a good place to start -- provided the hosts agree that there
> >> are no dealbreaker issues for them. This parallels the long adoption
> >> of LQT for support desk type forums.
> >>
> >> In this context, we also want to do some systematic measurement: How
> >> does such a system affect the # of comments posted, and the quality of
> >> the discussion?
> >>
> >> We expect that we'd need to focus in on this use case in production
> >> for quite some time to get it right and really get people to fall in
> >> love with the system as it improves. At the same time, there may be
> >> other use cases that are less contentious and could serve as
> >> additional trials -- like talk pages in Wikidata.
> >>
> >> We're not pushing an aggressive schedule on Flow -- we understand it
> >> needs to happen at the pace of the communities, since you can't build
> >> an "opt-out" for this kind of system (unlike VisualEditor). So the
> >> schedule is going to have to give as needed.
> >>
> >> And as above, I'm open to us putting some short term effort into talk
> >> page improvements that can be made without Flow -- knowing it's still
> >> some time out. But based on the above long term functional and
> >> architectural considerations, I think a system that treats
> >> comments/threads as structured information, rather than as documents,
> >> is ultimately necessary, so I'd argue against procrastinating. It's
> >> going to be hard enough as it is to get this done without putting it
> >> on the backburner once more.
> >>
> >> Finally, any comment that is about specific Flow UI aspects should be
> >> treated with a massive block of salt. The UI will evolve dramatically
> >> as we learn what works for new and experienced users alike.
> >>
> >> Sincerely,
> >> Erik
> >>
> >> [1]
> >> https://lists.wikimedia.org/pipermail/wikipedia-l/2003-July/011069.html
> >> [2]
> >> https://meta.wikimedia.org/w/index.php?title=LiquidThreads&oldid=100760
> >> [3] https://translatewiki.net/wiki/Support
> >> [4] https://www.mediawiki.org/wiki/Project:Support_desk
> >> [5]
> >>
> https://upload.wikimedia.org/wikipedia/commons/5/5c/LQT-v2-TalkPage-Full.png
> >> [6] https://www.mediawiki.org/wiki/LiquidThreads_3.0/Design
> >> [7] https://gerrit.wikimedia.org/r/#/c/119243/
> >> [8] https://www.mediawiki.org/wiki/Flow/Architecture
> >> --
> >> Erik Möller
> >> VP of Engineering and Product Development, Wikimedia Foundation
> >>
> >> _______________________________________________
> >> Wikimedia-l mailing list, guidelines at:
> >> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> >> Wikimedia-l@lists.wikimedia.org
> >> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> >> <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
> > _______________________________________________
> > Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> > Wikimedia-l@lists.wikimedia.org
> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
>
> _______________________________________________
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
>
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
Re: [Wikimedia-l] To Flow or not to Flow [ In reply to ]
On 8 September 2014 05:46, John Mark Vandenberg <jayvdb@gmail.com> wrote:

> If it is good
> software, the projects will *ask* for it to be deployed, like they did
> with LiquidThreads, and users will want to use it on their user talk
> even if the wider community isnt ready to migrate.


This is the key point.

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

(I asked this before.)


- d.

_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
Re: [Wikimedia-l] To Flow or not to Flow [ In reply to ]
A problem that I would like Flow to solve is the high amount of labor
needed to read over a dozen pages across four wikis in order for the reader
to access most of the MediaViewer discussions.

Pine
On Sep 8, 2014 12:22 AM, "David Gerard" <dgerard@gmail.com> wrote:

> On 8 September 2014 05:46, John Mark Vandenberg <jayvdb@gmail.com> wrote:
>
> > If it is good
> > software, the projects will *ask* for it to be deployed, like they did
> > with LiquidThreads, and users will want to use it on their user talk
> > even if the wider community isnt ready to migrate.
>
>
> This is the key point.
>
> Those of us who presently use talk pages to get the work done. What is
> going to make us *love* Flow, for all its imperfections, and demand to
> have it for ourselves? What's Flow's killer feature for us?
>
> (I asked this before.)
>
>
> - d.
>
> _______________________________________________
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
Re: [Wikimedia-l] To Flow or not to Flow [ In reply to ]
On 8 September 2014 05:54, Marc A. Pelletier <marc@uberbox.org> wrote:
> And yet, after over a decade of open-ended design through social
> convention, the end result is... our current talk pages. Perhaps
> another decade or two will be needed before that document-centric
> architecture gives us a half-decent discussion system?

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

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

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

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


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

_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
Re: [Wikimedia-l] To Flow or not to Flow [ In reply to ]
On 8 September 2014 11:44, Diego Moya <dialmove@gmail.com> wrote:

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

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

_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
Re: [Wikimedia-l] To Flow or not to Flow [ In reply to ]
Hoi,
Pine, I would like so many things.. I expect that SUL and more goodliness
from this will be a requirement. For me there is urgency in having a
discussion system that works for mobiles and templates...

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

On 8 September 2014 09:46, Pine W <wiki.pine@gmail.com> wrote:

> A problem that I would like Flow to solve is the high amount of labor
> needed to read over a dozen pages across four wikis in order for the reader
> to access most of the MediaViewer discussions.
>
> Pine
> On Sep 8, 2014 12:22 AM, "David Gerard" <dgerard@gmail.com> wrote:
>
> > On 8 September 2014 05:46, John Mark Vandenberg <jayvdb@gmail.com>
> wrote:
> >
> > > If it is good
> > > software, the projects will *ask* for it to be deployed, like they did
> > > with LiquidThreads, and users will want to use it on their user talk
> > > even if the wider community isnt ready to migrate.
> >
> >
> > This is the key point.
> >
> > Those of us who presently use talk pages to get the work done. What is
> > going to make us *love* Flow, for all its imperfections, and demand to
> > have it for ourselves? What's Flow's killer feature for us?
> >
> > (I asked this before.)
> >
> >
> > - d.
> >
> > _______________________________________________
> > Wikimedia-l mailing list, guidelines at:
> > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> > Wikimedia-l@lists.wikimedia.org
> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
> _______________________________________________
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
>
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
Re: [Wikimedia-l] To Flow or not to Flow [ In reply to ]
On 09/08/2014 12:46 AM, John Mark Vandenberg wrote:
> While it may not be everybody's dream system, talk pages are quite
> usable, as demonstrated by a lot of people using them every single
> day.

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

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

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

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

-- Marc


_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
Re: [Wikimedia-l] To Flow or not to Flow [ In reply to ]
That's not a reasonable task, Marc. Newbies have an equally hard time
editing content, too, and even when they succeed, on many projects they're
very likely to be reverted and deluged with templated messages in response
to a good faith attempt. There is no evidentiary basis to demonstrate that
new users have a harder time participating in discussion than they do in
content contribution. Independent studies seem to identify the nature of
the discussions as being significantly more problematic than the technical
means of participating.

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

Risker/Anne



On 8 September 2014 09:58, Marc A. Pelletier <marc@uberbox.org> wrote:

> On 09/08/2014 12:46 AM, John Mark Vandenberg wrote:
> > While it may not be everybody's dream system, talk pages are quite
> > usable, as demonstrated by a lot of people using them every single
> > day.
>
> That's... not a demonstration of usability. Like many people, I found
> myself using some random blunt object not designed for purpose to hammer
> in a nail at least once; that speaks to the importance of getting the
> nail in, not the lack of need for a proper hammer. :-)
>
> Let's be honest here; I'm /highly/ computer-literate, and I've been
> using Mediawiki for some 11 years and I *still* find talk pages an
> annoyance at the best of times and they can be downright painful if
> there's anything like a large discussion in progress you are attempting
> to track/participate in. Between edit conflicts, increasingly confusing
> indentation, signatures that may or may not make separation between
> commenters clear... It's no surprise that newbies are scared away.
> Editing articles is already hard enough, anything that provides an extra
> barrier to participation hurts - especially when that barrier lies in
> the way of getting /help/.
>
> Talk pages, as a mechanism, are lacking every affordance that users
> expect of a communication medium. And no, that X thousand people have
> gotten used to their failings does not make them any better for the Y
> billion people that have not.
>
> But don't take my word for it! Find random newbies, and ask them to try
> the simple task of commenting on a discussion in progress without giving
> them guidance. They they flail around, or simply give up, remember that
> it's not /them/ who have failed -- I'm pretty sure they've participated
> in plenty of other online discussions before.
>
> -- Marc
>
>
> _______________________________________________
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l@lists.wikimedia.org
> <https://meta.wikimedia.org/wiki/Mailing_lists/GuidelinesWikimedia-l@lists.wikimedia.org>
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
>
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
Re: [Wikimedia-l] To Flow or not to Flow [ In reply to ]
On 09/08/2014 10:18 AM, Risker wrote:
> The most obvious one is automatic signing of comments, and it is
> something that we have technically been able to impose for years; sinebot
> didn't come into existence in a vacuum.

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

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

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

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

-- Marc


_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
Re: [Wikimedia-l] To Flow or not to Flow [ In reply to ]
Well, I think that the "article editing" project (i.e., VE) has a huge
potential for also resolving a lot of discussion space issues. I don't see
tacking on yet another UI as being a positive for new editor introduction
or retention, and cannot think of another significant site that has two
such wildly divergent interfaces (one very flexible and the other very
rigid in structure), except perhaps in the mobile vs. desktop situation.

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

Risker/Anne


On 8 September 2014 10:24, Marc A. Pelletier <marc@uberbox.org> wrote:

> On 09/08/2014 10:18 AM, Risker wrote:
> > The most obvious one is automatic signing of comments, and it is
> > something that we have technically been able to impose for years; sinebot
> > didn't come into existence in a vacuum.
>
> I suppose that's a philosophical divergence between us then - that
> sinebot even needs to exist to me is demonstration that the system is
> broken.
>
> You say that discussion isn't all that much harder than editing content.
> Even if I agreed with that (and I do not, edit conflicts in articles
> are much rarer than on talk pages - and usually easier to sort out),
> that's not a *good* thing!
>
> Participating in discussion should be much, *much* easier than editing
> articles: encouraging newbies to seek help and participate in the
> community *before* diving in anything but trivial article edits would be
> an immensely powerful retention tool!
>
> (Which isn't to say that editing articles doesn't *also* need a lot of
> help - but that's a different project).
>
> -- Marc
>
>
> _______________________________________________
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l@lists.wikimedia.org
> <https://meta.wikimedia.org/wiki/Mailing_lists/GuidelinesWikimedia-l@lists.wikimedia.org>
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
>
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
Re: [Wikimedia-l] To Flow or not to Flow [ In reply to ]
Thank you for this overview and history, Erik!

On Fri, Sep 5, 2014 at 9:49 PM, Erik Moeller <erik@wikimedia.org> wrote:

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


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

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

best,
-- phoebe

--
* I use this address for lists; send personal messages to phoebe.ayers <at>
gmail.com *
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
Re: [Wikimedia-l] To Flow or not to Flow [ In reply to ]
Hello,

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

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

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

Kind regards
Ziko



Am Montag, 8. September 2014 schrieb Risker :

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

On 8 September 2014 16:43, Ziko van Dijk <zvandijk@gmail.com> wrote:

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




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

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

Visit http://www.wikimedia.org.uk/ and @wikimediauk
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
Re: [Wikimedia-l] To Flow or not to Flow [ In reply to ]
Facebook?

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

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

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


Risker/Anne



On 8 September 2014 11:43, Ziko van Dijk <zvandijk@gmail.com> wrote:

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

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

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

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

Regards

Jonathan Cardy


>

_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
Re: [Wikimedia-l] To Flow or not to Flow [ In reply to ]
On Mon, Sep 8, 2014 at 12:22 AM, David Gerard <dgerard@gmail.com> wrote:
> On 8 September 2014 05:46, John Mark Vandenberg <jayvdb@gmail.com> wrote:
> Those of us who presently use talk pages to get the work done. What is
> going to make us *love* Flow, for all its imperfections, and demand to
> have it for ourselves? What's Flow's killer feature for us?

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

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

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

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

So, educated guesses and hypotheses.

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

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

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

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

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

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

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

Flow -theoretically- even could have language awareness of individual
posts, enabling a single multilingual discussion space, easy
translation of individual comments, etc. A team of Japanese
researchers built something like this on top of LQT a few years ago,
as a prototype: http://langrid.org/mwikidev/ (Guess why they didn't
build it on old-school talk pages?) For a truly multilingual
community, I think that could be a killer feature -- as opposed to
just splitting the conversation spaces, as we do now.

3) Tags. The team hasn't decided if/how to implement tags yet. My own
bet is that they could be a killer feature. Let people add/edit those
right below the thread title with one click and see if they start
using them.

Say you want an article to be deleted. Start a thread with #afd tag,
explain your rationale, you're done. Other users can pull up the
recent #afd threads, sort by date, etc. Discussion can happen at the
article level or from the tag page.

Say you want to welcome new users. Leave a welcome note with #welcome
tag. Other users can join in on the welcome and give tips/hints.

Say you're a new user and you want to get help. Start a thread with
#help tag and it'll show up on that board. Other users can provide
help. (Yes, I know the {{helpme}} template which is sort of a very
poor person's version of this.)

Say you like a picture and you want to nominate it for FP status.
Leave a note with #fpc and it'll get added to that feed. (Tags that
are invoked from File talk: pages could dynamically include a thumb,
so no need for extra logic to do that.)

If people misuse tags, others will remove them. (And no, it doesn't
have to be the hashtag syntax. It could work like categories, where
tags could have pages describing them and their purpose -- I wouldn't
recommend using actual categories, because the hierarchy is overkill.)

You'd probably need a tiny bit more pixie dust for rich workflows, but
I'm not quite sold on the idea of a workflow domain language or
anything like that. I'd look for simple rules: Flow already has
"closure" as a discussion property, so closed threads could be easily
filtered. Setting a tag could generate a configurable notice on the
subject page. Etc.

Workflows built in wikitext are cool (I've built a few myself, and I
only hate myself a little bit for it in the morning), but they're not
the only way to build workflows. Tags, dynamic searches, pings, and
similar mechanisms can help build and improve workflows, as well,
potentially in a much more straightforward fashion.

Flow can help us expand our toolset, and it's for us (the WMF-us) to
prove that the balance of losses won't be too large in comparison to
our (the Wikimedia-us) gains. But we (Wikimedia-we) need to do that
cost accounting rationally, gently allowing reason, time, habit and
adoption to act as a counter to the normal over-accouting of losses
vs. gains.

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

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

1 2 3 4 5  View All