Mailing List Archive

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

I did a couple if simple tests on MediaWiki on Flow pages with often
occurring edits. The tests failed.

I am an admin on Commons, and I regularly have to remove an image on a talk
page because it is for example a violation of copyright. I see no way to
remove the copyright violation from the message.

Another thing I tried is the removal of a personal attack or a privacy
issue. It is common on nl-wiki to remove a personal attack out of a message
and replacing it by a template which says what happened. This is impossible
to do.

If a template is changed, its parameters on the various places where the
template is added need to be changed as well. This is done by hand or with
a bot (like AWB), both ways seems impossible with flow.

If someone added a message to the wrong page, it is relocated to another
talk page. Seems impossible to do here. If a message is considered to be
inappropriate for a certain page, it is relocated, seems impossible with
Flow.

Another thing I noticed is that I can't get a complete overview of all
messages added to a certain talk page. After 10 messages, everything is
hidden. A quick ctrl + F is impossible. When I know there was a discussion
about a specific thing, I want to check the talk page easily by searching
it completely, not possible. It is very annoying that I can't get a
complete overview of all messages on a talk page, this is a basic need!

As I read on mw:Flow: "to make the wiki discussion system more efficient
for experienced users" (as goal of Flow)
I get it! By making normal things impossible to do, the experienced users
have indeed less work...

For the rest I have seen no way why this method is more efficient for
experienced users, as it is not.


So, there is flow, and instead of the community can work with it as it
needs to work with, it does not flow but got stuck...

To answer the question, To Flow or not to Flow, it does not flow. I am not
able to do simple edits which are done every day.

Romaine



2014-09-06 6:49 GMT+02:00 Erik Moeller <erik@wikimedia.org>:

> 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 -> it does not flow [ In reply to ]
On 06.09.2014 23:14, Romaine Wiki wrote:
> Hello all,
>
> I did a couple if simple tests on MediaWiki on Flow pages with often
> occurring edits. The tests failed.
>
...

> So, there is flow, and instead of the community can work with it as it
> needs to work with, it does not flow but got stuck...
>
> To answer the question, To Flow or not to Flow, it does not flow. I am
> not
> able to do simple edits which are done every day.
>
> Romaine

Hi Romaine

thanks for the great post.

May be indeed a good starting point would be to invite the community
(not only en.wp and large projects, but also non-wikipedia and small
projects) to list all functionalities of the talk pages they need and
then discuss whether they are absolutely needed or we can survive
without them. I am not aware of this discussion ever taken place (at
least I am fairly active in several Wikimedia projects for a pretty long
time and I have never heard about it).

Cheers
Yaroslav

_______________________________________________
Wikimedia-l mailing list, 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 -> it does not flow [ In reply to ]
On Sat, Sep 6, 2014 at 2:14 PM, Romaine Wiki <romaine.wiki@gmail.com> wrote:

> I am an admin on Commons, and I regularly have to remove an image on a talk
> page because it is for example a violation of copyright. I see no way to
> remove the copyright violation from the message.
>
> Another thing I tried is the removal of a personal attack or a privacy
> issue. It is common on nl-wiki to remove a personal attack out of a message
> and replacing it by a template which says what happened. This is impossible
> to do.

Please see my response to Todd here explaining the current permissioning:
https://lists.wikimedia.org/pipermail/wikimedia-l/2014-September/074358.html

> If a template is changed, its parameters on the various places where the
> template is added need to be changed as well. This is done by hand or with
> a bot (like AWB), both ways seems impossible with flow.

Flow doesn't automatically update template output -- it retains the
output as it was when the user posted the comment. We can argue
whether that's good or bad behavior, but it's worth doing so in the
context of real examples. When would this cause problems?

Contrary to some descriptions, it's not quite the same as {{subst}}ing
the template. You can still get back to the wikitext used produce the
output, and change it, and potentially re-parse it. It just doesn't do
so automatically (which is also not an inherent limitation).

> If someone added a message to the wrong page, it is relocated to another
> talk page. Seems impossible to do here. If a message is considered to be
> inappropriate for a certain page, it is relocated, seems impossible with
> Flow.

It doesn't support any kind of moving yet, that's still (like many
features) to be developed, but unlike talk pages, it's architecturally
viable to move a whole thread and its history, rather than copying and
pasting content around, losing history, as we currently do routinely.

> Another thing I noticed is that I can't get a complete overview of all
> messages added to a certain talk page. After 10 messages, everything is
> hidden. A quick ctrl + F is impossible. When I know there was a discussion
> about a specific thing, I want to check the talk page easily by searching
> it completely, not possible. It is very annoying that I can't get a
> complete overview of all messages on a talk page, this is a basic need!

