Mailing List Archive

[Wikimedia-l] To Flow or not to Flow
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>
Re: [Wikimedia-l] To Flow or not to Flow [ In reply to ]
On Fri, Sep 5, 2014 at 9:49 PM, Erik Moeller <erik@wikimedia.org> wrote:

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


I think there's actually a much more fundamental question:

Who is "we"?

-Pete
[[User:Peteforsyth]]
_______________________________________________
Wikimedia-l mailing list, 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,
"We" includes anyone who wants to be involved and does not exclude him or
herself by his or her own actions or choices.
Thanks,
GerardM


On 6 September 2014 07:09, Pete Forsyth <peteforsyth@gmail.com> wrote:

> On Fri, Sep 5, 2014 at 9:49 PM, Erik Moeller <erik@wikimedia.org> wrote:
>
> > 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 <snip>
>
>
> I think there's actually a much more fundamental question:
>
> Who is "we"?
>
> -Pete
> [[User:Peteforsyth]]
> _______________________________________________
> Wikimedia-l mailing list, 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 ]
Hi Erik,

While I have a lot of reservations about the usefulness of the Media
Viewer, I agree with you that talk pages are now inefficient for all
and complex for new users. Personally I am willing to try any system
which offers the features missing in the current talk pages, specially
removing the need for manual signatures.

Regards,

Yann


2014-09-06 10:19 GMT+05:30 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 [ In reply to ]
On 6 September 2014 07:11, Gerard Meijssen <gerard.meijssen@gmail.com> wrote:
> Hoi,
> "We" includes anyone who wants to be involved and does not exclude him or
> herself by his or her own actions or choices.
> Thanks,
> GerardM

Incorrect.

Erik's email includes phrases like "We're not pushing an aggressive
schedule on Flow". This clearly means that "we" refers to the
Wikimedia Foundation and excludes unpaid volunteers who hold no
responsibility or authority for the deployment schedule.

Fae
--
faewik@gmail.com https://commons.wikimedia.org/wiki/User:Fae

_______________________________________________
Wikimedia-l mailing list, 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 Saturday, September 6, 2014, Erik Moeller <erik@wikimedia.org> wrote:

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


What about setting up some kind of Flow self-service for projects? Let play
to those wiling to play, in the way they think it's best for their projects.

Potential requirements to join the Flow self-service:

* At least one tech ambassador volunteering to act as contact between the
project and the Flow team, summarizing community feedback in the channels
agreed (mw:Talk:Flow, etc).
* Community agreement after a public discussion in the project.
* Selection of a first page to try Flow.

When the requirements are met, Flow is enabled in that project and
activated in that page. A month of trial follows, and after that the
community must evaluate whether it is worth activating Flow in more pages
or wait. Maybe at some point the admins of the project can control in which
pages Flow is deployed?

While we (Wikimedia movement) dedicate so much time to negotiate
incremental deployments of Flow in some sensitive and tough arenas, maybe
there are huge regions in our communities where editors would welcome a
test of this feature. The feedback of these early adopters would help
fine-tuning Flow and to better define the development priorities, since
longer term use of regular editors provides a more complete perspective
than power users in mediawiki.org alone.


--
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
_______________________________________________
Wikimedia-l mailing list, 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 6 September 2014 05:49, Erik Moeller <erik@wikimedia.org> wrote:

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

I rather think the more fundamental question is (for any software
solution) "does this tool enable us to build the encyclopedia, better
than its predecessor?".

> - Update author names after a username change without having to update documents

So if I say in a discussion in which you participated, much earlier,
"I agree with what Eloqeunce said", and you subsequently change your
user name to ErikM, my comment would be made nonsensical?

--
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

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

That seems a sensible plan. I am thinking of the help desk on Commons
(in English or in another language) as a good testbed.

Regards,

Yann

