Thanks Erik for your mindful comment. Such high level technical, social and strategic vision is rare to find. It deserves being placed in a prominent position for increased visibility, and it helps in building bridges with the community.
Inter-wiki conversation sounds indeed like a killer feature in reference to discussion, and you're right that tags would increase the flexibility for definition of conversation-based workflows by increasing its granularity. On 9 September 2014 11:55, David Gerard <dger...@gmail.com> wrote: > (Wiki talk pages don't have a unit really, which is their blessing for > flexibility and curse for usability.) > So much this. Though it doesn't need to be that way; that's not an essential property of wiki systems, although it may be for Mediawiki. I've mentioned MS OneNote because it's an example of a full wiki-like environment where the unit of content is the multimedia element, and pages work as whiteboards - collages of such media items, that may include collaborative text and individualized comments, both attributable to their authors. The tool keeps track of each independent part an allows them to be merged or split by simple copy/paste operations, through a clever UI trick that highlights which part is currently being edited at any time. Erik, would it be viable to use the Flow architecture to use topic threads as media elements?, in such way that: - topics or individual comments can be embedded as items within wiki blackboards - changes to comments are shown in the history of the blackboard container (with full diff support for the blackboard as a whole) If those functions are viable, it would solve most or all of my "loss-aversion" "spider sense", as it would show a clear path to grow the platform into a truly flexible tool for collaborative creation, not just a conversation and community-building system as it seems to be planned from the information which is available so far. On 9 September 2014 11:45, Erik Moeller <e...@wikimedia.org> wrote: > On Mon, Sep 8, 2014 at 12:22 AM, David Gerard <dger...@gmail.com> wrote: >> On 8 September 2014 05:46, John Mark Vandenberg <jay...@gmail.com> 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? > > 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@lists.wikimedia.org > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, > <mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe> _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>
