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

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.

On 09/07/2014 01:57 AM, Diego Moya wrote: the And yet, after over a decade of open-ended design through social convention, the end result is... our current talk pages. Perhaps another decade or two will be needed before that document-centric architecture gives us a half-decent discussion system? Sorry if that sound snarky, but I have difficulty buying an argument that the current system has the potential to suffice when it has demonstrably already failed. It does no good to have the hypothetical capacity for a good system if, in practice, it's unusable. -- Marc

On 09/07/2014 01:57 AM, Diego Moya wrote: the And yet, after over a decade of open-ended design through social convention, the end result is... our current talk pages. Perhaps another decade or two will be needed before that document-centric architecture gives us a half-decent discussion system?

Sorry if that sound snarky, but I have difficulty buying an argument that the current system has the potential to suffice when it has demonstrably already failed.

It does no good to have the hypothetical capacity for a good system if, in practice, it's unusable.

. e.g. once it is beta quality, I am sure Jimmy Wales will want it enabled on his user talk page, which would increase exposure to, and acceptance of, Flow.

On 8 September 2014 05:46, John Mark Vandenberg &lt;jayvdb(a)gmail.com&gt; wrote: This is the key point. Those of us who presently use talk pages to get the work done. What is going to make us *love* Flow, for all its imperfections, and demand to have it for ourselves? What's Flow's killer feature for us? (I asked this before.) - d. _______________________________________________ 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>

On 8 September 2014 05:46, John Mark Vandenberg &lt;jayvdb(a)gmail.com&gt; wrote: Those of us who presently use talk pages to get the work done. What is going to make us *love* Flow, for all its imperfections, and demand to have it for ourselves? What's Flow's killer feature for us?