2014-09-06 17:09 GMT+05:30 Quim Gil <qgil@wikimedia.org>:
> On Saturday, September 6, 2014, Erik Moeller <erik@wikimedia.org> wrote:
>
>> 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.
>
>
> What about setting up some kind of Flow self-service for projects? Let play
> to those wiling to play, in the way they think it's best for their projects.
>
> Potential requirements to join the Flow self-service:
>
> * At least one tech ambassador volunteering to act as contact between the
> project and the Flow team, summarizing community feedback in the channels
> agreed (mw:Talk:Flow, etc).
> * Community agreement after a public discussion in the project.
> * Selection of a first page to try Flow.
>
> When the requirements are met, Flow is enabled in that project and
> activated in that page. A month of trial follows, and after that the
> community must evaluate whether it is worth activating Flow in more pages
> or wait. Maybe at some point the admins of the project can control in which
> pages Flow is deployed?
>
> While we (Wikimedia movement) dedicate so much time to negotiate
> incremental deployments of Flow in some sensitive and tough arenas, maybe
> there are huge regions in our communities where editors would welcome a
> test of this feature. The feedback of these early adopters would help
> fine-tuning Flow and to better define the development priorities, since
> longer term use of regular editors provides a more complete perspective
> than power users in mediawiki.org alone.
>
>
> --
> Quim Gil
> Engineering Community Manager @ Wikimedia Foundation
> http://www.mediawiki.org/wiki/User:Qgil
> _______________________________________________
> Wikimedia-l mailing list, 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 Sat, Sep 6, 2014 at 9:50 AM, Fæ <faewik@gmail.com> wrote:

> On 6 September 2014 07:11, Gerard Meijssen <gerard.meijssen@gmail.com>
> wrote:
> > Hoi,
> > "We" includes anyone who wants to be involved and does not exclude him or
> > herself by his or her own actions or choices.
> > Thanks,
> > GerardM
>
> Incorrect.
>
> Erik's email includes phrases like "We're not pushing an aggressive
> schedule on Flow". This clearly means that "we" refers to the
> Wikimedia Foundation and excludes unpaid volunteers who hold no
> responsibility or authority for the deployment schedule.
>

Incorrect.

In such a long text, "we" can obviously refer to both "the Foundation" and
"the community" (both of which Erik is a member of), depending on context.
There would be little point in Erik asking "Do we want discussions to occur
in document mode, or in a structured comment mode?" on a public mailing
list, when he just wants to ask a Foundation-internal question, right?
Pretty obvious, really, unless your goal is to distract from the actual
topic.
_______________________________________________
Wikimedia-l mailing list, 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 ]
Refer to the signature Erik used. The rationale that employees when acting
as employees somehow are to be wearing a hat of an unpaid volunteer was
worn out when superprotect was invented.
On 6 Sep 2014 14:22, "Magnus Manske" <magnusmanske@googlemail.com> wrote:

> On Sat, Sep 6, 2014 at 9:50 AM, Fæ <faewik@gmail.com> wrote:
>
> > On 6 September 2014 07:11, Gerard Meijssen <gerard.meijssen@gmail.com>
> > wrote:
> > > Hoi,
> > > "We" includes anyone who wants to be involved and does not exclude him
> or
> > > herself by his or her own actions or choices.
> > > Thanks,
> > > GerardM
> >
> > Incorrect.
> >
> > Erik's email includes phrases like "We're not pushing an aggressive
> > schedule on Flow". This clearly means that "we" refers to the
> > Wikimedia Foundation and excludes unpaid volunteers who hold no
> > responsibility or authority for the deployment schedule.
> >
>
> Incorrect.
>
> In such a long text, "we" can obviously refer to both "the Foundation" and
> "the community" (both of which Erik is a member of), depending on context.
> There would be little point in Erik asking "Do we want discussions to occur
> in document mode, or in a structured comment mode?" on a public mailing
> list, when he just wants to ask a Foundation-internal question, right?
> Pretty obvious, really, unless your goal is to distract from the actual
> topic.
> _______________________________________________
> Wikimedia-l mailing list, 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 06.09.2014 13:39, Quim Gil wrote:
> On Saturday, September 6, 2014, Erik Moeller <erik@wikimedia.org>
> wrote:
>
>> 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.
>
>
> What about setting up some kind of Flow self-service for projects? Let
> play
> to those wiling to play, in the way they think it's best for their
> projects.
>
> Potential requirements to join the Flow self-service:
>
> * At least one tech ambassador volunteering to act as contact between
> the
> project and the Flow team, summarizing community feedback in the
> channels
> agreed (mw:Talk:Flow, etc).
> * Community agreement after a public discussion in the project.
> * Selection of a first page to try Flow.
>

Hi Quim,

actually, this is exactly what is happening now and this is what caused
this turmoil yesterday night.

