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(a)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(a)lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
Hi,
I am not a mobile user. So for the first time, I used the Mobile App
on a Samsung S4 to upload a few pictures. I am quite disappointed, to
say the least. I stopped counting how many times the application
crashed while uploading just a few pictures. Then in reviewing my
uploads, I can't see the description or the license, the field is
blank. Then I discovered that the Application does not check if the
name already exists, and uploads over the old file without warning.
Luckily I didn't upload over someone else files. Then the categories I
choose were not included, and also no warning there. It is a bit less
bad on a tablet, where I can read the description and the license, but
I can't add any category. I wonder how a software in such a bad
condition gets deployed... Now it is much easier than on the desktop,
and I understand why we get so many useless pictures from mobile
uploads.
https://commons.wikimedia.org/wiki/Commons_talk:Mobile_app#Feedback_on_Andr…
Regards,
Yann
Heh. That was not my first time when I started typing my email address and
instead Gmail autofilled wikimedia-l. This is what I get for choosing
wiki.pine instead of pine.wiki. I need some coffee or more sleep.
Anyway, this is what was supposed to go to Wikimedia-l:
Do we have a central place for collecting ideas relevant to the strategic
plan update? I suppose we could use Idealab but a dedicated space on Meta
might be easier for everyone in the long run, or we could re-open the
Strategy wiki.
Thanks,
Pine
Hi Nasir,
We've heard this from one other user, but have been unable to reproduce the
bug so far. I'm going to connect you to the team so we can trouble-shoot
off-list. Thanks for testing!
Siko
>
> ------------------------------
>
> Message: 3
> Date: Tue, 9 Sep 2014 23:06:31 +0600
> From: Nasir Khan <nasir8891(a)gmail.com>
> To: Wikimedia Mailing List <wikimedia-l(a)lists.wikimedia.org>
> Subject: Re: [Wikimedia-l] Open call for Individual Engagement Grant
> proposals
> Message-ID:
> <CAP+9T6Sojneb496G6gp8BM_EwJ2s-BiTeL+TnCjp=HG_m0F=
> 6g(a)mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Dear Siko,
>
> "Create a new idea" button is not working in the
> https://meta.wikimedia.org/wiki/Grants:IdeaLab/Ideas page and "Try a new
> tool to create your proposal" button in the
> https://meta.wikimedia.org/wiki/Grants:IEG page.
>
> I faced this form the Firefox and Chrome browser in Windows 8. is it only
> me who is facing this issue?
>
>
>
> --
> *Nasir Khan Saikat*
> www.nasirkhn.com
>
>
> On Tue, Sep 2, 2014 at 11:26 PM, Siko Bouterse <sbouterse(a)wikimedia.org>
> wrote:
>
> > Greetings! The Wikimedia Foundation Individual Engagement Grants program
> is
> > accepting proposals for funding new experiments from September 1st to
> 30th.
> > <https://meta.wikimedia.org/wiki/Grants:IEG>
> >
> > Your idea can improve Wikimedia projects by building a new tool or
> gadget,
> > organizing a better process on your wiki, conducting research on an
> > important issue, or providing other support for community-building.
> Whether
> > you need $200 or $30,000 USD, Individual Engagement Grants can cover your
> > own project development time in addition to funding for a team to help
> you.
> > The program has a flexible schedule and reporting structure, and
> > Grantmaking staff are there to support you through all stages of the
> > process.
> >
> > Do you have have a good idea, but you are worried that it isn't developed
> > enough for a grant? Put it into the IdeaLab, where volunteers and staff
> > can give you advice and guidance on how to bring it to life. <
> > https://meta.wikimedia.org/wiki/Grants:IdeaLab> Also, IEG will be
> hosting
> > three Hangout Sessions for real-time discussions to help you make your
> > proposal better - the first will happen on September 16th. <
> > https://meta.wikimedia.org/wiki/Grants:IdeaLab/Events#Upcoming_events>
> >
> > For inspiration, you can read more about past projects <
> > https://blog.wikimedia.org/tag/individual-engagement-grants/> that
> > received
> > funding or review open proposals <
> > https://meta.wikimedia.org/wiki/Grants:IEG#ieg-reviewing>. We are
> excited
> > to see some of the new ways your grant ideas can support our community
> and
> > make an impact on the future of Wikimedia projects.
> >
> > Submit your proposal in September! <
> > https://meta.wikimedia.org/wiki/Grants:IEG#ieg-apply>
> >
> > Warm regards,
> > Siko
> >
> > --
> > Siko Bouterse
> > Head of Individual Grants
> > Wikimedia Foundation, Inc.
> >
> > sbouterse(a)wikimedia.org
> >
> > *Imagine a world in which every single human being can freely share in
> the
> > sum of all knowledge. *
> > *Donate <https://donate.wikimedia.org> or click the "edit" button today,
> > and help us make it a reality!*
> > _______________________________________________
> > Wikimedia-l mailing list, guidelines at:
> > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> > Wikimedia-l(a)lists.wikimedia.org
> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
>
>
>
--
Siko Bouterse
Wikimedia Foundation, Inc.
sbouterse(a)wikimedia.org
*Imagine a world in which every single human being can freely share in the
sum of all knowledge. *
*Donate <https://donate.wikimedia.org> or click the "edit" button today,
and help us make it a reality!*
Dear all,
The Individual Engagement Grants Committee is seeking new members. We are
diverse, consensus-based committee with members on five continents and a
variety of skills. As a group we speak 16 languages and have over 500,000
edits to a variety of Wikimedia sites. We review grant applications twice
per year in four categories: Research, Tools (usually software), Online
community organizing, and Offline outreach and partnerships.
Members may specialize in as few or as many areas as they wish.
We look for the following qualifications. This information is taken from
our Meta page.
Mandatory:
1. Experience with the Wikimedia movement and at least one Wikimedia
project
<https://meta.wikimedia.org/wiki/Special:MyLanguage/Wikimedia_projects>.
2. Experience with some aspect of Wikimedia programmatic or
project-based work, e.g. editor engagement, WikiProjects or other on-wiki
organizing processes, outreach, events, partnerships, research, education,
gadget or bot-building, etc.
3. Ability to edit basic wiki-markup (grant proposal discussions are
largely conducted on meta-wiki).
4. Reasonable facility with English, for reviewing and discussing grant
proposals.
5. In good community- and legal- standing (not currently blocked or
banned, involved in allegations of unethical financial behavior, etc).
6. Availability to actively engage in the selection process during the
published schedule for that round (time commitment is about 3 hours per
week, plus 1 extra day for scoring).
Preferable:
1. Experience leading, coordinating, or managing projects with an
intended on-wiki or online impact.
2. Experience handling externally provided money and working within
budgets, preferably in a non-profit context.
3. Experience applying for grants or working in grants programs (in the
Wikimedia, academic, or wider non-profit world).
4. Ability to read and write in multiple languages.
Acceptable:
1. Members may apply for an Individual Engagement Grant themselves, but
they will recuse themselves from reviewing proposals in the same category
as their own during that round.
2. Membership does not conflict with membership in other Wikimedia
committees, including the Grant Advisory Committee
<https://meta.wikimedia.org/wiki/Special:MyLanguage/Grants:PEG/Grant_Advisor…>
or the Wikimania Scholarships Committee.
Please apply at
https://meta.wikimedia.org/wiki/Grants:IEG/Committee#ieg-candidates. The
close of the application period is September 21. The Committee will review
the applications internally and announce new members by early October,
coinciding with the start of the public review period for new grant
proposals.
For the Committee,
Pine
Greetings! The Wikimedia Foundation Individual Engagement Grants program is
accepting proposals for funding new experiments from September 1st to 30th.
<https://meta.wikimedia.org/wiki/Grants:IEG>
Your idea can improve Wikimedia projects by building a new tool or gadget,
organizing a better process on your wiki, conducting research on an
important issue, or providing other support for community-building. Whether
you need $200 or $30,000 USD, Individual Engagement Grants can cover your
own project development time in addition to funding for a team to help you.
The program has a flexible schedule and reporting structure, and
Grantmaking staff are there to support you through all stages of the
process.
Do you have have a good idea, but you are worried that it isn’t developed
enough for a grant? Put it into the IdeaLab, where volunteers and staff
can give you advice and guidance on how to bring it to life. <
https://meta.wikimedia.org/wiki/Grants:IdeaLab> Also, IEG will be hosting
three Hangout Sessions for real-time discussions to help you make your
proposal better - the first will happen on September 16th. <
https://meta.wikimedia.org/wiki/Grants:IdeaLab/Events#Upcoming_events>
For inspiration, you can read more about past projects <
https://blog.wikimedia.org/tag/individual-engagement-grants/> that received
funding or review open proposals <
https://meta.wikimedia.org/wiki/Grants:IEG#ieg-reviewing>. We are excited
to see some of the new ways your grant ideas can support our community and
make an impact on the future of Wikimedia projects.
Submit your proposal in September! <
https://meta.wikimedia.org/wiki/Grants:IEG#ieg-apply>
Warm regards,
Siko
--
Siko Bouterse
Head of Individual Grants
Wikimedia Foundation, Inc.
sbouterse(a)wikimedia.org
*Imagine a world in which every single human being can freely share in the
sum of all knowledge. *
*Donate <https://donate.wikimedia.org> or click the "edit" button today,
and help us make it a reality!*
Responding to two comments. Firstly Risker " Newbies have an equally hard time
>
> editing content, too, and even when they succeed, on many projects they're
> very likely to be reverted and deluged with templated messages in response
> to a good faith attempt. There is no evidentiary basis to demonstrate that
> new users have a harder time participating in discussion than they do in
> content contribution."
I would go further, reverting newbie edits to talk pages is rare. They may occasionally need help with indentation or signing, and if they edit a busy page they may get edit conflicts. But unlike in main space actual reversion is rare. We do need some system to identify newbie queries that have been left longest, as queries on article talk pages can linger for a very long time. But we should not treat the need for improvements on talk pages as being as pressing as the need to improve the experience for newbies in main space. V/E will help a little there, though not till it is ready to be deployed. But there are bigger problems, the amount of edit conflicts suffered by the creators of new articles and the ongoing train wreck with some of the regulars working to the unwritten rule that everything must be verified, while the system doesn't even prompt newbies to add a source.
Re Erik's comment "I'm open to us putting some short term effort into talk
>
>> page improvements that can be made without Flow -- knowing it's still
>> some time out."
That would be great, there are various Won't fix bugs on Bugzilla that should be easy to fix. Setting : # and * as paragraph delimiters as far as edit conflicts are concerned should resolve a lot of the edit conflicts in talk space. Really low hanging fruit.
Regards
Jonathan Cardy
>
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
[x-posted]
Hello,
The next monthly IRC office hour of the Wikimedia Language Engineering
team will be on Wednesday, September 10, 2014 at 1700 UTC on
#wikimedia-office.
We will be taking questions and discussing about our ongoing work,
particularly around the Content Translation project[1], and upcoming
plans.
Please see below for event details and local time. See you there.
Thanks
Runa
[1] https://www.mediawiki.org/wiki/Content_translation
Monthly IRC Office Hour:
===================
# Date: September 10, 2014 (Wednesday)
# Time: 1700 UTC/1000PDT (Check local time:
http://www.timeanddate.com/worldclock/fixedtime.html?iso=20140910T1700)
# IRC channel: #wikimedia-office
# Agenda:
1. Content Translation project updates and plans
2. Q & A (Questions can be sent to me ahead of the event)
--
Language Engineering - Outreach and QA Coordinator
Wikimedia Foundation
Where does the idea that user interface changes to the system which
has already produced the most monumental reference work in the history
of humanity are going to help with its only actual problem, that
people aren't sufficiently inclined to stick around and maintain it?
If there was any evidence that VE or Media Viewer or Flow will make
the projects more attractive to volunteers, I'm sure we would have
heard it by now. But there isn't. Nor is there any evidence that any
of the several Editor Engagement projects have made a dent in
volunteer attrition rates, despite their success in encouraging tiny
subsets of very new editors to contribute a few minutes more work.
The present set of dramatic distractions from attention to the
vanishing volunteer corps only highlights that Foundation leadership
has no ability to focus on the only strategic goal they haven't
achieved: retaining volunteers. Because it is so much easier to
pretend that readers need WYSIWYG or a lightbox or can't figure out
how to indent replies; since readership numbers aren't an actual
problem (when mobile users are added to desktop pageviews) this
guarantees the false appearance of success in the eyes of everyone who
doesn't see through the transparent cop-out. Where is the evidence
that the status quo user interface from 2005 would not have done just
as well in every measurable aspect of movement success?
Steven Walling wrote:
>...
> We practically can't and don't take on initiatives that directly
> try to provide more free time or money to editors....
That is absolutely false. Individual Engagement Grants have recently
been proven to be substantially more cost-effective in achieving the
Foundation's stated goals than any other form of grant spending, on a
per-dollar basis. Is there any evidence that any Foundation
engineering effort of the past five years has done as well? I haven't
seen any.
When the Foundation spends on copyright advocacy, those initiatives
directly try to provide more economic empowerment to the small
fraction of contributors who stand to benefit from whatever additional
government documents or panorama images they hope to free up. But
volunteers who want to update information on the side effects of
commonly prescribed drugs get nothing.
When the Foundation spends on attempts to oppose the Trans Pacific
Partnership, those initiatives directly try to provide more free time
and money to the small subset of editors threatened by lengthening of
copyright terms. But editors who want to help translate introductory
material foundational to engineering skills literacy get nothing.
Who at the Foundation bears the responsibility for deciding which of
initiatives that might benefit the real needs of vanishing volunteers
are funded, and why aren't they held accountable for their record
since 2007?