(Wiki talk pages don't have a unit really, which is their blessing for flexibility and curse for usability.)

On Mon, Sep 8, 2014 at 12:22 AM, David Gerard &lt;dgerard(a)gmail.com&gt; wrote: First, on the subject of "kiler features", generally - we can make educated guesses, but with software that's used by communities, you really need to experiment and iterate. I'm sure we'll try stuff in Flow that doesn't make sense (and we've already talked here about aspects of the current design that may have to be changed, like the limited threading display), and I'm sure things we think are minor will become more popular than we expect. Generally, I'm not a big fan of maintaining illusions of certainty. I've argued against detailed year-long plans to Sue and the Board, as I'm sure they will attest, until we got the flexibility to set more malleable goals in engineering. Lila immediately came in with the expectation in mind that we'd have precision a quarter out, and broad high level ideas a year out, and need flexibility to change our mind as we learn. In tech work, you need to be able to double down on success when you hit it (make that killer feature _the_ feature), and kill the cruft that you thought was smart but that just doesn't work. With Echo, we included a bunch of notification types and didn't really know which ones people would love. We guessed that mentions would become popular, but their use has exceeded our wildest expectations. Go to any high traffic talk page and you'll see Echo pings all over the place. A feature that didn't exist before 2013 and that nobody, as far as I know, ever asked for (!) before we built it. And yet it's become indispensable. When we experimented with mobile contributions, our first hypothesis was that uploads would be a good start, because mobile isn't well-suited for long form edit contributions. In fact, mobile editing became wildly popular very quickly and has generally been embraced by the community (to the point where people ask us to enable IP editing on mobile, which we consciously did not do initially to lessen crappy edits), while the signal to noise ratio on uploads has been so poor that we're about to retire most upload features until we really can spend cycles on mitigating those risks. So, educated guesses and hypotheses. Flow makes lots of things possible that are otherwise hard/impossible (much better search, tracking of comments, etc.) but my hypothesis is that there are three primary killer features that Flow can provide: 1) Fast interactions. The process of responding on a talk page is ridiculously slow (edit section, find place, indent comment, write comment, sign comment, preview, save, worry about edit conflict ..). In my view, the reason people don't value this in Flow such-as-it-is already is primarily [[loss aversion]]. There's a large set of concerns that Flow makes existing things impossible (and yes, I'll respond a bit more to Diego) or harder. Losses are psychologically far more powerful than gains -- so any cool comment features that Flow _already has_ (fast and easy replies, no edit conflicts, etc) will not be perceived to be "killer features" unless/until the balance of perceived losses shrinks dramatically from what it is now. And it'll keep shrinking as we go. As pointed out, we can _try_ to make this work with sticks, spit and duct tape on top of wikitext, even in the odd cases of mixed markup for indentation, comments interrupted in the middle, outdent templates, etc. -- but it'll almost certainly just have to bail in some cases, and misidentify comment demarcations in others. I'd like to test those boundaries a bit more before making confident statements about how much of "fast interactions" we can deliver without Flow, however. Either way, it is IMO a clear killer feature that's badly needed. 2) Centralized conversation spaces. Flow's architecture is already cross-wiki; its UI is not. As pointed out, there are multiple cross-wiki discussions as well as mailing list discussions about this very topic. Wil suggested "Pick a conversation space and stick to it!". Well, wouldn't that be nice - if it worked in our universe. Except that we know it rarely does. People want to have discussions in their "home wiki", and we use mailing list threads like this for good reasons as well. You could participate in the same Flow conversation from en.wp, mediawiki.org and meta, without caring one way or another (SUL finalization being the main blocker to avoid account wonkiness). When/where that's desirable is something to negotiate -- but for example, feedback on features that are deployed across wikis is a perfect case for wanting to have local pages that feed into a single stream of comments. If you want to go nuts, you could build a Flow<->mailing list or Flow<->NNTP (oldschool!) gateway. If we do our API homework, I mean literally "you" because we're sure as hell not going to do it anytime soon ;-) Flow -theoretically- even could have language awareness of individual posts, enabling a single multilingual discussion space, easy translation of individual comments, etc. A team of Japanese researchers built something like this on top of LQT a few years ago, as a prototype: http://langrid.org/mwikidev/ (Guess why they didn't build it on old-school talk pages?) For a truly multilingual community, I think that could be a killer feature -- as opposed to just splitting the conversation spaces, as we do now. 3) Tags. The team hasn't decided if/how to implement tags yet. My own bet is that they could be a killer feature. Let people add/edit those right below the thread title with one click and see if they start using them. Say you want an article to be deleted. Start a thread with #afd tag, explain your rationale, you're done. Other users can pull up the recent #afd threads, sort by date, etc. Discussion can happen at the article level or from the tag page. Say you want to welcome new users. Leave a welcome note with #welcome tag. Other users can join in on the welcome and give tips/hints. Say you're a new user and you want to get help. Start a thread with #help tag and it'll show up on that board. Other users can provide help. (Yes, I know the {{helpme}} template which is sort of a very poor person's version of this.) Say you like a picture and you want to nominate it for FP status. Leave a note with #fpc and it'll get added to that feed. (Tags that are invoked from File talk: pages could dynamically include a thumb, so no need for extra logic to do that.) If people misuse tags, others will remove them. (And no, it doesn't have to be the hashtag syntax. It could work like categories, where tags could have pages describing them and their purpose -- I wouldn't recommend using actual categories, because the hierarchy is overkill.) You'd probably need a tiny bit more pixie dust for rich workflows, but I'm not quite sold on the idea of a workflow domain language or anything like that. I'd look for simple rules: Flow already has "closure" as a discussion property, so closed threads could be easily filtered. Setting a tag could generate a configurable notice on the subject page. Etc. Workflows built in wikitext are cool (I've built a few myself, and I only hate myself a little bit for it in the morning), but they're not the only way to build workflows. Tags, dynamic searches, pings, and similar mechanisms can help build and improve workflows, as well, potentially in a much more straightforward fashion. Flow can help us expand our toolset, and it's for us (the WMF-us) to prove that the balance of losses won't be too large in comparison to our (the Wikimedia-us) gains. But we (Wikimedia-we) need to do that cost accounting rationally, gently allowing reason, time, habit and adoption to act as a counter to the normal over-accouting of losses vs. gains. 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(a)lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>