FLOW was once deployed on two en.wp WikiProjects in the past,
Wikiroject:Breakfast and another one, i do not remember which on off the
top of my head. The Wikiproject participants agreed to use their talk
pages as a testbed, and it was announced reasonably broadly. Volunteers,
including me, tried installed FLOW and discovered that it is substandard
and can not be used for any reasonable discussion. The test was
terminated, some feedback was generated, some of it was taken onboard,
the rest presumably not.

Yesterday, we discovered that FLOW was installed as a test in the
Teahouse, a place whose purpose is to welcome newbies. I am not using
the Teahouse, but the argument which I have heard was that FLOW was
installed on a page inaccessible from the main Teahouse page and thus
unlikely to be visited by newbies. Apparently, there was some discussion
in the Teahouse, and the consensus was that FOW should not be installed.
Since FLOW was installed clearly against the community will and since it
is clearly still substandard, we had to act somehow. Danny got a warning
at his talkage, the FLOW page was protected, and I had to send a message
here, which in the end of the day started this discussion.

This is not the way FLOW should be deployed.

To me, Wikidata deployment was an example of successful Wikimedia
project deployment which went relatively easily (even though there are
still users having a strong opinion against Wkidata). The reasons it
went so smoothly were that (i) it was clear what the end goal is, what
should happen at what stage, and what are the needed steps; (ii) there
were a large amount of volunteers and ambassadors from the first day
sharing the idea and helping to explain it and to fix the bugs; (iii)
Support was always and easily available, including Danny and Lydia, and
they were really willing to listen to us and to help us, not to impose
their vision.

I am afraid with Flow we are still not even at (i). Whereas after
Erik's message I understand what he wants in very general terms, the
implementation is completely open. In these terms, Facebook or PHP are
both FLOW. I guess we start from the concept, and the next step would be
for volunteers to instal Flow a their talk pages. If they can survive
for a couple of months, we can talk about it further.

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 [ In reply to ]
Quim Gil <qgil@wikimedia.org> wrote:


> Potential requirements to join the Flow self-service:
>
> * At least one tech ambassador volunteering to act as contact between the
> project and the Flow team, summarizing community feedback in the channels
> agreed (mw:Talk:Flow, etc).
> * Community agreement after a public discussion in the project.
> * Selection of a first page to try Flow.
>
> When the requirements are met, Flow is enabled in that project and
> activated in that page.
>

Thank you Quim!

Yes, I would like to have Flow enabled on a test page on Dutch Wikipedia.
To acquire community agreement I have started a topic in the village pump
of the Dutch Wikipedia [1]. Essentially I asked if there exist objections
against enabling Flow on a test page, and, if yes, what those objections
are.

Best regards,


Dedalus

[1]
https://nl.wikipedia.org/wiki/Wikipedia:De_kroeg#Aanvraag_testpagina_voor_Flow_op_de_Nederlandstalige_Wikipedia

[2]
https://upload.wikimedia.org/wikipedia/commons/c/c0/WMF_StrategicPlan2011_spreads.pdf
_______________________________________________
Wikimedia-l mailing list, 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 Sat, Sep 6, 2014 at 6:49 AM, Erik Moeller <erik@wikimedia.org> wrote:

> Hi all,
>
> <snip>
>
> 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>



This email almost exactly embodies what I mean when I say that we are told
not to worry, everything will be OK in the earlier stages of development,
when in the later stages near deployment we're being told that the feature
has been under development for months or even years, and only *now* we come
with all these demands.

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

I think a lot of reasons for the "document mode" commenting system got
missed. But there are very good reasons we must retain that.

One huge thing is that article talk pages are not only for discussions, but
also for metadata (article assessments, history, Wikiproject data, as
examples from the English Wikipedia). The top of the talk page also, on
many pages, serves notices and FAQs to new visitors to the talk page.

For reviews like that, it may be necessary to have wikitext act as
wikitext, another very significant concern. ("Your use of Template:Example
is what's causing the text formatting to break in that section, because it
does like this: (insert example). You should actually use
{{example|arg1|arg2}}.") In other cases, subpages or other pages need to be
transcluded in, and all the functions of the transcluded page must be
preserved. Discussion pages aren't -only- used for discussion.

I think there's a serious flaw in thinking with the current development
processes, that Wikipedia needs to be more like Facebook, or Instagram, or
Twitter to attract new users. Jan-Bart has even mentioned Quora at several
points. Quora is cool. I love Quora. But that's not Wikipedia, and it's not
what Wikipedia should aspire to. They're not a competitor. (For that
matter, there -are- no competitors, we give our "product" away for free,
not only to read but to repackage and reuse!)

