Topic on Talk:Flow Portal/Archive2

Auto-archiving is a horribly unflexible solution which is suitable only for the least active talk pages; please elaborate on what methods of archiving will be available. Cf. bugzilla:24815.

+1

archiving is definitely something that needs to be handled implicitly by the software, not by bots and humans.

I think we have different understanding of "archiving".

In this case, by "auto archiving", we mean "it gets old and falls off the front page". There is no real explicit "archive" action that will cause something to disappear; all the content remains you just have to keep paging (or scrolling) through the timeline to get to it. Or search for it. Or one of several ways to find it.

"Manual Archiving" in this case is going to be like "hatting" a thread: you close it to new replies, drop in a summary as to why, and that's that.

Yes, that's the auto-archiving that I was referring to, and it makes the system unusable.

I'm. . . totally confused. How does this make it unusable?

Have you ever used feeds before? My twitter stream auto-archives. You get to the archives by scrolling. They're there. They're not really archived; they are just lazy loaded.

Yes and I hate it, but I don't have to work on it, it's just chatter. What you're proposing is the same in LQT, so I'm not going to repeat what was already said for LQT; just see the tracking bug above. This loss of functioning may be ok for user talk pages, but if you think this flow system might ever be used elsewhere I suggest you to put more thought in this or it will bite hard later.

I don't see any problem in an inactive discussion getting off the main page automatically. What really bothers me is when someone "lock" a topic to new comments just because it has being inactive for N days. Actually, usually I don't see a reason to close a topic to future comments. This just forces people to create a duplicated topic to discuss the same thing (instead of just adding a comment which would make the topic to be moved to the beginning of the list again)

Would a more intelligent way to link to the previous discussion (or even just pull it back into the new one) help with that? Things are archived, but it doesn't necessarily mean they aren't still worth discussing, indeed.

I agree. A feature that automatically suggests possible duplicate topics would be ideal to solve this problem.