* inter-wiki or intra-wiki integration of multiple-venue discussions rather than several parallel pages and potentially parallel discussions (not a very frequent issue, but a messy one when needed; Pine notes this below)

There have been proposals to use a right-hand bar to show information relevant to the content in view ("see related Wikidata item"; "articles on this subject in other languages use these images"; etc.); that could be a neat place to put relevant discussions' subjects/titles (or even the whole discussion). Alternatively, we could put little markers in a tray/gutter that users can click on to see more of, or put a highlighted ring around content subject to recent discussion when editors change it. There are lots of ways we could consider making a more powerful, more visible way to discuss content. Making these kind of tool available through VisualEditor would be pretty easy (though getting the design right for all our workflows would need some care, and as always the challenges of getting a reasonable, consistent design for phone, tablet and desktop platforms will need some thought). Doing it in the wikitext editor in a way that makes sense for users might be harder. However, "hard" is not a good enough excuse for us not tackling these kinds of big issues around making editing a simpler, more obvious experience that doesn't need people to have read the talk page and all its archives before making an edit. Does that sound like a useful change for experience editors? :-)

I think that would be very helpful indeed. "This part of the article was most recently discussed under subject "Stop changing the genre". Click here to review or participate in the discussion."

Eh. I'm not particularly interested in building features that only work in VE and not wikitext, and particularly not in ones that would require changing both the wikitext used to write talk pages for the benefit of VE users and disrupting wikitext. We can, and we must, do better than that. (But yes, I imagine the additional ease of VE here would be significant.)

On 10 September 2014 18:48, Todd Allen &lt;toddmallen(a)gmail.com&gt; wrote: James, this sort of thing will make experienced editors clamour for VE ;-) You should be able to do this with the present talk pages - annotate VE pages with a link to the discussion.

On 10 September 2014 07:54, Andrew Gray &lt;andrew.gray(a)dunelm.org.uk&gt; wrote: You know, Andrew, this was always something that I thought would be one of the real features of Flow, one of the things that could pull people over to supporting the transition. Until it got turned it on. I have 'watch-listed' the Flow-specific pages on Mediawikiwiki (MWW) and English Wikipedia for a very long time. When they turned on notifications at MWW about a week ago, my mailbox and notifications were flooded - I'm not talking just a little bit, I mean I got so many notifications that I couldn't sort out the ones that weren't related to that one specific Flow page - and that was with a single Flow stream being watched. I suppose I expected it to be like the email notices we get when a watched page gets edited on non-Wikipedia projects (e.g., Meta, MWW) - that is, the first change would generate an email/notification and nothing more until I went to the "page" itself. From what I've been told, this isn't something that Echo/notifications does or was meant to do. I know the Flow team is scrambling to try to reduce the overwhelming nature of the notifications. But it occurs to me that there was a reason why "email notification" was never turned on for Wikipedia projects - the sheer volume of messages that would be generated for users with hundreds or thousands of pages on their watchlists - and that's going to be just as much an issue for Flow as it would be if we just turned on those email messages today. Looks brilliant on paper, but reality is a different thing. Risker/Anne

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

On 10 September 2014 17:47, Martijn Hoekstra on The feature shouldn't be "notify on all posts on the subscribed thread" either. I don't want to be notified every time a new thread appears at any one of my watched pages.

However, it's hard to tell whether such suggestions ever reach the development team; it's clear that this one need didn't arrive in time to be taken into account before the release.

This is not testing, this was rolled out to the production environment.

The release has been interfering with the work of those editors who happen to have participated in any Flow page. This is more than an "oops", it's affecting the mission. Why is experimentation still being released to all editors, instead of limiting it to those willing to participate in it? _______________________________________________ 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>