Making the interface easier to use is fine, but never at the expense of
quality or flexibility. The second is the real sticking point here. We need
maximum flexibility to handle complex discussions and complex problems. We
may need some stuff at the top of the page, not left in "infinite scroll"
hell. (Infinite scroll has to be one of the worst, user-unfriendliest UI
ideas I've ever seen.) We need the ability to rapidly archive "forum" style
posts or stuff that's become unproductive, and we need -any- editor able to
do that, not just admins. Non-admin editors help out all the time in that
regard. We need the ability to have real archives; again, infinite scroll
with or without search is nowhere near a replacement for that. We need the
ability to easily wikilink to specific sections.

Adding some "rails" is fine, but never at the expense of the underlying
functionality. VE, once it works, is the model to look at there: It
supplements, not supplants, the existing functions. That will be a huge
step in the right direction, the problem there was not design but
execution. Once it works properly, that issue goes away.

With Flow, the issue is flawed design. Supplanting current talk page
functionality will not work. We need the flexibility of subpages and freely
editable documents. The only other option there would be to use
article-space subpages for that, and that would be messy and horribly
inefficient.

Facebook, Twitter, forums, etc., don't need that, but it cannot be
emphasized enough that we ***are not, and should not aspire to be or look
like, a social media site***. We handle complexity that sites designed
around "LOL OMGZ LOLCAT PIX!" do not need to handle.

The resistance you're seeing here is you're trying to take things right out
of someone's hand, while they shout "Hey, I was USING that, and this thing
you're trying to hand me won't do the same thing!". No amount of tweaks to
Flow will change that, unless you can somehow layer it onto existing talk
pages rather than replacing them. But any workable solution must retain
that backwards compatibility, as VE will.

Maybe Flow could see limited use in a few newbie help areas to aid them in
making the transition from reader to editor, but serious editors will by
and large not want it sitewide. Ease-of-use helpers will be much more
easily accepted, provided they're actually ready for wide scale use when
rolled out as site defaults and have easy opt outs. Why not, at the very
least, try the less radical change first and see how it works?

Todd


On Fri, Sep 5, 2014 at 10:49 PM, 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 ]
Since we already know two of the changes that will come from Flow, the end of signature personalisation and only three levels of talk indentation; Surely it makes sense for the WMF to put those to the community now and see if it can win consensus for those two changes?

On a less contentious note, has anyone costed how much cheaper than FLOW it would be to introduce auto sign on talk pages, with all new accounts opted in from the implementation date onwards and all new accounts opted out? We would need a button on the edit screen marked "sign my comment" so that people could uncheck an edit where they were adding a wiki project tag or fixing a typo in their post. But it would make things a lot easier for newbies. The indentation is relatively easy to pick up, but currently every welcome message has to introduce the concept of four tildas. It would be much easier and the site much more welcoming if that no longer had to be explained to newbies.

Regards

WereSpielChequers/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>
[Wikimedia-l] To Flow or not to Flow [ In reply to ]
(The self-service suggestion and the opinions below are mine, posted here
with the best of my community intentions.)

Hi Yaroslav,

On Saturday, September 6, 2014, Yaroslav M. Blanter <putevod@mccme.ru
<javascript:_e(%7B%7D,'cvml','putevod@mccme.ru');>> wrote:

> actually, this is exactly what is happening now and this is what caused
> this turmoil yesterday night.


The situation you describe and the hypothetical self-service process I
suggested are different.

I guess we start from the concept, and the next step would be for
> volunteers to instal Flow a their talk pages. If they can survive for a
> couple of months, we can talk about it further.
>

Discussing concepts is better done while trying prototypes, alphas, betas
(and we have been doing this for Flow for about a year now). For instance,
I believe mw:Winter is progressing in the way it is progressing thanks to a
good balance between conceptual discussions, prototyping iterations, and
actual testing. Flow itself is progressing well thanks to the limited
deployments in some real pages.

Allowing users to activate Flow in their Talk pages would fit in the
self-service idea. If the development team decides to open this
possibility, I will not hesitate in joining the trial.


