Topic on Talk:Flow Portal/Archive2

I would like to see a section on the main page outlining the strengths of the existing system, and what will be done to preserve them, build on them; or if they will be abandoned, why that is necessary or valuable. (I of course do not deny the major drawbacks, as described.)

One thing that comes to mind is the "talk page stalker" dynamic that so often leads to unexpected spontaneous collaboration. I'm sure there are others, but this one especially comes to mind. Under Flow, will there be an easy way to eavesdrop on, and jump into, conversations involving the people with whom you work closely, admire, etc.? If not, is there a solid reason for thinking that will be OK?

Every discussion that someone else is involved in would be tagged with their username, as I see it (just as logs are, if you want to search logs by user). So yes, you could visit the stream of just those interactions. Right now, you can in theory search an individual user's contribs by namespace and see all of their edits to [user talk] pages. In this setup, as I understand it, you would be able to search for all interactions between users involving that user. (effectively the same thing).

Yes but what's not totally clear is whether you can "subscribe" to the conversations of a user (messages to/from) i.e. "watch the user" (using the bugzilla term): this should be clarified. In theory it would be even easier with this proposed system, because – as you said – they're all tracked and they wouldn't rely on the fact that they happen on the user talk you're watching.

A requirement for this is that no such a thing as private messages/"notifications" exist. This is very important, and another thing that should be highlighted in the document. Kaldari said that only non-persistent messages are going to be private notifications, for instance "page A has been linked from page B" which adds nothing to page B's history; but this is not very clear/well defined in the document.

I'd like to clarify the things I'm interested in here. The order of these is significant, it goes from most general to most specific:

1. The people undertaking a project to replace/upgrade a major software feature should carefully think through (among other things) the strengths of the existing feature, and whether or not they can be preserved.
2. The people undertaking the project should put that analysis on display in a clear way (i.e., it should not be necessary for the reader/community member to dig through various wiki pages to learn about the fundamental design goals and the fundamental design challenges).
3. Talk page stalking: probably too specific for this discussion; it was meant only as an example. (However, it may be worth noting that even after these explanations, I'm having a hard time picturing how, as an end user, information about my friends' edits and notes left for my friends would be presented to me.)

Pete, the monthly status says «Mid-month saw Kim Schoonover begin user research regarding how user-to-user talk pages are handled», so maybe by digging wikis, google docs, etherpads and mailing lists enough you may find the "strengths of existing system" documented somewhere.

Yes, you will be able to "talk page stalk" as it were. Even better, actually.

And I'd argue that there are no strengths of the existing system, only interesting work arounds for its flaws.

What is interesting or valuable about the workarounds? What do they reveal about how people prefer to collaborate? Knowing the way you work, I am sure you've asked questions like this, but I think your thinking on this needs to be on prominent display if community buy-in is desired. I'm not looking for answers here in discussion -- my point is that the description of the project needs to put this stuff on display, or nobody outside the core group working on the feature will understand or fully buy into its value, nobody outside a core group will be in a position to offer useful input along the way. I am pretty sure this kind of communication is the key to getting genuine community buy-in in the long run.

An example of the kind of overview/conversation-starter that works: http://lists.wikimedia.org/pipermail/wikimediaannounce-l/2011-September/000238.html and a helpful evaluation of what came before: meta:Talk:Terms_of_use#Reasons_for_the_New_Terms_of_Use

One of the things from the bare-wiki discussion method that I miss in LQT is the ability to fully edit other's posts, specifically signatures* and dates. I do this quite a bit when organizing old talk pages, with threads in incorrect pages, incorrect order, unsigned, unmerged, etc. Forgery needs not be a concern since the whole edit history is available, and small marks can be added to make it clear the date or signature have been edited, just like LQT currently marks that the content of a post has been edited.

* In LQT, a user can edit their own signature if they edit the post after it's first saved, but editing others' sigs would be a potentially useful feature, as described above. Dates can't be edited by anyone, apparently.

Talk page are used for other purposes in addition to sending messages to a person, or joining in a discussion.

In my own work in WP, I normally go to a user talk page when there is a problem with their contributions; what I will say there can depend very much on what else I find, first there, and then in their contribution history. The present system works extremely well for this., except when they delete things from their talk p., and if I suspect this, I need to check also their talk p. history.

There are also some people whose talk p. is watched by a very large number of people--sometimes several hundred , most of whom do not really plan on posting there, but want to see what is being discussed there, under the assumption that some of what they find out about may be interesting.

I'm concerned that the emphasis on specific information flow may be damaging to general project-wide awareness.

Absolutely valid point. With the current system I leave a message on someones talk page and add it to my watchlist to see if he responds. Often the initial question is solved but a very similar follow-up question by another editor is posted (but in a new section). If I had not watched the whole talk page (and I probably won't do this with the possibilities of the new system) I'd never know about this new question, which may be enlightening for me or easy for me to answer.

"Talk page are used for other purposes in addition to sending messages to a person, or joining in a discussion."

This first point is my primary reason for arguing that the "Board" remain distinct from the "Feed". The fact that Boards will be used as "quick glances" into the life of an editor is super-important to me. We have been discussing what other things might need to appear on the board in addition to discussions. Block noticies? If they are an administrator, should we indicate that they have performed administrative actions (e.g., "Bob blocked Vandal23342")? What about main space contributions?

These are the kinds of questions that we're wanting answers to.

(And, by the way, it is currently planned that deleted posts and topics will remain on the board, just noting that the topic was deleted and by whom. So you won't have to check the history to see that this has happened.)

"There are also some people whose talk p. is watched by a very large number of people--sometimes several hundred , most of whom do not really plan on posting there, but want to see what is being discussed there, under the assumption that some of what they find out about may be interesting."

This is exact and precise use-case for being able to subscribe to other users' boards. The Feed/Subscription model will actually make doing this easier, not harder.

The end vision of Flow is not to restrict information flow - far from it. And, in fact, the entire point of the project (from my mind) is to actually increase project-wide awareness.

Right now, if you want to see what's going on with the seven WikiProjects you're a member of, you have to go to seven different pages and see if they've been updated (or view diffs from your watchlist, which is painful). Think about a future point where new posts and new requests on those seven boards automatically flow into your feed. This increases collaboration power.