On 10 September 2014 19:49, Martijn Hoekstra &lt;martijnhoekstra(a)gmail.com&gt; wrote: That doesn't make any difference, Martijn. I ''want'' to be subscribed to all the topics at my 3000 pages, I just don't want to get a notification for all them; I want to actively seek most of those at the watchlist in an opportunistic way.

Notifications from a few selected subset of pages would be a godsend; however, if it was deployed to all talk pages with the current design, I'd have to disable the category of notifications from conversations - it's simply too distracting. The "howler" notification widget (is that its name? I first heard it this week) draws all attention when it's activated, in particular with that bright red color; I want it to be activated only for things I deem important, so that I only have to evaluate it for things that require my immediate evaluation. If it gets triggered too often, it disrupts the attention I pay to my other main tasks. This distinction between actively seeking updates in the Watchlist and passive notification from Echo seems missing from the design, at least for events that are not alerts. Anything that can affect what an editor can see at en.wiki or any other community site without activating it at Preferences>Beta (that's the official channel for opting in to experimental features, right?) Yes, editors who subscribed to Wikiproject Breakfast and Wikiproject Hampshire have been receiving some strange, months-old notifications this week from those Flow pages. Danny had to step in at en:Talk:Flow and recommend that users disabled notifications from Flow to avoid problems. _______________________________________________ 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>

The feature shouldn't be "notify on all posts on the subscribed thread" either. I don't want to be notified every time a new thread appears at any one of my watched pages. I have about 3000 pages in my watchlist, and receive around 400 updates daily only from talk pages, which 50 or so come from unique pages; getting all those as notifications would render Echo useless to me. Apparently this volume of data was not taken into account when designing the notification feature that was rolled out this week, and it is still ignored in the redesign proposals that I've seen at the various forums.

On 8 September 2014 05:46, John Mark Vandenberg &lt;jayvdb(a)gmail.com&gt; wrote: This is the key point. Those of us who presently use talk pages to get the work done. What is going to make us *love* Flow, for all its imperfections, and demand to have it for ourselves? What's Flow's killer feature for us?

On 09/08/2014 12:46 AM, John Mark Vandenberg wrote: That's... not a demonstration of usability. Like many people, I found myself using some random blunt object not designed for purpose to hammer in a nail at least once; that speaks to the importance of getting the nail in, not the lack of need for a proper hammer. :-) Let's be honest here; I'm /highly/ computer-literate, and I've been using Mediawiki for some 11 years and I *still* find talk pages an annoyance at the best of times and they can be downright painful if there's anything like a large discussion in progress you are attempting to track/participate in. Between edit conflicts, increasingly confusing indentation, signatures that may or may not make separation between commenters clear... It's no surprise that newbies are scared away. Editing articles is already hard enough, anything that provides an extra barrier to participation hurts - especially when that barrier lies in the way of getting /help/. Talk pages, as a mechanism, are lacking every affordance that users expect of a communication medium. And no, that X thousand people have gotten used to their failings does not make them any better for the Y billion people that have not. But don't take my word for it! Find random newbies, and ask them to try the simple task of commenting on a discussion in progress without giving them guidance. They they flail around, or simply give up, remember that it's not /them/ who have failed -- I'm pretty sure they've participated in plenty of other online discussions before. -- Marc _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l(a)lists.wikimedia.org <https://meta.wikimedia.org/wiki/Mailing_lists/GuidelinesWikimedia-l@lists.wikimedia.org> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>

On 09/08/2014 10:18 AM, Risker wrote: I suppose that's a philosophical divergence between us then - that sinebot even needs to exist to me is demonstration that the system is broken. You say that discussion isn't all that much harder than editing content. Even if I agreed with that (and I do not, edit conflicts in articles are much rarer than on talk pages - and usually easier to sort out), that's not a *good* thing! Participating in discussion should be much, *much* easier than editing articles: encouraging newbies to seek help and participate in the community *before* diving in anything but trivial article edits would be an immensely powerful retention tool! (Which isn't to say that editing articles doesn't *also* need a lot of help - but that's a different project). -- Marc _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l(a)lists.wikimedia.org <https://meta.wikimedia.org/wiki/Mailing_lists/GuidelinesWikimedia-l@lists.wikimedia.org> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>