I agree with you Helder, topics/discussions should not be locked for inactivity or because immediate consensus is one way or another (I've seen some that are closed in less than a few of hours which prevents people in other timezones from contributing and effectively excluding them).

I think it's worth noting that when we say topic, we're not just talking things on article or user talkpages; if we ever want this sort of thing to work on community noticeboards, for example, having a lock feature is useful.

Even then, sometimes there are typos in archived/resolved discussions, or links (internal or external) that need to be updated, etc. and it wouldn't be a good thing to prevent editors from performing such changes.

The point of "locking" a topic is not to prevent people from ever editing it again. What we're talking about here is the equivalent of a "hat note".

Who can unlock and lock topics is a question we should ask, but I shouldn't think of it as being a "NEVER AGAIN SHALL THIS BE TOUCHED" type of lock; more of a "okay, we're kind of done here; let's move on."

On the contrary, auto-archiving is arguably unnecessary on less-active talkpages... it's the more active ones that could sometimes not even function without it. Currently the solution is bots and they work fine, but they needn't be necessary...

But this would be just like with bots, far as I can figure. Falls off the page, goes away, call it what you will, but it will still be accessible... Whatever the case it was not being edited or nothing added, so the discussion is clearly done, even if it is just because everyone was ignoring it. But not archiving it wouldn't make them not ignore it, unfortunately.

Might need to consider something to make some threads sticky, but that will be a later consideration.

No, that's not how it works. Bots archival is often incorrect, so such bots are sometimes reverted and need templates to ask archival or prevent it. Still, they're waaaay more flexible and efficient than the "auto-archival" as commonly meant and as implemented in LQT.

I'm not going to repeat everything: don't be lazy, read the bugs against LQT, I've triaged and organised them and it was enough of a waste of time. I've no idea who's responsible for designing Flow but it would be a suicide to ignore the experience we've got with the LQT attempt to replace wiki pages.

I honestly think we're talking past one another.

Exactly, that's why you should look at more opinions by using bugzilla. :)

That's not what Bugzilla is for. If you want more opinions, start an RfC or go to meta or something.

The opinions are already there! Unlike this talk page were a handful people talk past each other (quot.). And now I'm unwatching all the threads and discussions about Flow, I'm never going to look at it for the next few years. Thanks for your patience.

I disagree. Although Bugzilla is neither a replacement for a mailing list nor an RFC, Nemo is right; Bugzilla is a place where people report things they think are problems.

Thus, it's quite reasonable to at least skim through the LQT bug subjects, and read some in full.

Indeed.

On the contrary, bots are, by the large, just fine, and some projects at least (Commons and enwp come to mind, mostly because they're the only ones I really use) would be kind of horribly massively screwed without them. Like... they wouldn't function. At all. Now sometimes bots do mess up, but that's what overrides are for, and no viable system would be without the ability to override the automatic or specify different archival periods/rates for different pages. MediaWiki is all about overrides; the key is to figure out which overrides are actually practical without overwhelming the users and all that jazz.

Flow is not going to be LQT. It may share some features in common, but there are many more mistakes to be learned from and avoided.

I'm not sure I like where this is going... There are some cool features and improvements over the current system, I agree. I have an apparently "unusual" method of archiving discussions on my talk page on Wikipedia. I have a set of tabs, and on my "talk" tab, I've created a ToC that will allow you to quickly and easily navigate to conversations by year. My actual "talk" page is really a re-direct to the current year's discussions (User_talk:Technical_13/2013 for this year for example). How will this new system get along with the archival system I use? Will I be able to opt out of using this system on my talk page if they don't get along?

I'm sorry to say but no, your set up will no longer work. It may be possible to transclude your Flow board into a page (and this is expected to happen) but at the end of the day the purpose of this project is to help standardize communication and collaboration mechanisms, not allow them to become further fragmented.

Your archival system, as described, will be obsoleted and not required.

As far as opting out, the roll-out plan has not been finalized but you should expect that this system - or one like it - will eventually become mandatory. When that will be I do not know.

How nice. I was going to refactor my talk page so that I archive stuff by content instead than by date, and now someone comes and breaks it. Wikitext is flexible and easy. This thing is not.

What if you could tag the threads, with a "#keyword", so that you could organize content with 1 quick action, even before or after it gets auto-archived?

What if you could watch publicly tagged combinations, such as, any workflow with both "#afd" and "#philosophy" gets fed into your watchlist? (Versus the current methods of watchlisting every change to w:Wikipedia:WikiProject Deletion sorting/Philosophy and to w:Wikipedia:WikiProject Philosophy/Article alerts, and the former having to be manually (and laboriously) updated)

That seems to be what Flow Portal/Basic information#Flow Board Search and Filter is hinting at the possibilities of.

That is all cool and well, thanks, and yes, they are improvements. Still, why not leaving the old infinitely-flexible system and build these things on top of it, instead of replacing it and playing whack-a-mole with new ad-hoc features in the hope of catching all use cases again? This is what I disapprove. I totally understand that doing it from scratch may be easier, but that is not a good excuse.

See w:Wikipedia talk:Flow#Conversion of old discussions for Jorm's comments on converting the existing pages.

Yes, we already noticed that Brandon has his own understanding of how the community should use talk pages. </sarcasm>

Frankly, it's tiresome that you developers assume to know better than ourselves how we are using the tools, and that for every feature that we request, you reply that it's simply not needed and there will be no plan to support it, or that we will need to ask it to be re-made from scratch. What happened to the old tenet of reaching to your user base to gather requirements before designing a software solution?

That some features are difficult to implement we can understand, but at least try to create an architecture that wont preclude them from being added in the future. The Parsoid and VE teams are doing just that, they're not artificially limiting the tool's potential growth from the beginning.

Another reply: I would argue that your current mode of archiving is actually less flexible: you have to archive atomically - that is, only one "tag". With Flow, you can apply multiple tags and the same content can appear in multiple places, which is far more flexible.

I'd call it confusing. Actually I'd give a link to the comment I just posted regarding the issue, but it is gone from my "New messages" feed – a problem that Flow might share.

And since I don't know on what I actually commented (I only replied to a "random" message that popped up as unread somewhere in my feed, no idea to which page this thread actually belonged) I'd also have a hard time to find this comment. So I'll just leave the link out.

Something like this would never happen with our current talk pages system: I'd know on what page, and in which section I commented. And probably the comment would have been on the same page (not totally split from each other as it might occur with feeds).

The LiquidThreads behavior in that regard is infuriating, to be sure, and is one of the things that we've designed against.

I really don't know how to help you, Patrick. You're dead set against anything and everything; I think it may be better for me to disengage with you.

I'm not dead set against it but I admit I'm very very skeptical about it to the point I will first believe it when I see it and when I see it works.

Have you stated somewhere how you will prevent the problems I mentioned? I'm sure you improved upon LiquidThreads (and I only used it as a rough example to get an idea of what I'm talking about), but how will you solve the fundamental problem of the "feeds" design? How will you make sure people know what they are discussing? How will you prevent endless discussion without real result (as the "flow" might produce)? Do you think people come back to a talk page and solve all the open issues on this talk page as they do currently, when the talk page is nothing more than a feed of multiple threads "flowing" around? Maybe my view is too narrow to see how this should work, but I'd be happy if you tried to enlighten me.

Although I admit this might be unpleasant questions, I think those are valid concerns and you'd be better off to take them into consideration.

How will you prevent endless discussion without real result (as the "flow" might produce)?

Do you think that we do this now, using the "infinitely flexible" free-form wikitext that lets users do whatever they want, including getting completely off track or talking past each other?

No, it's already a serious problem with current talk pages but I'm pretty sure the intended design of Flow will make it a lot worse. That's why I try to encourage you to think of alternatives and/or ways to mitigate the negative aspects of the design.

To describe my concerns as general as possible:

1. I don't think a threaded discussion system were answers are sorted according to the comments they were posted on aids any discussion. It leads to many "sub-threads" (just to remind you, the topic of this thread is "Auto-archiving", but that's not what we're discussing any more). Most of these sub-threads don't ever reach any useful consensus at all. The discussion gets "stuck" in them (think of en:WP:Bikeshed). The initial topic of the thread gets out of sight.
2. The other extreme – comments ordered strictly according to the date they were posted as in many forums – isn't the best solution either. The discussion goes on (with the newest comments always at the end). Sub-threads don't have the ability to emerge. The problem is that it's nearly impossible to have multiple discussions on the topic going on in parallel. Also if the discussion goes off-topic it's hard to get back on-topic.
3. The "infinitely flexible" free-form wikitext that lets users do whatever they want actually is improving upon both thread models (as long as authors use the tools in a reasonable manner). On one hand one has the possibilities of 1. being able to create arbitrary thread structures. On the other hand when some discussions get too deeply nested and/or too off-topic one simply "outdents", the discussion continues at the bottom where the newest answers are (similar to 2.), and the former "sub-threads" start to die out.

I admit that 3. (our current discussion system) is only as good as the editors that are taking part in the discussion and for this reason it is not perfect either. But in my opinion it is still superior to 1. (what Flow should be) and clearly superior to 2., combining the advantages of both as good as possible.

Or you split the thread, so that tangents get their own, which is (1) what we do manually now, whenever anyone's actively managing a discussion and (2) what Flow is designed to make a quick and easy task, without needing to manually change the number of colons on anything.

Sounds like a good idea in theory, but who is going to split threads in practice? Especially those off-topic sub-threads that are not really worth discussing at all containing only meta-discussion without real value for the project? When you split them off they might catch even more attention, if you don't they are detrimental to the goal of the main thread.

Also, splitting a thread might get controversial very fast (who decides if a discussion is too off-topic regarding the original thread?). Authors could feel offended when their contribution to a thread gets split off, resulting in edit warring.

The only solution to the above I could think of is only allowing administrators to do these jobs. This is however totally against Wikipedia principles and will hopelessly overload admins.

I suspect that it will be handled the same way that it is now, which means not usually bothered with and rarely reverted. It's the same task that we're doing manually right now. The only real difference is that in the future, splitting will be done by clicking on a menu instead of by typing ===Section headings=== and removing :::::indentation formatting.

Flow does not change talk page guidelines in any material way. It changes the buttons you click on to do the same tasks. It does not change the rules about what you should or shouldn't do.

Sorry, but you're loosing my original argument:

• Currently moderating in this form is nearly not present. Threads are seldom "split" and indentation is only touched slightly. It's not needed on current talk pages for discussions to work efficiently.
• Flow will urgently require such moderating per the issues I mentioned above.

Therefore we have no bothering and reverting with current talk pages, but I'm sure we'll either have

1. endless meta discussions without results or
2. edit warring at it's best when people try to moderate

with Flow.

This is not an "non-issue" as you're trying to convince me. It is a hell of an issue that will decide whether Flow works or will blow up in your face!

Please, take the time and think about it. The slightest changes to a discussion system have the power to totally change the way discussions are held (even if it doesn't "really" change something).

Your concern here is about handling somewhat-off-topic comments.

You seem to be saying that the inclusion of a couple of tangential comments in a conversation is just fine now, but the same comments posted in the same discussion will somehow, suddenly become incredibly disruptive to the conversation merely because those comments are posted in Flow instead of on an old-fashioned talk page.

I do not agree with your belief that exactly the same comments in exactly the same discussion will be perfectly fine in one discussion format and completely disruptive in another discussion format.

Sorry, maybe I'm not clear enough, but the discussions will not be the same. The discussion formats are different enough to influence discussions in a detrimental way.

In the end it's as simple as this (I thought I'd made that clear before but maybe I did not):

• When somebody posts an off-topic comment on our current talk pages, the discussion goes on (at the bottom of the section) and this of-topic branch dies out.
• When somebody posts an off-topic comment in Flow, this new branch will stay at the top of the thread whenever a new answer is posted, no matter where the main discussion has (or would have) gone.

Since having new messages at the top of your feed is one of the principles of Flow, theres nothing you can do about that.

We're obviously not picturing the same thing. So here's what we've got now:

You: 1

Me: 2

You: 3

Me: 4

You: 5

Me: 6

That's a basic threaded, indented discussion with six comments, half from me and half from you. The numbers tell you the order that the comments happened in. If someone revives this discussion years later, they'll add their comment, #7, at the bottom.

Let's say that somebody adds an off-topic comment in the middle. Chronologically, it appeared after your comment #3, and before my reply #4, like this:

You: 1

Me: 2

You: 3

New user: Tangent!

Me: That's a bit of a tangent.

You: Try posting your idea to this other page.

Me: 4

You: 5

Me: 6

Again, if someone revives this conversation years later, they'll add their comment, #7, at the bottom.

Now, you say that this off-topic tangent eventually dies out in the current system. That's fine. But how is it that this tangent will not die out, just because the same conversation is posted to a Flow thread instead of to a free-form wikitext page? How is this comment not staying right where it was typed, near the top of the old-fashioned discussion, but somehow it climbs higher in prominence, above the original comments, if you type exactly the same conversation, in exactly the same order, into Flow?

The answers are simple:

• The first case:
  With current system, if someone answers "years later" he/she will add #7 not as subthread of #6 but at the top level (therefore outdenting, but it will still be in reply to number #6). Normally nobody will add a comment between #6 and #7 afterwards, but the discussion will continue strictly below #7 leaving the old part of the thread alone.
  This might work in Flow up to this point, although I'm quite sure #7 would become a subthread of #6 in Flow in practice (that's how "reply" buttons work and how people are using them). Therefore the new conversation partially might get partially buried in a sevenfold nested discussion. Maybe someone will then even answer directly to post #1 to artificially outdent the thread, making #7 a "dead end".