Of course, which is why it's a high priority feature.

> To answer the question, To Flow or not to Flow, it does not flow. I am not
> able to do simple edits which are done every day.

It's a system in early development, and has never been advertised as
anything else. To draw conclusions about what it can and cannot do is,
by definition, premature. A much more useful discussion is whether a
system like it (provided some of its properties are clarified and
improved) is desirable, and if not, what alternative ways there are to
make talk pages more user-friendly, and what the limitations of those
methods are. Also, to the extent that there are aspects of the Flow
architecture that really are dealbreakers, we should fix them now.

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

Flow is a long term bet that an architecture of tructured comments
will ultimately have fewer hard and fast limitations on how
collaboration in wikis can work, and will accrue usability benefits
very quickly (as it already has done, like faster posting and replies)
due to its architecture. So far we've only invested in the long term
bet -- some rebalancing of effort towards the short term may be
valuable, and may lead to interim milestones that impact users today
rather than years from now. I can't answer when you'd hit the
boundaries of what you can do with the free form text on talk pages
today, but I don't think anyone's really tried yet. (Magnus, I am
sending brain waves in your direction! ;-)

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>
Re: [Wikimedia-l] To Flow or not to Flow -> it does not flow [ In reply to ]
Hi,

I forgot to mention that we use a lot of template messages on talk pages to
inform users about something. In a part of these templates we automatically
add categories because we want to track the users who have problematic
behaviour. Testing this by adding a category to a message in Flow gives no
result.

Another issue I think of are deleted files and templates. They show up in
categories and special pages to be fixed.

Also often messages are copied to another page, including all the
wikisyntax. I haven't found any way to do that. Going from a Flow page to a
non-Flow page. This is a basic thing.

Also, so far I have seen, it is not possible to create a page with all the
discussions about a certain topic. This is currently possible to keep an
overview.

The option Permanent link is not working as I would expect. It is good that
there is a way to link to an individual topic (that is what Permanent link
currently does), but we also like and need the possibility to link to a
certain revision of a message. (This also would mean that if I post a
message, someone else reacts on it, I have to change my message and the
other person does it as well in his, that the permanent link to an earlier
version should show the topic as it was on that certain moment in time.)


I also found a bug, the links of the history page do not work in Dutch:
https://www.mediawiki.org/w/index.php?title=Topic:S1uggs1vsnq6d8g8&action=history&uselang=nl


One last thing I somehow notice that Flow gives me some feeling of
clumsiness. I can't qualify it yet somehow. Some buttons are not on
intuitive places. But what concerns me is that it is no longer a wiki way
of editing/responding. The community loses control over their pages and
messages as it is all fixed in the software. Flow takes away the ability to
organize and I do not think that is good development. I can understand and
imagine that Flow can be handy to reply on each other, but the thing that
Wikipedia (and MediaWiki) makes great is the ability to re-organize. The
community loses with the current state of Flow to much their control over
the content of talk pages.

Greetings,
Romaine






2014-09-06 23:23 GMT+02:00 Yaroslav M. Blanter <putevod@mccme.ru>:

> On 06.09.2014 23:14, Romaine Wiki wrote:
>
>> Hello all,
>>
>> I did a couple if simple tests on MediaWiki on Flow pages with often
>> occurring edits. The tests failed.
>>
>> ...
>
> So, there is flow, and instead of the community can work with it as it
>> needs to work with, it does not flow but got stuck...
>>
>> To answer the question, To Flow or not to Flow, it does not flow. I am not
>> able to do simple edits which are done every day.
>>
>> Romaine
>>
>
> Hi Romaine
>
> thanks for the great post.
>
> May be indeed a good starting point would be to invite the community (not
> only en.wp and large projects, but also non-wikipedia and small projects)
> to list all functionalities of the talk pages they need and then discuss
> whether they are absolutely needed or we can survive without them. I am not
> aware of this discussion ever taken place (at least I am fairly active in
> several Wikimedia projects for a pretty long time and I have never heard
> about it).
>
> Cheers
> Yaroslav
>
>
> _______________________________________________
> Wikimedia-l mailing list, 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 -> it does not flow [ In reply to ]
On 6 September 2014 15:33, Erik Moeller <erik@wikimedia.org> wrote:
>
> Flow doesn't automatically update template output -- it retains the
> output as it was when the user posted the comment. We can argue
> whether that's good or bad behavior, but it's worth doing so in the
> context of real examples. When would this cause problems?
>