Hello, a) This discussion actually belongs to a talk page on Meta or Mediawiki.org, for example :-) b) All my experience in teaching Wikipedia tells me that the talk page system is absolutely outdated and inappropriate. It is, sorry to use this word, *ridiculous* that you have to teach people how to communicate technically in Wikipedia. I never had to explain to someone how to do that on Facebook... As other people have pointed it out already, if you are already accustomed to the Wikipedia user interface for a longer time, you might find it difficult to fully understand what is the problem for newbies. And how big this is a problem, and how important it is to solve this problem. Kind regards Ziko Am Montag, 8. September 2014 schrieb Risker : see depending so that content. be https://meta.wikimedia.org/wiki/Mailing_lists/GuidelinesWikimedia-l@lists.w… _______________________________________________ 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>

On 09/08/2014 10:18 AM, Risker wrote: I suppose that's a philosophical divergence between us then - that sinebot even needs to exist to me is demonstration that the system is broken. You say that discussion isn't all that much harder than editing content. Even if I agreed with that (and I do not, edit conflicts in articles are much rarer than on talk pages - and usually easier to sort out), that's not a *good* thing! Participating in discussion should be much, *much* easier than editing articles: encouraging newbies to seek help and participate in the community *before* diving in anything but trivial article edits would be an immensely powerful retention tool! (Which isn't to say that editing articles doesn't *also* need a lot of help - but that's a different project). -- Marc _______________________________________________ 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>

On Tue, Sep 9, 2014 at 10:04 AM, Wil Sinclair &lt;wllm(a)wllm.com&gt; wrote: ​This - signing by hand - is pretty much a universal experience for new users, myself included.

​ -- ~Keegan https://en.wikipedia.org/wiki/User:Keegan

This is my personal email address. Everything sent from this email address is in a personal capacity. _______________________________________________ Wikimedia-l mailing list, guidelines at:

Wikimedia-l(a)lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,

Hoi. When you look at talk pages in isolation, you look at them on a computer screen. A mobile or tablet screen is increasingly not used in isolation.

is where we find our new users and editors. We cannot afford to ignore them; they are our future. This is why tinkering with talk pages is not an option. Moving away from talk pages because of mobiles and tablets is the killer reason why we need to move away from talk pages. It is a killer reason because it makes all arguments to the contrary pale away. Thanks, GerardM

On 10 September 2014 09:20, Martijn Hoekstra &lt;martijnhoekstra(a)gmail.com&gt; wrote: > On Sep 10, 2014 5:11 AM, "Keegan Peterzell" &lt;keegan.wiki(a)gmail.com&gt;

> > > > On Tue, Sep 9, 2014 at 10:04 AM, Wil Sinclair &lt;wllm(a)wllm.com&gt; wrote: > > > > > > > > FWIW, I signed my first comment by hand. I missed the comments about > > > sigs in the wikitext editor interface. If it weren't for my family > > > situation, I'm pretty sure I would have bailed. In any case, it was > > > much easier to engage at WO, and that was partly- but not mostly-

> > > to the fact that they run discussion software over there. > > > > > > ,Wil > > > > > > > > ​This - signing by hand - is pretty much a universal experience for

> > users, myself included. > > > > > >

> > ​ > > > > > > -- > > ~Keegan > > > > https://en.wikipedia.org/wiki/User:Keegan > > I'm not saying that isn't crap and unwelcoming: it is, and it deters new > users. But it's hardly the end of the world either. By signing the wrong > way no real harm is done, if someone just tells you about the option to

> ~~~~ > > It's crap and archaic and should be fixed, but it's also an example of

> idea that there are no mistakes on a wiki. So you did something not