• The second case:
  You're right, up to the point you posted (the three replies to #3) a thread in the current discussion system will look exactly like it probably will look in Flow. However you're overlooking something that will happen afterwards (at least if Flow will work the way the whole Feed-thing implies):
  With the current discussion system a post #7 that is added "years later" will be added at the bottom (as described in my first bullet point).
  With Flow, the latest post will probably show up quite prominently (as it is the latest post in the thread). The deeply nested discussion starting with #4 might be even collapsed at this point. Therefore it is very unclear where this potential #7 will be added (plus the potential issues mentioned in my first bullet point).

I disagree.

First, right now, there are hundreds of examples of people replying to years-old conversations without outdenting. You could probably find dozens of such examples in my own contributions alone. It is universal if the years-later reply is the second reply in the discussion, and it is very common for short discussions.

Second, as I understand it, messages that you personally have read will be collapsed (to save screen real estate, which you were complaining about above), and all the messages that you personally have not read will not be collapsed. So I don't think that people will have any more difficulty in figuring out what the most recent reply is about than they do now.

Sorry, but you did cleary not understand my second point, and also not my intention on screen real estate:

• The latest post in a thread (that might be new, therefore unread and uncollapsed) might be a totally uninteresting side note (the tangent you mentioned between comments "3" and "4" above). It will be the latest dicussion, therfore marked unread and unfolded for everyone, therefore attracting traffic. People might reply to this tangent!
  The important part of the thread, which might have continued through "4", "5" and "6" is old ad this point, will be marked as read and might be collapsed. Therfore the "important part's visibility is low, while the unimportant part's visibility is high!
  What I wanted t express is, that Flow probably will encourage people to reply to new posts, in contrast to following the golden thread down to parts which might be already collapsed.
