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