> Great, that means you contributed. So we fix it (collaboratively) and > improve your contribution, no harm done. > > That said, auto sign and a reply button would be a *whole* lot

> than what we have now, and would be great improvements over the current > situation. > > Flow definitely has a reply button, and automatic signing as well, but I > can't help but think that just those features in isolation would be

_______________________________________________ Wikimedia-l mailing list, guidelines at:

Wikimedia-l(a)lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,

Hoi, I expected that it was obvious... Arguments that are based on desktop experiences are futile because the desktop experience is the lesser of two evils. The desktop experience is already bad, the experience on mobiles and tablets is much worse it is intolerably unusable,

Yes, you are overlooking stuff when you only consider inserting an isolated comment that may help. That is not the only problem and not even the main problem. Reading and analysing talk pages is already next to impossible in this environment therefore inserting an isolated comment does not help enough to make the experience at least bearable. Thanks, GerardM

On 10 September 2014 09:47, Martijn Hoekstra &lt;martijnhoekstra(a)gmail.com&gt; wrote: computer isolation. the pale pages. indentation martijnhoekstra(a)gmail.com&gt; wrote: family was https://en.wikipedia.org/w/index.php?title=Talk:History_of_Alaska&diff=… to of current but

What do you propose to make talk pages easier to read and analyse?

Making entering text on a phone a process not made entirely of pain will be interesting.

Am 10.09.2014 09:56 schrieb "Gerard Meijssen" &lt;gerard.meijssen(a)gmail.com&gt;om>: two and isolated in What do you propose to make talk pages easier to read and analyse? computer isolation. ignore not the pale skin, is pages. indentation martijnhoekstra(a)gmail.com&gt; wrote: family was mostly- for https://en.wikipedia.org/w/index.php?title=Talk:History_of_Alaska&diff=… deters option to of and current but email ?subject=unsubscribe> https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, ?subject=unsubscribe> https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines <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(a)lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>

[...] that allow editors and admins to detect and combat vandalism and remove BLP sensible material and libel; features which are not available in Flow as of today.

On 09/10/2014 01:25 PM, Diego Moya wrote: That is simply not true, at last as of the master branch. Topics and replies can be hidden, deleted, or suppressed -- the same things that can be done to talk page revisions at this moment.

given that the actual comments are isolated and not differences between revision, supressing a comment containing libel that has gone unnoticed for a bit does *not* cause the history of the conversation to be mangled because intermediate diffs have to be suppressed as well. -- Marc

On 09/10/2014 01:41 PM, Diego Moya wrote: As far as I can tell, you could see it because it never /was/ deleted. I just deleted it, can you still see it? I think what you see is the odd interaction with deleting the "page" that a flow board lived at -- which may not even be a supported scenario (or, at the very least, might need work). -- Marc _______________________________________________ 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>

When a specific way of working insists on talk pages, it means that the associated workflow has to be revisited and changed with urgency. It cannot be permitted that special interests take the whole of the much needed change hostage. "Leaving this material unchecked ..." is FUD. It is not an argument that prevents change, at most it means that a different mechanism has to be designed for that special interest.

David's really on to something here. What is the "killer app" of the platform? If we think through requirements some, we might identify just one or two features of Flow that almost all editors would find compelling. This may be enough to shift lots of criticism from "I don't want Flow because of this use case" to "I want Flow because of this killer feature, but what can we do about this use case I'm concerned about?" It may not be apparent on first glance. Candidates for me would include well structured threaded discussions and no edit conflicts, but these don't seem to be enough for a lot of editors- particularly if they have to give up some other features that current talk pages have to offer that they find more compelling. For those of you who are holding out on support for Flow because there isn't anything that you feel provides enough value to tip the scales in favor of Flow vs. current talk pages, can you think of any one feature- or maybe a small collection of features- that would? ,Wil On Wed, Sep 10, 2014 at 11:00 AM, David Gerard &lt;dgerard(a)gmail.com&gt; wrote: _______________________________________________ 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>