• Regarding screen real estate: Yes, I want to save up as much space as possible. But not by hiding content but by optimizing the UI and using the available space for content as efficiently as possible.
  You propably now the idiom "Out of sight, out of mind". That's exactly what will happen when collapsing is used. And (I'm sorry to destroy this dream) a user will not remember all content he read so you can cleanly wipe it from his "feed". He often needs substantial parts of past discussion as a mnemonic device – and he'll forget most of the past discussion as soon as this device is removed (aka old content collapsed)... And people will discuss over and over again, exactly the same content, having forgotten all that was before (reminds me of "groundhog day").

A personal side note: I have disabled collapsing for Liquid Threads, for exactly this reason. I want to have all the conversation right at my hands. So I can re-read old comments whenever I wish and to always have an overview of a threads history, to prevent discussing things over and over again.

Who cares if people reply to an old tangent? They do it now, and the sky still hasn't fallen. If the new comment is about the tangent, then the contents of the non-tangent 'host' thread are pretty irrelevant anyway, aren't they?

If it really bother you in a given instance, then split the thread to remove the tangent, just like you do now. The only real difference is in how you will do this. The new method will involve clicking a button or menu item. The old method involved deleting colons. Your general discussion-management options, and the end result, are still fundamentally the same.

I'm giving up on this. You seem to be totally convinced that the currently intended design for Flow will work, so that there is no point to try to explain the problems to you further.

