Talk:Flow/Converting talk pages

Various approaches

(BG: Flow). There are four ways to convert talk pages to Flow:

1. Do not convert. Lose content.
2. Shove old content to a non-Flow archive. (This one, coming from the Flow Team (now Collaboration Team))
3. Move each old talk page discussion page (a page, and an archive) as a single Flow topic which does inherit its history. Then manually — semi-automatically to a large extent — split it into topics and properly indented messages, so that it's eventually converted to the Flow format.

   This means Flow should be able to:

   • Move a thread to another page
   • Move a comment to another thread (in the same page/in another page)
   • Split a thread in two.
   • Merge two threads.
   • Split posts
   • Indent and outdent posts
   • Re-sign posts for another person
   • Split one thread in two threads (and give a new topic the new one)
   • Support nested threads (2 threads inside of one with relevant subheadings)
   • Edit timestamps on other Flow posts (i.e. I split it into two, but I would like to set the new post timestamp to the real old ts, not to now)

4. Do it fully automatically. Parse signatures, indent with ":" and "*", etc.

(Tracked at T76682 and T78253). I would like to know what we would like to have. Gryllida 23:56, 11 December 2014 (UTC)

• I'm personally leaning toward #3, because #1 is unacceptable, #4 is unrealistic (people already tried it before), and #3 isn't too much work — these refactoring featuers are needed for processing a moderately bug RFC anyway. #2 has the disadvantage that old conversations do not start "Flowing". Gryllida 23:56, 11 December 2014 (UTC)
• Wouldn't #3 mess up the edit history? What happens when non-talk content appears in a talk namespace, such as w:WP:AFC submissions? I think that #3 would cause too many problems and that #2 is the only acceptable option. --Stefan2 (talk) 00:07, 12 December 2014 (UTC)
  • Stefan2: No. Each new post would say "I was split from XXX" in its first history entry, where XXX is a link to the original post which inherits the history from the original classic talk page. Leaving the history one more click away is fairly common, when archiving, for example. Gryllida 00:11, 12 December 2014 (UTC)
  • What happens to WPTalk:AFC/*? This is a question for #2, #3, and #4. We would have to find a way to blacklist that. This problem isn't unique to #3. ;-) Gryllida 00:13, 12 December 2014 (UTC)
• Wouldn't the most useful way to deal with the imposition of Flow be to move the old talk page to a non-Flow namespace and conduct discussions there from then on, thus keeping discussions away from Flow? --Pi zero (talk) 01:03, 12 December 2014 (UTC)
  • For wikis which don't need Flow: I hope they there will be a way to opt out. Right now I'm concerned about proper migration to Flow for those wikis which want it. I was told some wikis (not a Wikimedia project) were okay with using and preferring Flow on talk pages, while retaining old discussions in wiki markup. This is something I'm considering a problem I'm trying to avoid happening here at Wikimedia projects. Gryllida 03:32, 12 December 2014 (UTC)
• I agree that #1 is unacceptable and #4 is unrealistic, and also unnecessary. Somewhere between #2 and #3 would work for me. What I mean by that is that there is no immediate need to convert a talk page until someone wants to add content to the page. It is at that point that a conversion is necessary, or at least desirable. If the simple solution is that old content is a single Flow topic that could be split on demand with guided editing or formatting hints, then important conversations could be converted, and the thousands of others that are merely historical don't need to be converted. Don't shove them anywhere. Let them sit until content is added or someone comes through and converts them. -- Dave Braunschweig (talk) 01:11, 12 December 2014 (UTC)
• Discussions should never be deleted or converted into Flow. They should be kept as they are. Flow should be an addition, not a replacement. --NaBUru38 (talk) 00:54, 16 December 2014 (UTC)
• I strongly suggest that any talk of converting talk pages to Flow should wait until we volunteers have accepted Flow. Forcing us into using it with no way to back out the changes will be a replay of the mess that accompanied Visual Editor & Media Viewer -- only nastier. -- Llywrch (talk) 23:58, 16 December 2014 (UTC)

Break 2

The task is separated into some distinct questions apparently.

1. What to do with stuff in talk namespaces which is permanently archived, or not a talk page?

   (A) Leave it alone. (B) Move it to Flow.

2. When actually in talk format and not archived, where should old content go?

   (A) Delete. (B) Leave it alone; move to a subpage. (C) Move it to Flow board.

3. If (C), then what of it to move it to a Flow board.

   (A) All of it. (B) Move partially, only as much as people want to revive a discussion.

4. If (C), then how to move it to a Flow board.

   (A) Semi automate it. Originally in the shape of 1 Flow topic per page (talk page, talk archive 1, talk archive 2, etc). Then people unbork it using semi-automated refactoring tools provided by Flow.

   (B) Semi automate it. Originally in the shape of 1 Flow topic per page section (talk page section 0, headline from section 1, ...., talk archive 1 sec0, headline from talk archive 2, etc). Then people unbork it using semi-automated refactoring tools provided by Flow.

   (C) Semi automate it. Originally in the shape of 1 Flow topic per page section. When can't define indent, leave it in markup of the post, but not in Flow. When can't define author, sign post by dummy account and today date permanently. Let people fix later by refactoring tools.

   (D) Fully automate it. Originally in the shape of 1 Flow topic per page section. When can't define indent, leave it in markup of the post, but not in Flow. When can't define author, sign post by dummy account and today date permanently. Polish the process. Do not implement refactoring tools; when the automatic thing fails, make people pull hair and do Flow database fixes by hand.

(Refactoring tools is defined one section above). Gryllida 03:32, 12 December 2014 (UTC)

• I'm inclined 1A (I think we all agree here), 2C; 3A (I feel not converting it would be a barrier for people participation in old discussions); 4 A, B, or C. Gryllida 03:32, 12 December 2014 (UTC)

• I have some difficulty with the premise here. The question is, I understand, how to convert in those cases where one has reason to convert. I truly don't mean to be difficult, but it seems to me that in order to make an informed decision about how to handle the conversion, one has to understand why one is converting. All things being equal, Flow would be undesirable; so if we're considering a situation where Flow is desirable, evidently all things aren't equal: something has changed from the generic situation, and since I can't envision what it would be that changed, I'm distrustful of suppositions about what is and isn't easy. About the only thing I expect we can safely suppose is that we don't want to lose information ( 2A ). --Pi zero (talk) 05:07, 12 December 2014 (UTC)

To remind, 'refactoring tools' is defined like this:

This means Flow should be able to:

• Move a thread to another page
• Move a comment to another thread (in the same page/in another page)
• Split a thread in two.
• Merge two threads.
• Split posts
• Indent and outdent posts
• Re-sign posts for another person
• Split one thread in two threads (and give a new topic the new one)
• Support nested threads (2 threads inside of one with relevant subheadings)
• Edit timestamps on other Flow posts (i.e. I split it into two, but I would like to set the new post timestamp to the real old ts, not to now)

--Gryllida 04:49, 7 April 2015 (UTC)