wrote: Gerard, It would really help me if you would go a little lower on the hyperbole. As soon as possible is indeed not tomorrow. It's today. Only we both agree that would be a very bad idea. What you probably mean is "As soon as a reasonable replacement for processes and talk pages can be found" - but when I phrase it like that, it becomes open for discussion what that reasonable replacement could be. It makes it very hard to keep taking your posts seriously if you keep speaking in such hyperbole. --Martijn

On 10 September 2014 19:54, Gerard Meijssen &lt;gerard.meijssen(a)gmail.com&gt; wrote: understand That should be known in advance, before removing the old mechanisms, not as a consequence of removing the tools that editors use. Those tools are in active use for a reason - if you remove the previous tools without a replacement in place, the tasks that depend upon them would cease to be performed. If you don't understand what you're trying to get rid of, please don't be so eager to remove it. Detailed diffs at watchlists and wiki history are what allow experienced editors to keep track of changes to a huge volume of talk pages. They include: * edit summaries for each change that users make to the page * a quick link to the exact content of one edit (that can be set up to be read with a mouse hover, without having to navigate away from the list of changes) * summary of changes from the last visit, showing the exact changes that happened between two revisions - and nothing else. Finding out quickly what exactly has been changed since the last time you visited a thread was a nightmare with LiquidThreads, and outright impossible with the current Flow design, yet it's an essential feature for reviewers and patrollers that have a huge number of watched pages - i.e. those editors that perform upkeep tasks and keep it reasonably clean of vandals and trolls. If we pulled the rug out and removed the tools they need to keep an eye upon destructive changes, those vital tasks to the project would be severely hurt. cannot an mechanism For the record, I don't oppose replacing the old ways of working with some other mechanism to achieve the same goal that would require retraining the users. I'm opposed to replacing those *before* the new software is able to support them, as it would disrupt the project in the meantime, and there's a very real possibility that the new software could happen to not be up to the task, and that we would find it out only after the fact. "There's a chance the project may be destroyed" is not a threat that old-time editors make, it's a natural consequence of what would happen if you restrict their ability to keep the project afloat. _______________________________________________ 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>

In case it's not clear enough in my sig, this is my personal opinion: On Wed, Sep 10, 2014 at 12:20 AM, Martijn Hoekstra < martijnhoekstra(a)gmail.com&gt; wrote: wrote: https://en.wikipedia.org/w/index.php?title=Talk:History_of_Alaska&diff=… use the right? ​I agree with you, Martjin. If you follow the cookie crumbs you'd see that I registered an account on the English Wikipedia /solely/ so I could sign a complaint about a resource I used and loved, and I thought it best to give respect back by registering and figuring out how to sign my complaint. I was also incredibly lucky as a n00b to have positive interactions, right from the get-go, which makes it a little more clear to me why I'm still around after all this time. I'm thirty-three years old, to me a nine-year unintentional commitment is a lifetime :) I'm also aware, through my experiences through the past nine years, that my experience is Golden™, and I desperately wish all new users could have such an experience. This kind of thing starts with software changes that break my workflow. I hate that. But to be fair, my workflow is ridiculous because the software is.​ ​The steps I have to take to do the things that I do would, IMO, make a rational person cry :). I really don't understand the theory that new users have to go through the same experiences as I did, no matter how pleasant, again IMO, my experiences were.

unfruitful process. It only breaks people down to rebuild them in the image that you want, and that's contradictory to the individualism that Wikimedia promotes.

I enjoy the fact that Wikimedia sites allow flexibility and customization on a personal account and institutional level. On the other hand, the world keeps moving and I sta​y in the same place unless I choose to go through the process of acceptance of a changing world. I do not consider the world changing to be something shoved down my throat; it's a reality of life. -- ~Keegan https://en.wikipedia.org/wiki/User:Keegan This is my personal email address. Everything sent from this email address is in a personal capacity. _______________________________________________ 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>

Now if Erik vision for the deeper than I give him credit for,