It's sad, since such design decisions will take their toll once Flow is deployed, in form of much less constructive discussions than we have now (and yes, I'm 100 % sure of this, but I don't know how to further elaborate on this).

But maybe this is the target of Flow: A steady flow of high volume, low quality discussions, some of which might produce at least some useful content in the end. Then do what you think is right and fall flat on your face with it.

WhatamIdoing, what Patrick complaints is not that people will be able to answer to the tangent; of course people can do that now too. It's that the design will encourage answering to the tangent, because it will be the one that stands out as more visible. This doesn't happen now, because the most visible comments are those physically at the beginning and end of the page, not the ones with the latest date; a tangent comment gets buried in the current system, as it's usually posted mid-page in the whole thread, so it doesn't have high visibility. With Flow, it would stand out, which is a Bad Thing - the original thread's subject is what should define the topic of conversation, so that off-topic detours are kept to a minimum.

It's not about the possibilities of the tool being the same; it's about the defaults, which as described will encourage the wrong behavior from users.

I don't see that as the case. If a split Topic is off topic for the Board, it gets re-parented to a different Board. If it's just off-topic, period, it gets closed (hatted). Either way, the original Topic remains pure.

You're always presuming that such moderating will actually happen. When I look at current threads this is clearly not the case. Threads need to "moderate themselves", e.g. keep clear even if off-topic discussion is happening. The current discussion system is quite good at this job (even if it probably was a lucky shot).

Additionally (as stated before) if re-parenting or even closure was done by users, it would produce controversy and maybe edit warring (who decides when topics are off-topic, what would be a more appropriate board or if the off-topic can even be "hatted"?)

If the moderating was only allowed to do by moderators (therefore circumventing most controversy), administrators would be drowning in work.

"I don't see that as the case".

Then you don't get what we're trying to say. The current design of talk pages deemphasizes answering to off-topic edits made in the middle of a thread, by its pure presentation, with no need of splitting nor re-parenting.

The proposed design emphasizes by default the visibility of such posts, which is exactly the opposite effect, and thus problematic. It requires active administration by administrators/users to keep the thread on-topic, while in the current design we get that for free without the need for user intervention.

We seem to be mixing 2 issues: off-topic comments, and mid-thread comments.

Off-topic comments (jokes/banter/tangentialquestions/etc) can be ignored (as we ideally do now), or if they're a legitimate separate topic then they can (more easily with Flow (hypothetically)) be split off into a new thread.

[I do agree that the decision of "when to split" will be a new-ish process for us to deal with (assuming that Flow makes it easier somehow), but it's the kind of thing we're pretty good at coming up with community-norms and guidelines for, if given a little time and hands-on experience. If we want to discuss the hypotheticals of how that could work, now/here, a new thread for it would be good!]