--
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
_______________________________________________
Wikimedia-l mailing list, 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 Sat, Sep 6, 2014 at 8:03 AM, Todd Allen <toddmallen@gmail.com> wrote:
> Erik,
> One huge thing is that article talk pages are not only for discussions, but
> also for metadata (article assessments, history, Wikiproject data, as
> examples from the English Wikipedia). The top of the talk page also, on
> many pages, serves notices and FAQs to new visitors to the talk page.

Yes, this is supported in Flow through wiki-editable headers. These
are community-editable like a wiki page. LQT simply used the existing
talk page for this purpose and hooked into its history and
permissioning, while Flow manages them separately, and its history
features are still very rudimentary for that reason.

> For reviews like that, it may be necessary to have wikitext act as
> wikitext, another very significant concern. ("Your use of Template:Example
> is what's causing the text formatting to break in that section, because it
> does like this: (insert example). You should actually use
> {{example|arg1|arg2}}.")

There's nothing in Flow's design that makes this impossible. There are
some inconsistencies to work through due to the use of Parsoid's HTML
for comment storage, and some extensions that may just be
fundamentally incompatible with a comment-based approach in their
current form (e.g. page-level translation, etc).

> We need the ability to rapidly archive "forum" style
> posts or stuff that's become unproductive, and we need -any- editor able to
> do that, not just admins.

Flow has a few features relevant to this right now, all still experimental:

- You can hide a topic from view (collapses it, others can undo)
- You can summarize or "close" a topic (others can reopen, both
actions update the summary, close also collapses)
- You can edit a topic's title
- You can hide an individual comment (collapses it, others can undo)

In the current permission system (which is easy to change)
the only thing that is lightly restricted is editing other people's
comments.

The underlying reasoning here is to try to support patterns that exist
in our community, while discouraging problematic changes. Comments
that solely consist of personal attacks can still be collapsed by
anyone, editing is discouraged except in special circumstances (and
hence restricted to admins); users don't have to monitor their own
comments for inappropriate edits.

Whether that's correct or not, I personally don't have a strong
opinion on. In LQT, we left comments openly editable, and I never
observed a problem with it; I think the arguments on both sides of
this issue are a bit out of proportion.

Back in 2004 I tried a little experiment by creating
https://en.wikipedia.org/wiki/User:Eloquence/Comment_policy and adding
it to my signature, to see if a subtle indicator would have more
people actually do anything interesting with my comments. It never
did. A year before I also tried to introduce a policy called "Remove
personal attacks" on en.wp:
https://en.wikipedia.org/w/index.php?title=Wikipedia:Remove_personal_attacks&oldid=1622559

This was hotly debated, and when/where to edit other people's comments
is actually still somewhat ambiguous in policies across wikis. English
Wikipedia acknowledges: "There is no official policy regarding when or
whether most personal attacks should be removed, although it has been
a topic of substantial debate. "

Just yesterday, as I was talking with Fram on Danny's talk page about
his .. slight escalation, another user popped in striking out Fram's
comments, then another user reverted that, ... so, there's a fair bit
of potential for conflict in this, which we do see a little bit of
every day.

German Wikipedia more explicitly encourages anyone to remove attacks
except people who are the subject of them, but cautions that users who
are subject of personal attacks should be careful, because it can
exacerbate a conflict. It then proceeds to explain that administrators
are encouraged to completely delete personal attacks using revision
deletion.
https://de.wikipedia.org/wiki/Wikipedia:Keine_pers%C3%B6nlichen_Angriffe

I think the strongest argument to keep comments openly editable, at
least initially, is that it's most consistent with policies as
currently written (most policies I've seen generally discourage
editing other people's comments, but have a few exceptions like the
one above). If, after much debate, communities want to adopt different
policies, then Flow's permissioning could be changed to reflect them.
Keeping the "Hide" type functionality in place for now would be a good
way to play with alternatives without immediately limiting options.

> We need the ability to have real archives; again, infinite scroll
> with or without search is nowhere near a replacement for that.

100% agreed. But with actual metadata for comments that's structured
and searchable, you can build much better search features -- search by
author, by date range, or even categorize/tag individual threads.
Archives in a well-built discussion system can be much more useful
than the current system of copying text around.

> We need the
> ability to easily wikilink to specific sections.

Again, none of that is limited by the architecture. Right now you can -
- wikilink to a Flow board ([[Talk:Flow]])
- wikilink to a topic on a board ([[Topic:Some id|Some title]])
- URL-link to a specific version of that topic

The history features are pretty rudimentary right now, as noted above;
that's mostly because the project (as noted in the original message)
decided to get rid of LQT's tie-in into the page architecture of
MediaWiki. That's an expensive decision, because by treating comments
as pages, you get a lot of stuff for free -- but it's motivated by a
desire to build UIs and an overall storage and retrieval architecture
that really make sense for a discussion system, rather than a document
mode system. So give them time to build out the scaffolding.

> With Flow, the issue is flawed design. Supplanting current talk page
> functionality will not work. We need the flexibility of subpages and freely
> editable documents.

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

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

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

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

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

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

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

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

I hope you give consideration to this argument before dismissing it as
inconsequential. So far it seems that the decision has already been made
and that your question ("Do we want discussions to occur in document mode, or
in a structured comment mode?") is rhetorical. I hope that this happens not
to be true, and the decision is still open to debate from the community.
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
Re: [Wikimedia-l] To Flow or not to Flow [ In reply to ]
Hoi,
As it is the current talk pages are horrible. You gloss over this fact
because you are so fired up about the potential of "end users can
build new features and flows on top of it, without the need to request
the platform
developers to build support for them". Then you attack flow because some
specifications are not there yet. In a previous mail it was said that much
of the UI is very much under development, any discussion is to be taken
with a table spoon of salt.

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


On 7 September 2014 07:57, Diego Moya <dialmove@gmail.com> wrote:

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

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

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

,Wil

_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
Re: [Wikimedia-l] To Flow or not to Flow [ In reply to ]
Hoi,
The central point Diego made starts from is that the current broken system
has a POTENTIAL for unstructured, unaccountable changes by whomever.

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

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


On 7 September 2014 09:55, Wil Sinclair <wllm@wllm.com> wrote:

> > Your suggestion is to be dismissed with prejudice because it is so
> > obviously wrong in so many ways.. I do not care about a possible
> potential
> > of a broken system at all I may want to think about features that are
> > actively used in this broken system.
> > Thanks,
> > GerardM
>
> I won't be dismissing it, because Diego makes some very good points
> and articulates the concerns that many in the community have expressed
> well.
>
> Dismissing his ideas won't make them go away. I just hope that
> dismissing them with that prejudice you mentioned doesn't make him go
> away.
>
> ,Wil
>
> _______________________________________________
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:wikimedia-l-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 ]
Gerard, with all due respect, your reply is all based on incorrect
assumptions. I recognize the severe problems that mediawiki conversations
currently have, and my points about Flow acknowledge that it's incomplete
software at its early stages and that it can grow into an acceptable tool
for having discussions, but all that is irrelevant to the conversation
that's going on at this thread.

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

Erik has this vision that building a stable and easy-to-use system requires
abandoning the open-ended nature of wiki systems, with which I disagree,
and has committed us to a project with that result in the end, to build a
very good architecture that will solve the wrong problem. From the
conversation so far, I believe such view to be based on an incomplete
understanding of the community needs, and I'm trying to steer the
conversation to take into account perspectives from the wider community
rather than the gut feelings of just one man, no matter how much experience
he has with the project.
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
Re: [Wikimedia-l] To Flow or not to Flow [ In reply to ]
Hoi,
It is fine to disagree. What is lacking in your vision is a viable
alternative and, as you acknowledge the current system is no longer viable
we are in need of an alternative now. Your notions are yours and that is
fine. However, we are not a debating club really. My point is very much
that in Flow we have a project that is actively developed. It is based on
the lessons learned with the current talk pages and Liquid Threads. The
process of development includes community consultation and it has a chance
of delivering something viable in the near future.

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

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


On 7 September 2014 11:14, Diego Moya <dialmove@gmail.com> wrote:

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

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

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

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

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



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

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

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

Please assume good faith and try to listen to what people who care deeply
about the project have to say. I believe that the end result of building an
understanding, from the very different starting points that are held by the
debaters, will benefit the project deeply and will allow for a much more
robust tool that any other way to proceed.
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
Re: [Wikimedia-l] To Flow or not to Flow [ In reply to ]
...and having said and sent that previous post, I want to publicly
apologize for the third paragraph counting from the end. That was uncalled
for.
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>

1 2 3 4 5  View All