I noticed this a few months ago and I think that in almost every case it's
not actually a problem. Many common talk pages templates are meant to be
substituted – in fact, some even spit out an error if you don't substitute
them! – so in most cases there's no substantial difference between
substitution and the way Flow currently does it; in both systems, using a
template generates a snapshot of the template at the time the post was made.

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

I expect that the reason most people find this so frustrating is not
because it results in any problems in and of itself, but because it
represents an inconsistency in the way that templates are handled in Flow
compared to how they're handled everywhere else, and therefore results in
Flow not behaving as an experienced user would expect. As I talked about
above though, the actual severity of that inconsistency is minor bordering
on trivial [2] in most cases.

Dan

[1]: https://en.wikipedia.org/wiki/Minimum_viable_product
[2]: https://www.mediawiki.org/wiki/Bugzilla/Fields#Severity

--
Dan Garry
Associate Product Manager, Mobile Apps
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>
Re: [Wikimedia-l] To Flow or not to Flow -> it does not flow [ In reply to ]
2014-09-07 0:33 GMT+02:00 Erik Moeller <erik@wikimedia.org>:

> On Sat, Sep 6, 2014 at 2:14 PM, Romaine Wiki <romaine.wiki@gmail.com>
> wrote:
>
> > I am an admin on Commons, and I regularly have to remove an image on a
> talk
> > page because it is for example a violation of copyright. I see no way to
> > remove the copyright violation from the message.
> >
> > Another thing I tried is the removal of a personal attack or a privacy
> > issue. It is common on nl-wiki to remove a personal attack out of a
> message
> > and replacing it by a template which says what happened. This is
> impossible
> > to do.
>
> Please see my response to Todd here explaining the current permissioning:
>
> https://lists.wikimedia.org/pipermail/wikimedia-l/2014-September/074358.html
>

Okay. One point I miss there, which I tried to mention in the post I typed
before I saw this one, is that there is a fundamental question to be
answered. The question is: who is in control of the content of pages.
Should the software be in control of pages or the local community? Maybe
this sounds strange, but the community has now the ability to rearrange a
talk page to reflect better the needs.

I know examples of people who added a new header about the same topic which
was discussed above, and then the two headers were merged into one. Or the
order of the messages being changed. To split up a topic into two topics to
keep the subject on topic. Rearranging large topics by adding 3rd and 4th
degree headers in what messages are grouped. These changes are now used to
keep the overview over an topic.

But hiding a complete message while only a very small part, usually one or
two words, is requested to be hidden, is unbalanced.



> > If a template is changed, its parameters on the various places where the
> > template is added need to be changed as well. This is done by hand or
> with
> > a bot (like AWB), both ways seems impossible with flow.
>
> Flow doesn't automatically update template output -- it retains the
> output as it was when the user posted the comment. We can argue
> whether that's good or bad behavior, but it's worth doing so in the
> context of real examples. When would this cause problems?
>
> Contrary to some descriptions, it's not quite the same as {{subst}}ing
> the template. You can still get back to the wikitext used produce the
> output, and change it, and potentially re-parse it. It just doesn't do
> so automatically (which is also not an inherent limitation).
>

Interesting way of handling templates. I need to think of what consequences
that would have, how it influences the way of using talk pages.

One question that already comes in my mind is what happens when in one
message a template is added, the template got deleted and later the user
who posted the original message wants to change the text. Will the template
stay look the same as the original post or will it be updated with saving
the change? (Sorry, I have not tested this yet.)


> > If someone added a message to the wrong page, it is relocated to another
> > talk page. Seems impossible to do here. If a message is considered to be
> > inappropriate for a certain page, it is relocated, seems impossible with
> > Flow.
>
> It doesn't support any kind of moving yet, that's still (like many
> features) to be developed, but unlike talk pages, it's architecturally
> viable to move a whole thread and its history, rather than copying and
> pasting content around, losing history, as we currently do routinely.
>

Good to read that it is something which is already thought of.
I think it is considered more important to have the possibility to move a
text (with a link to the source page for the history) than having the
history with it. But I think it can be an improvement if moving is possible
with history.


> > Another thing I noticed is that I can't get a complete overview of all
> > messages added to a certain talk page. After 10 messages, everything is
> > hidden. A quick ctrl + F is impossible. When I know there was a
> discussion
> > about a specific thing, I want to check the talk page easily by searching
> > it completely, not possible. It is very annoying that I can't get a
> > complete overview of all messages on a talk page, this is a basic need!
>
> Of course, which is why it's a high priority feature.
>

Good to know.


