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 <e...@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-requ...@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-requ...@lists.wikimedia.org?subject=unsubscribe>