Mid-thread comments are actually a thing that we might not want to miss, but are very easy to miss with the current discussion system. There are numerous times, that I've made a reply to a busy thread, in the semantically correct location (eg. halfway down, 5:indents in), but barely anybody saw it, because we're all too often in the habit of only looking at the bottom few posts. LQT is possibly an example of a fix for this, and this discussion is an example in particular. I assume Flow will be similarly useful in this regard.

Exactly!

AFAICT, what Patrick complains of is his belief that a tangentially related comment made in the middle of the discussion, according to the date stamps will somehow be placed very prominently at the top (i.e., before the comment that it is in reply to), because Flow can magically tell that it's a tangent and wants to separate it from the rest of the discussion, instead of leaving all the comments in the position that the users put them in.

Go look at the example I gave. Pay careful attention to the words "Chronologically, it appeared after your comment #3, and before my reply #4, like this:"

When you understand that the comments in this discussionw were made in chronological order, then see if you can explain why you believe Flow would split them up instead of presenting them in order.

I know that it's difficult to understand a visual structure by talking about it, but please try to make an effort. The summary you provide is still an inaccurate understanding of what Patrick and I have said, although you're closer. Now if you replace where you say "will somehow be placed very prominently at the top" with "will be prominently placed, as its shown expanded and with all threads above and below it contracted" you'll finally see what we're trying to say. The part about the software magically detecting whether a post is on-topic is an strawman argument, so let's forget that part and see how both systems actually differ.

That your particular example doesn't show problems doesn't mean that no other common situations exist that are problematic. The problem appears not when all comments are made in order, but when one post is made out-of-order as a reply to a comment in the middle of a thread. Let's see an example where the difference can be seen:

Alice: 1

Bob: 2

Alice: 3

Cartman: 4a

Bob:4b

Alice: 5

Bob: 6

Here, both comments 4a and 4b are replies to comment 3. Let's say Cartman's comment 4a is slightly off-topic, but still merits a late answer by Alice (call it 4a'), chronologically made after comment 6. In the current software, this is the resulting thread:

Alice: 1

Bob: 2

Alice: 3

Cartman: 4a

Alice: 4a' (offtopic)

Bob:4b

Alice: 5

Bob: 6

Here, only Alice and Cartman would be interested in continuing thread 4a; any other editor would continue the main thread with comment 7, normally by outdenting it below #6. However, if Bob returns to the thread right now, this is what he'll see:

Collapsed comments (1,2,3)

Cartman: 4a

Alice: 4a' (offtopic)

Collapsed commens (4b, 5, 6)

Given that Alice's offtopic comment is the last one made, it's the one that's show expanded. Can you see now how Flow's different presentation can highlight different parts of the conversation, even if the structure is exactly the same? Now anyone returning to the thread will be enticed to follow the offtopic conversation, instead of replying to the hidden comment #6.

The solution you suggest would be to manually split thread 4a, requiring a maintenance discipline that is currently not needed. However, Flow doesn't support sub-sections, so not even that solution is similar (in current talk pages, thread 4a could be continued as a new sub-section under the same section; with Flow it'll have to be located at a completely separate new Topic). I think the best option for Flow on Article Talk pages will be to avoid any form of collapsed comments, to make it as similar as possible to the current system.

I hope that you finally can see our concerns from this explanation. If you still can't see it, we'll have to wait until a working prototype is available to provide a more realistic and detailed example of the problem; our concerns are certainly not going away.

You are concerned that this (to a person who has already read nearly all of this thread, not to someone reading it for the first time):

[Collapsed comments (1,2,3)]
  Cartman: 4a
    Alice: 4a' (offtopic)
      [Collapsed comments (4b, 5, 6)]

will make the off-topic comment too visible. Well, actually, I don't think you'll see that. Cartman's post is old in your example, so you'd actually see this:

[Collapsed comments (1,2,3,4a)]
    Alice: 4a' (offtopic)
      [Collapsed comments (4b,5,6)]

or perhaps you'd see one line from each of them, to refresh your memory:

[Collapsed #1:  When in the course of hunam events...]
  [Collapsed #2:  We need to discuss the definition...]
    [Collapsed #3:  You have a typo at ''human''...]
       [Collapsed Cartman: 4a]
         Alice: 4a' (offtopic)
      [Collapsed #4b:  I agree.]
        [Collapsed #5:  Are we sure this is "necessary"?]
          [Collapsed #6:  Yes, but I think it's...]

If Alice had never made her comment, the thread would look like this:

[Collapsed comments (1,2,3,4a,4b,5,6)]

This, too, presumably makes reply #6 (which you read yesterday, or last week, or whenever) just as hidden as Alice's off-topic post.

What really matters isn't whether Alice's comment is "off-topic". What matters is whether it's useful. If people want to reply to it, then they should be able to, just like they are now. If their replies become unmanageable, then split the thread, just like we do now. By "just like we do now", I mean "this practice is already so common that the talk page guidelines have addressed the ways to do it for years now.

I don't know enough yet about how it would be done and noted to determine whether thread split/combine would create opportunities for vandalism which would be difficult to reverse. Perhaps thread split/combine and message deletion (as opposed to blanking) should be restricted to admins.

We've agreed that, on en.wiki, there should be no restrictions on who can edit messages. That doesn't mean there shouldn't be restrictions on restructuring messages.

As far as software design is concerned, it would be very foolish for Flow to hard-code the user groups who are allowed to take actions. You should expect each individual project to be able to decide which groups are allowed to take which actions, and you should expect to be able to change them if you later decide that your first choice was a mistake.

How have you designed against that? The Flow prototype has in essence the same confusing structure of LiquidThreads, minus LQT's helpful main index. Are you referring to the separate, persistent notifications? I think that will help to reduce confusion, but it's not enough.

Quote (@Jorm): „With Flow, you can apply multiple tags and the same content can appear in multiple places, which is far more flexible.“

Who says this can't be done by creating tags on top of the current wiki-based talk pages as Cyclopia suggested, in the form of templates and transclusion? This way you'd have all the flexibility of Flow tags, plus all the flexibility of the base wiki system, making it far more flexible that the previous both alternatives!!.

How? My user talk page at en.wp normally has between 50 and 100 discussions on it. How could the "infinitely flexible" current system let me tag each section as being different from the others? Is your idea that my user talk page turns into one of those AFD-like nightmares of transcluding every single discussion separately? No thanks.

The current system already tags each section as different from the others; each section or subsection title gets its anchor, and a neat table of contents is placed at the top of the page with all the section titles. I don't see anything like that in the Flow prototype nor design documents. There's nothing terrible about pages like Wikideletion Today, in fact that's a terrific way to catch up on recent conversations dispersed throughout the community on a loose topic, a really practical summary of everything that was added to in the previous 24 hours, that I can quickly skim to find what discussions are of interest to me. Are you really suggesting that a workflow that many find useful should not be supported because you personally wouldn't find a use for it? I'm not proposing to have it at *all* pages, only those where it does make sense.

How exactly would the current design support skimming irrelevant threads to which I'm subscribed, in order to find only the ones at which I want to participate? The current Flow design seem to force you to review the content of everything to which you're subscribed to, which is certainly nightmarish. But a good table of content provides the kind of overview that allows power users to follow a huge amount of content updates without being overwhelming. What is the equivalent topic overview tool in Flow?

The equivalent is tags: Flow Portal/Basic information#Tags. The description there isn't great (it needs a lot of expansion from the bulletpoints), but essentially it will let us automate a bunch of procedures that currently have to be done manually in multiple steps (or slightly faster with userscripts), eg the Deletion sorting.

A strongly related system is w:Wikipedia:Article alerts. Tags could be thought of as an upgrade and/or expansion of this system (which is reliant upon wikiproject banners).

Side-note: w:Wikipedia:XfD today seems to be a slightly more official version of Wcquidditch's Wikideletion Today, and I've suggested potentially merging those 2, to get the best aspects of both in a single location. :)

My point is that the allegedly "infinitely flexible" current system makes it impossible for any person to load and ready just the one or two sections on my user talk page that interests him.

I'm not sure what your other concern is here. You praise Wikideletion Today for putting every single deletion discussion in front of you, whether you want it or not. You then complain that Flow has the option of putting every single deletion discussion in front of you. If you can tell me why it's good for WT to do this and bad for Flow to do this, then perhaps I'll understand your concern.

The difference is one of context. If I filter out all the information that I don't want to see right now, I will not be aware that it exists in order to maybe see it later. Wikideletion Today puts all discussions in a single page, and then provides a table of contents for all discussions in the page, so that I can do two things:

1. See how many conversations are active in the page (with a list of their section and subsection titles, which also provides hints about their relative size), and
2. Select which conversations I want to read, skipping the rest.

This is the overview-plus-detail pattern, which is lost if you treat all content as an infinite stream of posts without an overarching structure. It wouldn't matter if a Talk page was simply a collection of totally unrelated conversations, but that is not true of Article Talk discussions, with are related by the article's topic; or Wikiproject's log reviews, which are related by the project's goals and activity.

There's no evidence at the Flow prototype or current design documents that Flow will have a way to provide 1 (seeing everything that exists) without forcing you to read everything (i.e. having all conversations loaded and expanded). The one feature that would approximate that, folding all threads, you said will be removed; and the tag system will only show conversations to which I have previously subscribed, which won't allow me to have an overview of a group of all-new conversations.

I don't object to having available the flow you describe, loading just one conversation and filtering out the rest, as long as the other flow is still possible in the same convenient way as it exists now.

There will definitely still be a "default view" situation, that can act the same way as the current listings.

It's just a case of making a single page (board) "subscribe" to all the relevant (eg AfD) tags, and then we humans look at that page to get the full/unfiltered version, the same as we do currently with transcluded sub-pages.

It's a different technical setup, but results in the same-as-current output (plus the additional output options).

(Except for the TableofContents, which isn't in the current prototype, but should be very easy to add.)

• How is the design of this default view? Is it equivalent to a Table of Contents overview, showing only the titles of each section?
• Will there be first- and second-level section titles in Flow threads? (and third-level, and fourth...)
• If so, is it possible to filter threads so that only threads up to sub-level X are visible in the overview?

If the answer to those three questions is yes, then the new view can indeed act the same way. If not, we'd be missing valuable functionality.

Good points. To clarify, you're asking if

• the ToC will be able to look as useful as this: http://i.imgur.com/Mvmn40f.png
• and if an equivalent to w:Template:TOC limit will exist.

Hopefully that's correct, and will therefor get the right details in front of the devs. :)

Exactly, that's what I'm talking about, thanks.

Given that Flow will be based on Javascript, it should be easy to have a collapsible ToC that works as an outline, i.e. it begins folded and the user unfolds the title of sections that are marked as having a level of subsections under them.

I haven't seen anything that suggests that this design decision has been made yet. Perhaps you should ask Jorm (next week, after he's back from Wikimania) about the current thinking on TOC-like options.

Thanks, I'll try to revive the topic next week.

Responding to Cyclopia:

How nice. I was going to refactor my talk page so that I archive stuff by content instead than by date, and now someone comes and breaks it. Wikitext is flexible and easy. This thing is not.

Why should you need to do this? Archived is archived. I think you may be conflating the concept of "curation" with "closing". Curating content would be done by adding tags to the topics that mark them "by content" (e.g., you tag topics that are about articles with, say, "#article", and maybe you tag personal conversations with "#personal"). You would then search for those tags, and the topics would come up.

Why would anyone want to do this? Because we can???

Do you even realize how much power you're taking away from the community by creating a new system from scratch optimized for just a few use cases, instead of building it on top of the existing platform?

I'm sorry for you if the WMF put you in a situation where you must build a tool that can't be up to users' expectations with the resources you've been given. But you should at least understand where the inevitable backlash will come from when this limited system is imposed upon the editors that grow accustomed to a much more powerful, if clunky tool.

It would be good if you can tag threads DO NOT ARCHIVE (perhaps in a per-thread common area) since right now, on en.wiki bots sometimes archive active processes, that have to be then brought back out of archives and a timestamp added to make it ignore that (most commonly with RfCs, split discussions, merge discussions, and move discussions)

Will it be possible to transclude comments in other pages? As long as underneath everything they are still messages that can be combined with other messages, people will still find elegant ways to curate them into organized views.

This is different from searching, which will always produce a search-result-styled view of the results.

A current topical archive might include some text from a project page, a collection of comments in a section below it, and some analysis/commentary on the results -- illustrated with some images or file-thumbnails floating along the side. How would someone do this refactoring, if the comments were created in Flow?

I think you'd "tag" each of the things that you wanted on the curated "page". It would automatically update if anyone added another comment to a tagged discussion.