> > To answer the question, To Flow or not to Flow, it does not flow. I am
> not
> > able to do simple edits which are done every day.
>
> It's a system in early development, and has never been advertised as
> anything else. To draw conclusions about what it can and cannot do is,
> by definition, premature. A much more useful discussion is whether a
> system like it (provided some of its properties are clarified and
> improved) is desirable, and if not, what alternative ways there are to
> make talk pages more user-friendly, and what the limitations of those
> methods are. Also, to the extent that there are aspects of the Flow
> architecture that really are dealbreakers, we should fix them now.
>

Someone (a user) gave me today another impression, it is good you tell me
this so I can correct that.


> As I wrote to Risker, I think it's worth considering spending some
> development time on turning something like the Teahouse gadget (which
> allows one click insertion of replies on the Teahouse Q/A page) into a
> Beta Feature after some further improvement, to see just how useful it
> could be for the common case. If there's an 80/20 rule and in 20% of
> cases it just gives up and edits the section, that might still be a
> time-saver and convenience. There might even be other relevant gadgets
> already in some languages/projects -- worth a closer look, for sure.
>
> Flow is a long term bet that an architecture of tructured comments
> will ultimately have fewer hard and fast limitations on how
> collaboration in wikis can work, and will accrue usability benefits
> very quickly (as it already has done, like faster posting and replies)
> due to its architecture. So far we've only invested in the long term
> bet -- some rebalancing of effort towards the short term may be
> valuable, and may lead to interim milestones that impact users today
> rather than years from now. I can't answer when you'd hit the
> boundaries of what you can do with the free form text on talk pages
> today, but I don't think anyone's really tried yet. (Magnus, I am
> sending brain waves in your direction! ;-)
>

I do hope that the performance for end users will be kept taken care of and
that it stays very quickly.

I think I have a good change to use the maximum of talk pages.
As my talk page is often used as some sort of help desk and to-do list in
one, I archive parts of it after checking if I have completed the subject,
done the request, solved the issue, etc. I do not automatically archive but
do archive manual after checking if the message is no longer needed.

In Flow I miss the option to copy the source code, even if it was only a
part, to quote someone including the wikisyntax that user added.

I must say, I like the the situation of the VisualEditor. It is there very
easy to edit, but if you need you can still access and edit the source
code. I can understand that viewing a complete talk page in source code
modus is not possible, but for topics such should be possible I think.

Thanks for the answers and explanations.

Romaine


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

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

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

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

_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
Re: [Wikimedia-l] To Flow or not to Flow -> it does not flow [ In reply to ]
rik, I appreciate your engaging with this *early* enough for design
decisions to be adjusted before Flow gets to major rollouts.

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

Pine


On Sat, Sep 6, 2014 at 5:01 PM, Erik Moeller <erik@wikimedia.org> wrote:

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

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


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

--
Keegan Peterzell
Community Liaison, Product
Wikimedia Foundation
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
Re: [Wikimedia-l] To Flow or not to Flow -> it does not flow [ In reply to ]
On Sat, Sep 6, 2014 at 10:27 PM, Keegan Peterzell <kpeterzell@wikimedia.org>
wrote:

> ..last July...
>

July 2013, for clarity.

--
Keegan Peterzell
Community Liaison, Product
Wikimedia Foundation
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
Re: [Wikimedia-l] To Flow or not to Flow -> it does not flow [ In reply to ]
Erik Möller wrote:

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

======

*This statement is simply not true.*

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

Page 20 (DIRECT QUOTE FOLLOWS):

*FLOW*

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

*Key Milestones*

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

(END QUOTE)


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

Tim Davenport
"Carrite" on En-WP /// "Randy from Boise" on WPO
Corvallis, OR (USA)
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
Re: [Wikimedia-l] To Flow or not to Flow -> it does not flow [ In reply to ]
Tim, I read that a bit differently.

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

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

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

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

Pine


On Sat, Sep 6, 2014 at 8:34 PM, Tim Davenport <shoehutch@gmail.com> wrote:

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

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

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

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

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

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

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

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

Erik

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

_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
Re: [Wikimedia-l] To Flow or not to Flow -> it does not flow [ In reply to ]
On Mon, Sep 8, 2014 at 6:47 PM, Erik Moeller <erik@wikimedia.org> wrote:

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

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


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

_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
Re: [Wikimedia-l] To Flow or not to Flow -> it does not flow [ In reply to ]
On Sat, Sep 6, 2014 at 6:33 PM, Erik Moeller <erik@wikimedia.org> wrote:

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

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

Two less dramatic ways to test such a bet:

1. Experiment with annotation and inline comments

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

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

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

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

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

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

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