Re: [Wikimedia-l] To Flow or not to Flow

[Gerard Meijssen]

Hoi,
We includes anyone who wants to be involved and does not exclude him or
herself by his or her own actions or choices.
Thanks,
GerardM


On 6 September 2014 07:09, Pete Forsyth petefors...@gmail.com wrote:

 On Fri, Sep 5, 2014 at 9:49 PM, Erik Moeller e...@wikimedia.org wrote:

  Fundamentally, there's one key question to answer for talk pages in
  Wikimedia projects: Do we want discussions to occur in document mode,
  or in a structured comment mode? All else flows from there snip


 I think there's actually a much more fundamental question:

 Who is we?

 -Pete
 [[User:Peteforsyth]]
 ___
 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

Re: [Wikimedia-l] Next steps regarding WMF-community disputes about deployments

[Erik Moeller]

On Fri, Sep 5, 2014 at 10:42 PM, Risker risker...@gmail.com wrote:
 The major deficiencies that have long been identified in the current
 discussion system (and that can be addressed by technology) are all able to
 be addressed in MediaWiki software or by extensions. Automatic signatures
 have been done by bots for years; indenting could be added to the editing
 function gadget and moved to an extension; much work has already been done
 on graceful resolution of edit conflicts.  The ability to watchlist an
 individual thread or section of a page is more challenging but, I have been
 told, still possible.

Let's just acknowledge that the limitations of what can reasonably be
layered onto wikitext-based representation of comments have not been
fully explored, rather than jumping to conclusions about what's easy
to address and what's hard. As noted separately, I agree it may be
worth pushing the boundaries a bit more on this, if only to know
exactly where they are, and to achieve short term improvements.

 Automatic signature (something that is currently
 functional on Flow, but is not customizable) turns out to be more of a
 challenge when users are widely known by a signature line that doesn't
 match their username,

I've not talked to them about it explicitly, but I'd guess that the PM
and the UX folks have a negative aversion against custom signatures
because of their free-form nature (including sometimes
layout-exploding ones). Perhaps a middle-ground can be found here,
with some more sanitization applied to prevent some of the
sigs-from-hell occasionally found. Other than that I can't see a good
reason to not just show them when they're set, and it's certainly
technically trivial to do so.

 and there is no method by which users can add an
 explanatory note to their signature such as formerly known as
 User:Whatever.

From the point forward that Flow is in wide use, a user rename would
be automatically reflected in old comments if desired, much as it is
reflected in old edits. But if signatures were supported, as above,
you could still use them for these types of indicators, as well.

 The more efficient indenting has reduced possible
 indents to three levels, without exception;

This seems to be the most religious topic when it comes to Flow. The
database stores all threading information. It'd be trivial to expand
the threading level if that's more popular and usable.

I've heard the argument that this doesn't work on mobile, but we could
just set a different threading level on mobile.

I think it's worth experimenting with flat pages (with quoting) for
certain purposes, and Danny wants to, but it strikes me as most
reasonable to start with something that more closely resembles talk
pages as they are now (which is why we did that with LQT originally).

 Rigid predictable technical
 restrictions on who can edit what has resulted in inability to remove
 posts that are obviously unsuitable (there's no undo or revert
 function), replaced with a hide function that can only be applied by
 certain users that's practically a red flag for people to look-see what the
 problem edit is.

The team has pretty strong arguments why they don't want posts to be
editable (the gist is, they fear that no other discussion system does
this, and it will freak people out -- they see the introduction of a
new system as a good opportunity to reset expectations). I personaly
am not religious about it; when we built LQT we made posts editable
(and made it clear who had edited someone else's posts) to preserve
that normal aspect of wiki-style editing. I think we should keep
talking about this.

I've not seen it named as a dealbreaker for small scale deployments.
The architecture can easily support both models.

 At the core is whether or not there is value in developing a discussion
 system that is radically divorced from any other interface used by the
 system.

That's a legitimate question, although it's not as radically
divorced as you would think; ultimately it'll use the VisualEditor
(probably with a simplified toolbar by default) just like Flow does.

As for the claim that the team never looked at current use cases,
having spent hours in rooms with them where they pored over printouts
of hundreds of talk pages, analyzed use cases, categorized them,
prioritized them, etc., I can assure you there's been a lot more of
this kind of thinking than you appreciate. There also have been round
tables and other outreach efforts, and a dedicated community liaison
from the start. Still, I don't think there's been enough talking to
each other -- we're still getting better at doing that, collectively,
and trusting in the value of conversation even when there's a lot of
noise and a lot of heat.

This is an opportunity for me to remind folks that the cost of heat
(accusations, insults, reverts, etc.) is that people withdraw. We
(WMF) have to do our part to prevent things from getting heated, but
I'd ask folks who notice this kind of thing 

Re: [Wikimedia-l] Next steps regarding WMF-community disputes about deployments

[Erik Moeller]

On Fri, Sep 5, 2014 at 11:13 PM, Erik Moeller e...@wikimedia.org wrote:

 That's a legitimate question, although it's not as radically
 divorced as you would think; ultimately it'll use the VisualEditor
 (probably with a simplified toolbar by default) just like Flow does.

.. just like article editing, I mean - you'll have a choice between
VE/wikitext, probably with a toolbar that's optimized for comments
(perhaps advanced tools available when needed).

Moreover, I think the idea that talk pages are actually an intuitive
system once you're familiar with editing articles is both unproven and
contradicted by all user research into article editing and talk pages.
Users discover wikitext incrementally, and they understand it to be
kind of like HTML. They think of it as a document formatting
language.

When they first discover talk pages, they have to learn a whole new
set of conventions -- the notion of signing and indenting your own
comments, the idea that in order to participate in a thread you have
to edit it, etc. That is a system divorced from editing, and it's a
mental model unlike any other discussion system.

The argument would be more supportable if you could layer a decent UI
on top of wikitext-based talk pages, as you suggest. But if you can do
that, you'll end up with a UI that introduces many of the same
conventions that Flow introduces, just with a hard limitation on some
of the additional capabilities and conveniences you can introduce. It
may be, as I acknowledged, still worth doing - even as an interim step
towards Flow.

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

Re: [Wikimedia-l] To Flow or not to Flow

[Yann Forget]

Hi Erik,

While I have a lot of reservations about the usefulness of the Media
Viewer, I agree with you that talk pages are now inefficient for all
and complex for new users. Personally I am willing to try any system
which offers the features missing in the current talk pages, specially
removing the need for manual signatures.

Regards,

Yann


2014-09-06 10:19 GMT+05:30 Erik Moeller e...@wikimedia.org:
 Hi all,

 I'm breaking out this discussion about Flow/talk pages (apologies for
 repeatedly breaking the megathread, but this is a well-scoped subject
 which deserves its own thread).

 Fundamentally, there's one key question to answer for talk pages in
 Wikimedia projects: Do we want discussions to occur in document mode,
 or in a structured comment mode? All else flows from there (pun
 intended).

 == Document mode ==

 There are not many examples of document mode discussion systems beyond
 wikis. You sometimes see people use collaborative realtime editors as
 such, because people want to talk in the same space where they work,
 but Google Docs provided alternatives (a pretty powerful
 comments/margin system and built-in chat) early on, for example.

 The current talk page system is a document mode system. Individual
 comments have unclear boundaries (a single transaction can result in
 multiple comments, signed or unsigned; indentation levels are
 unpredictable and often inconsistent). All the joys and pain points of
 working on the same document are present (a heavily trafficked talk
 page will see many edit conflicts). You can't easily show comments in
 multiple contexts (cross-wiki, via email, as a notification, etc.)
 because of the boundary problem.

 You could try to make a document mode system work better. On the basis
 of wikitext, you can do some very basic things, like the new section
 link I added to MediaWiki back in July 2003 [1], when I wrote: This
 feature could also be the first stage of a more sophisticated
 discussion system, where the next stage would be auto-appending
 signatures and providing a 'Reply to this' link after each comment.

 But due to the aforementioned unpredictability, even making a reply
 link work consistently (and do the right thing) is non-trivial. You
 can get some of the way there, and the Wikipedia Teahouse actually has
 a gadget, written by Andrew Garrett (more on him below) that does
 precisely that.

 https://en.wikipedia.org/wiki/Wikipedia:Teahouse/Questions

 Note the Join this discussion link. It does give you a pop-up, and
 posts the comment for you in the right place, with indentation (it
 does not auto-sign, but instead tries to teach users the signature
 habit which they'll need to use on other talk pages).

 It may be worth doing more research and development on this, to see
 just how far we can get without changing the fundamentals, since a
 wholly new system may still be years out for wide use. However, there
 are inherent limitations due to the lack of a predictable and
 consistent structure.

 You could go further down the road of a document mode or hybrid
 system, but IMO not without introducing fully predictable comment
 markers (think comment id=234234Bla ~~~/comment) -- which would
 pollute the wikitext, be fragile (e.g. accidental or deliberate
 corruption of identifiers), and probably be considered unacceptable in
 a system that still supports unlimited wikitext editing for those
 reasons.

 == Structured ==

 I personally gave up on patchwork on top of talk pages about 10 years
 ago. The advantages of having comments clearly identified as such are
 many:

 - Display comments in arbitrary order, arbitrary threading style
 - Search comments across date ranges
 - Search comments by author
 - Track comments as comments, not as diffs
 - Monitor changes at any part of a comment thread
 - Display comments independent of a given document (e.g. email,
 cross-wiki, etc.)
 - Display comment metadata in different formats easily (e.g. timestamps)
 - Update author names after a username change without having to update 
 documents
 - Enables third parties to build new UIs (think Wikiwand for comments)
 more easily
 - Ability to tag/categorize individual comments/threads
 - and more.

 I identified some of these reasons when I wrote the proposal for
 LiquidThreads in October 2004 [2]. At that point, the Wikimedia
 Foundation had 0 employees, and this was too large an effort to likely
 get traction just from ad hoc volunteering. So after some time, I
 managed to persuade third parties to fund development, including
 Wikicities and WikiEducator, and found a developer to do the initial
 work, David McCabe. David did a good initial job but the system had
 many known issues and was only deployed at a small scale.

 At the same time, I think there were many things about even the
 original design that were good (and aren't found in most other forum
 systems):

 - It preserved headers on top of the threaded conversation as
 community-editable wiki-like spaces
 - 

Re: [Wikimedia-l] Upload Wizard work (was Re: Next steps regarding WMF-community disputes about deployments)

[Yann Forget]

Hi,

2014-09-04 12:34 GMT+05:30 Erik Moeller e...@wikimedia.org:
 On Sun, Aug 31, 2014 at 8:59 AM, Yann Forget yan...@gmail.com wrote:
 the most urgent and important thing is to fix the
 UploadWizard.

 This is indeed underway, and has been for some time, with focus on bug
 fixes and code quality improvements.

 https://gerrit.wikimedia.org/r/#/q/UploadWizard,n,z

 Recent work on Media Viewer has been primarily UX prototyping and

I suppose you mean the UploadWizard?

 validation of the prototype. Based on user research and feedback,
 we'll implement only very tightly scoped improvements that have been
 validated in the prototype or that require no UX validation (e.g.
 attribution and performance improvements).

 The best place to follow all the work the team is doing is the
 multimedia mailing list:
 https://lists.wikimedia.org/mailman/listinfo/multimedia

 Erik

 --
 Erik Möller
 VP of Engineering and Product Development, Wikimedia Foundation

Regards,

Yann

___
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

Re: [Wikimedia-l] Next steps regarding WMF-community disputes about deployments

[Pine W]

Something that that would be useful is a video demonstration of Flow in
action.

I like the goal of VE in principle, and I hear lots of comments to the
effect that it is improving over time. MediaViewer seems to be on the road
to improvement. I understand where both of those are headed. But I am
trying to get a mental picture of Flow from what I've read. A video would
be worth a thousand words. If Flow helps us to organize discussions in ways
that makes them easier for everyone to follow, that will be good. If Flow
disrupts constructive ways of having conversations and is not intuitive,
there will be yet another round of power users asking why time and money
are being spent on projects that miss the biggest pain points and may cause
more pain. I am hoping that Flow will be an improvement, and I think a
video demo or mockup of Flow would be helpful to evaluate if Flow's design
is likely to produce the intended results.

Pine


On Fri, Sep 5, 2014 at 11:29 PM, Erik Moeller e...@wikimedia.org wrote:

 On Fri, Sep 5, 2014 at 11:13 PM, Erik Moeller e...@wikimedia.org wrote:

  That's a legitimate question, although it's not as radically
  divorced as you would think; ultimately it'll use the VisualEditor
  (probably with a simplified toolbar by default) just like Flow does.

 .. just like article editing, I mean - you'll have a choice between
 VE/wikitext, probably with a toolbar that's optimized for comments
 (perhaps advanced tools available when needed).

 Moreover, I think the idea that talk pages are actually an intuitive
 system once you're familiar with editing articles is both unproven and
 contradicted by all user research into article editing and talk pages.
 Users discover wikitext incrementally, and they understand it to be
 kind of like HTML. They think of it as a document formatting
 language.

 When they first discover talk pages, they have to learn a whole new
 set of conventions -- the notion of signing and indenting your own
 comments, the idea that in order to participate in a thread you have
 to edit it, etc. That is a system divorced from editing, and it's a
 mental model unlike any other discussion system.

 The argument would be more supportable if you could layer a decent UI
 on top of wikitext-based talk pages, as you suggest. But if you can do
 that, you'll end up with a UI that introduces many of the same
 conventions that Flow introduces, just with a hard limitation on some
 of the additional capabilities and conveniences you can introduce. It
 may be, as I acknowledged, still worth doing - even as an interim step
 towards Flow.

 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

Re: [Wikimedia-l] Upload Wizard work (was Re: Next steps regarding WMF-community disputes about deployments)

[Erik Moeller]

On Fri, Sep 5, 2014 at 11:35 PM, Yann Forget yan...@gmail.com wrote:
 Hi,

 2014-09-04 12:34 GMT+05:30 Erik Moeller e...@wikimedia.org:
 On Sun, Aug 31, 2014 at 8:59 AM, Yann Forget yan...@gmail.com wrote:
 the most urgent and important thing is to fix the
 UploadWizard.

 This is indeed underway, and has been for some time, with focus on bug
 fixes and code quality improvements.

 https://gerrit.wikimedia.org/r/#/q/UploadWizard,n,z

 Recent work on Media Viewer has been primarily UX prototyping and

 I suppose you mean the UploadWizard?

No, I meant that we've done a bunch of work in parallel in August:

- Pau Giner, Abbey Ripstra and Fabrice Florin have primarily focused
on prototyping and validating a bunch of changes to media viewer, with
some help from the dev team. The changes that have tested well are now
being implemented very rapidly.

- The multimedia dev team has spent a fair bit of time doing some
initial UploadWizard refactoring and code cleanup. We've also
contracted Neil Kandalgaonkar, the original UploadWizard developer
(who left WMF a while ago), to help out a bit and provide some history
on the project.

- In addition, the dev team has focused a fair bit on improved
instrumentation (measurement of user actions, success/failures), both
for Media Viewer and Upload Wizard.

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

Re: [Wikimedia-l] Next steps regarding WMF-community disputes about deployments

[Erik Moeller]

On Fri, Sep 5, 2014 at 11:41 PM, Pine W wiki.p...@gmail.com wrote:
 Something that that would be useful is a video demonstration of Flow in
 action.

That could be handy, Pine. But sometimes you can't demonstrate all
benefits yet, because they don't even exist in the implementation yet
-- only in the foundations of an architecture. And sometimes you can
show the idea of a benefit, but people will look at the current
implementation and hate some aspect of it, and fail to imagine a
version of it that would be beneficial.

To give an example of the latter, Flow already has the ability to give
thread-level notifications of responses. But the first implementation
of notifications was very spammy (generated too many notifications),
so people who looked at it said I don't see the benefit! It's just
spammy!. Love em or hate em, sites like Facebook spend years tweaking
the algorithm for every one of their features (newsfeed,
notifications, etc.) to get the best results from their perspective.
It takes time to get this right -- and the initial reaction may often
be No, this sucks because, well, it's not quite right yet.

Fundamentally, I'd ask people to relax a bit regarding Flow. Nobody's
planning to push this one out radically. Today we saw some on-wiki
drama because a new test page was turned on. For something like the
en.wp Teahouse, I'd want the hosts to be fully on-board before
converting it over (and the rest of the community to not oppose it).
If that's not doable, we can focus on other use cases first. It's
early days and this one's a long haul -- just like VE. But we
shouldn't shy away from a problem just because it's hard.

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

Re: [Wikimedia-l] Next steps regarding WMF-community disputes about deployments

[Gerard Meijssen]

Hoi,
I have used LiquidThreads and the current talk pages for too long. I prefer
LiquidThreads ANY day warts and all over the talk pages.

Ok this discussion is about automated discussion environments and lets keep
to that subject. As you may know, translatewiki.net uses LQT. It is
therefore quite a good environment for learning about the use of Flow. It
is truly multi-lingual; by definition. It eats its own dog food; it is
where the localisation of Flow and any other MediaWiki software happens.

Conversion software is being developed and it will be great when it and
flow is at the stage where it can bring Flow to translatewiki.net. One
additional benefit is that the twn community and people like Siebrand are
well able and fearless. When they have issues they will be precise, topical
and in a language that will be understood by the developers of Flow.

When twn is happy using flow, you can be sure that technically it suffices
and that it did get proper attention from the perspectives of all the
languages that are actively maintained.
Thanks,
 GerardM


On 5 September 2014 23:43, Tim Davenport shoehu...@gmail.com wrote:

 I really don't like the way that people are referring to Flow as a done
 deal with an inevitable roll out. Nothing remotely close to workable
 software has been produced, no case has been made that the purported
 problems being addressed by this top-down software project are valid issues
 in the community, the range of unintended effects that will be cause by the
 mass archiving of talk pages and move to a new flashy system hasn't been
 properly assessed.

 With Visual Editor, there was a clear need for WYSIWYG capabilities —
 although the software rolled out was grossly inadequate and the roll out
 process hamhanded (not to say incompetent). With Media Viewer, at least
 there is a clear benefit to a certain percentage of WP readers to offset
 the inconveniences resulting from mildly inadequate software. With Flow we
 are looking at the potential of grossly inadequate software with no
 apparent saving graces other than the fact that the old software is old
 and the new software will be new and that things will look nice.

 If this is done wrong, it will be a catastrophe for WMF far bigger than
 what happened with VE.

 Wil Sinclair, an enthusiast for the LiquidThreads/Flow mechanism for talk
 pages, is in an excellent position to give us some A/B numbers for
 participation at his site, with in without LiquidThreads being imposed from
 above.

 How did that work out with participation levels at the OffWiki site, Mr.
 Sinclair?

 How many very active editors has the convenient LiquidThreads mechanism
 generated for your site?

 How many edits have taken place in the month after LiquidThreads was
 installed over community objections versus the month before it was
 installed?

 Has the clean up process been easy reconverting to MediaWiki without the
 LiquidThreads extension?

 Bottom line: OffWiki site participation was blown up by a unilateral move
 to LiquidThreads by the tech department.

 Observe and learn.

 Tim Davenport
 Carrite on WP /// Randy from Boise on WPO
 Corvallis, OR




 ===

 Wil Sinclair wrote:
 This somewhat circuitously brings us back to the subject. We have a
 chance to rollout Flow the right way. There are some questions that
 come to mind that might tell us if we're headed for a big win or a
 bigger debacle:

 1) Is the WMF working with the community as closely and substantially
 as possible to make sure Flow is ready for primetime?

 2) Is the community preparing itself for a major change, not only in
 interface, but to some degree in wiki-philosophy about how discussions
 are conducted- not to mention the notion that, while wiki software can
 do almost anything involving asynchronous online communication, it
 can't do everything as well as other interfaces?

 I think Flow will be particularly challenging. I deployed Liquid
 Threads on another site. I liked the threaded interface, as did
 others. But overall it was roundly rejected because it was harder to
 search (I only found out you have to add the namespace to the
 searchable namespace in LocalSettings.php later), and it invasively
 took over all discussion pages, among other headache. Problems like
 these could easily be addressed before a rollout, but they should be
 addressed as early as possible. It is notable, however, that the more
 our users used it, the more they seemed to like it.

 What can we do to make the Flow rollout as smooth as starting '''now'''?

 ,Wil
 ___
 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: 

Re: [Wikimedia-l] Next steps regarding WMF-community disputes about deployments

[Isarra Yos]

On 06/09/14 06:13, Erik Moeller wrote:

On Fri, Sep 5, 2014 at 10:42 PM, Risker risker...@gmail.com wrote:

The major deficiencies that have long been identified in the current
discussion system (and that can be addressed by technology) are all able to
be addressed in MediaWiki software or by extensions. Automatic signatures
have been done by bots for years; indenting could be added to the editing
function gadget and moved to an extension; much work has already been done
on graceful resolution of edit conflicts.  The ability to watchlist an
individual thread or section of a page is more challenging but, I have been
told, still possible.

Let's just acknowledge that the limitations of what can reasonably be
layered onto wikitext-based representation of comments have not been
fully explored, rather than jumping to conclusions about what's easy
to address and what's hard. As noted separately, I agree it may be
worth pushing the boundaries a bit more on this, if only to know
exactly where they are, and to achieve short term improvements.


But many of these things have been explored and experimented with. 
That's just it. We have extensions to create a whole new discussion 
system already which get some things right and others no so much, like 
LQT and Comments, and various bots and gadgets that do smaller tasks 
(auto-signing, indentation, cleanup, etc).


Have the successes and failures of the existing approaches and tools 
been considered? Are things LQT got right present in Flow?



Automatic signature (something that is currently
functional on Flow, but is not customizable) turns out to be more of a
challenge when users are widely known by a signature line that doesn't
match their username,

I've not talked to them about it explicitly, but I'd guess that the PM
and the UX folks have a negative aversion against custom signatures
because of their free-form nature (including sometimes
layout-exploding ones). Perhaps a middle-ground can be found here,
with some more sanitization applied to prevent some of the
sigs-from-hell occasionally found. Other than that I can't see a good
reason to not just show them when they're set, and it's certainly
technically trivial to do so.


Signatures that break the page are currently dealt with by yelling at 
the user to fix their sig and then blocking them if need be. I dunno how 
a structured talkpage would necessarily change that, though having the 
signatures automatically tidied might be useful in general, as it should 
at least help prevent unclosed tags. Beyond that what they allow really 
depends on the project, but any structured formatting with sensible 
padding should work fine no matter what they do (I mean, I've never seen 
any issues with that with LQT).



and there is no method by which users can add an
explanatory note to their signature such as formerly known as
User:Whatever.

 From the point forward that Flow is in wide use, a user rename would
be automatically reflected in old comments if desired, much as it is
reflected in old edits. But if signatures were supported, as above,
you could still use them for these types of indicators, as well.


The more efficient indenting has reduced possible
indents to three levels, without exception;

This seems to be the most religious topic when it comes to Flow. The
database stores all threading information. It'd be trivial to expand
the threading level if that's more popular and usable.


How is this religious? Something is needed to show progression, and 
lacking anything else, threading has already been proven to work. Just 
chopping it off has been shown time and again not to (you see it 
particularly often on blog and news comments).



I've heard the argument that this doesn't work on mobile, but we could
just set a different threading level on mobile.

I think it's worth experimenting with flat pages (with quoting) for
certain purposes, and Danny wants to, but it strikes me as most
reasonable to start with something that more closely resembles talk
pages as they are now (which is why we did that with LQT originally).


Formatting the pages as flat with just ids and links to what the things 
are replying to could be an interesting option experiment with, 
especially when you don't have a lot of space. Like boards. Be like 
4chan! Everyone loves 4chan.





Rigid predictable technical
restrictions on who can edit what has resulted in inability to remove
posts that are obviously unsuitable (there's no undo or revert
function), replaced with a hide function that can only be applied by
certain users that's practically a red flag for people to look-see what the
problem edit is.

The team has pretty strong arguments why they don't want posts to be
editable (the gist is, they fear that no other discussion system does
this, and it will freak people out -- they see the introduction of a
new system as a good opportunity to reset expectations). I personaly
am not religious about it; when we built LQT we made posts 

Re: [Wikimedia-l] Next steps regarding WMF-community disputes about deployments

[Erik Moeller]

On Sat, Sep 6, 2014 at 12:23 AM, Isarra Yos zhoris...@gmail.com wrote:
 Have the successes and failures of the existing approaches and tools been
 considered? Are things LQT got right present in Flow?

Some, yes (remember Andrew and Brandon have worked on both LQT and
Flow) -- in other cases the team deliberately made a different call,
and they may have gotten it wrong, or not. Let's reason it through.

Flow has LQT-style headers, for example, and thread-level summaries,
both with a much nicer UX than LQT, but adopting some of the same
principles.

 Signatures that break the page are currently dealt with by yelling at the
 user to fix their sig and then blocking them if need be. I dunno how a
 structured talkpage would necessarily change that, though having the
 signatures automatically tidied might be useful in general, as it should at
 least help prevent unclosed tags.

Sure, some leeway (and some testing/sanitization) makes sense to me to
see what works.

 Formatting the pages as flat with just ids and links to what the things are
 replying to could be an interesting option experiment with, especially when
 you don't have a lot of space. Like boards. Be like 4chan! Everyone loves
 4chan.

*cough*

 Why in the world would posts not be editable? I've never used a platform
 where discussion was important in which users couldn't at least edit their
 own posts (along with mods) where the lack of such wasn't often complained
 about (for instance bugzilla and gerrit don't allow it; moodle and tumblr
 do).

Sorry, I should have been clearer. By default, Flow lets you edit your
own comments, and lets admins edit all comments, just like typical
forum conventions. It just doesn't let everyone edit everything.

-- 
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] [Wikimedia Announcements] Fwd: [PRESS RELEASE] Wikimedia Commons celebrates its 10th anniversary

[Tilman Bayer]

Hi all,

ten years ago this Sunday, Wikimedia Commons went online. We've sent out
the below press release to draw some attention to this occasion, and also
published a separate blog post by Lila which goes a bit more into the
project's history (such as the very first photograph uploaded to Commons):

https://blog.wikimedia.org/2014/09/05/celebrating-the-10th-anniversary-of-wikimedia-commons/


-- Forwarded message --
From: Tilman Bayer tba...@wikimedia.org
Date: Fri, Sep 5, 2014 at 4:54 PM
Subject: [PRESS RELEASE] Wikimedia Commons celebrates its 10th anniversary
To: press-release press-rele...@lists.wikimedia.org


(This press release is also available online here:
https://wikimediafoundation.org/wiki/Press_releases/Wikimedia_Commons_celebrates_its_10th_anniversary
)

Wikimedia Commons celebrates its 10th anniversary

   - *22 million+ images make Wikimedia Commons world’s largest freely
   licensed educational media repository.*

(San Francisco, USA) September 5, 2014 -- This Sunday marks the 10th
anniversary of Wikimedia Commons
https://commons.wikimedia.org/wiki/Main_Page. Its creation was officially
announced on September 7, 2004.

More than 22 million media files have been uploaded by the Wikimedia
volunteer community over the decade since Commons came into being. The
Wikimedia Foundation is extremely grateful to have a dedicated community of
creators and institutions who continue to share their images and other
media so that the project has flourished and will continue to thrive.

Wikimedia Foundation Executive Director Lila Tretikov said: “Many people
don’t know that the incredible, freely-licensed images that illustrate
Wikipedia are curated and maintained by the volunteer community of
Wikimedia Commons editors. Wikimedia Commons is the visual engine of the
Wikimedia projects, and we look forward to its next decade of
contributions, collaboration, and sharing.”

In the past ten years, creators have contributed to Commons in a variety of
ways, including the annual Wiki Loves Monuments contest, which is currently
inviting submissions through the end of September. The Guinness Book of
World Records named Wiki Loves Monuments the largest photo contest in the
world, and it has inspired more 900,000 image uploads since 2010.

On this occasion we also celebrate the partnerships with dozens of cultural
institutions (GLAM) from around the world that have donated portions of
their collections. Their contributions have allowed Wikimedia Commons to
become a vital resource for educational and historical content, and ensured
the increasing depth and richness of the illustrations for articles on
Wikipedia.

The Foundation recognizes the vibrant Wikimedia Commons community, which is
responsible for increasing the availability of freely licensed images and
information to the public. The Commons community takes its role as a
guardian of the rights of creators extremely seriously, working diligently
to confirm authorship and licensing status of the media uploaded to
Commons. This work is reflected in the low number of DMCA takedown requests
received by the Wikimedia Foundation every year.

Erik Moeller, then a volunteer Wikimedian, first proposed the Commons in
March 2004 as a common repository for the images that Wikipedians had begun
uploading to illustrate the free online encyclopedia’s growing collection
of articles. Today, Moeller is the Wikimedia Foundation’s Deputy Director
and VP of Engineering, and Commons is the world’s largest repository of
freely licensed educational media on the internet.

“The Wikimedia Commons community is the reason these freely-licensed images
exist for everyone to enjoy. said Moeller. “Our next steps are to prepare
Wikimedia Commons for the future, including support for rich, structured
metadata; a massively improved user experience for uploading media; better
tools for editing media content through the web; and better support for
video. The first decade was just the beginning.”

The Foundation is thrilled to be celebrating these and many more
achievements of the project’s first decade.


About the Wikimedia Foundation

https://wikimediafoundation.org
https://blog.wikimedia.org/

The Wikimedia Foundation is the non-profit organization that operates
Wikipedia, the free encyclopedia. According to comScore Media Metrix,
Wikipedia and the other projects operated by the Wikimedia Foundation
receive 413 million unique visitors per month, making them the fifth-most
popular web property world-wide (comScore, July 2014). Available in 287
languages, Wikipedia contains more than 32 million articles contributed by
a global volunteer community of roughly 80,000 people. Based in San
Francisco, California, the Wikimedia Foundation is an audited, 501(c)(3)
charity that is funded primarily through donations and grants.

Wikimedia Foundation Press Contact:

Communications, Wikimedia Foundation
+1 415-839-6885 ext 6633kmaher[image: @]wikimedia.org



-- 
Tilman Bayer
Senior 

Re: [Wikimedia-l] Next steps regarding WMF-community disputes about deployments

[Fæ]

On 06/09/2014, Isarra Yos zhoris...@gmail.com wrote:
 Be like 4chan! Everyone loves 4chan.

No.

This is so wrong it hurts.

Fae
-- 
fae...@gmail.com https://commons.wikimedia.org/wiki/User:Fae

___
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

Re: [Wikimedia-l] To Flow or not to Flow

[Fæ]

On 6 September 2014 07:11, Gerard Meijssen gerard.meijs...@gmail.com wrote:
 Hoi,
 We includes anyone who wants to be involved and does not exclude him or
 herself by his or her own actions or choices.
 Thanks,
 GerardM

Incorrect.

Erik's email includes phrases like We're not pushing an aggressive
schedule on Flow. This clearly means that we refers to the
Wikimedia Foundation and excludes unpaid volunteers who hold no
responsibility or authority for the deployment schedule.

Fae
-- 
fae...@gmail.com https://commons.wikimedia.org/wiki/User:Fae

___
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] Endless drama around solutions to non-problems as misdirection

[James Salsman]

Where does the idea that user interface changes to the system which
has already produced the most monumental reference work in the history
of humanity are going to help with its only actual problem, that
people aren't sufficiently inclined to stick around and maintain it?

If there was any evidence that VE or Media Viewer or Flow will make
the projects more attractive to volunteers, I'm sure we would have
heard it by now. But there isn't. Nor is there any evidence that any
of the several Editor Engagement projects have made a dent in
volunteer attrition rates, despite their success in encouraging tiny
subsets of very new editors to contribute a few minutes more work.

The present set of dramatic distractions from attention to the
vanishing volunteer corps only highlights that Foundation leadership
has no ability to focus on the only strategic goal they haven't
achieved: retaining volunteers. Because it is so much easier to
pretend that readers need WYSIWYG or a lightbox or can't figure out
how to indent replies; since readership numbers aren't an actual
problem (when mobile users are added to desktop pageviews) this
guarantees the false appearance of success in the eyes of everyone who
doesn't see through the transparent cop-out. Where is the evidence
that the status quo user interface from 2005 would not have done just
as well in every measurable aspect of movement success?

Steven Walling wrote:
...
 We practically can't and don't take on initiatives that directly
 try to provide more free time or money to editors

That is absolutely false. Individual Engagement Grants have recently
been proven to be substantially more cost-effective in achieving the
Foundation's stated goals than any other form of grant spending, on a
per-dollar basis. Is there any evidence that any Foundation
engineering effort of the past five years has done as well? I haven't
seen any.

When the Foundation spends on copyright advocacy, those initiatives
directly try to provide more economic empowerment to the small
fraction of contributors who stand to benefit from whatever additional
government documents or panorama images they hope to free up. But
volunteers who want to update information on the side effects of
commonly prescribed drugs get nothing.

When the Foundation spends on attempts to oppose the Trans Pacific
Partnership, those initiatives directly try to provide more free time
and money to the small subset of editors threatened by lengthening of
copyright terms. But editors who want to help translate introductory
material foundational to engineering skills literacy get nothing.

Who at the Foundation bears the responsibility for deciding which of
initiatives that might benefit the real needs of vanishing volunteers
are funded, and why aren't they held accountable for their record
since 2007?

___
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

Re: [Wikimedia-l] Next steps regarding WMF-community disputes about deployments

[David Gerard]

Erik - how confident are you that you're coming up with something that
the present users of talk pages - people actually trying to get work
done on articles - will love? Not just barely tolerate - what are you
bringing us?


- d.

___
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

Re: [Wikimedia-l] To Flow or not to Flow

[Quim Gil]

On Saturday, September 6, 2014, Erik Moeller e...@wikimedia.org wrote:

 So we think a
 support forum like the Teahouse, and its equivalent in other languages
 may be a good place to start -- provided the hosts agree that there
 are no dealbreaker issues for them.


What about setting up some kind of Flow self-service for projects? Let play
to those wiling to play, in the way they think it's best for their projects.

Potential requirements to join the Flow self-service:

* At least one tech ambassador volunteering to act as contact between the
project and the Flow team, summarizing community feedback in the channels
agreed (mw:Talk:Flow, etc).
* Community agreement after a public discussion in the project.
* Selection of a first page to try Flow.

When the requirements are met, Flow is enabled in that project and
activated in that page. A month of trial follows, and after that the
community must evaluate whether it is worth activating Flow in more pages
or wait. Maybe at some point the admins of the project can control in which
pages Flow is deployed?

While we (Wikimedia movement) dedicate so much time to negotiate
incremental deployments of Flow in some sensitive and tough arenas, maybe
there are huge regions in our communities where editors would welcome a
test of this feature. The feedback of these early adopters would help
fine-tuning Flow and to better define the development priorities, since
longer term use of regular editors provides a more complete perspective
than power users in mediawiki.org alone.


-- 
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
___
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] (no subject)

[Tim Davenport]

Wil Sinclair wrote:

I think there is a lot of value and promise in Flow. But it is a huge paradigm
shift for onwiki communication, and it must not surprise users under any
circumstances. Maybe someone has the right figure handy, but I wouldn't be
surprised if, after archives are added up, there is more discussion across
all wikis than content. If so, one might argue that this is a bigger change
than VE and it certainly dwarfs the impact that most editors experience
from the MV rollout.

==
It is an interesting question as to whether there is more talk than total
content at WP. lt's an empirical question, maybe someone has the answer.

Regardless, Flow is bigger than VE in impact for the active volunteer
community because there will be no opt-outing out of it. If and when it is
installed, it will be the one and only available option for everyone. If
that software is broken in any significant way, I find it hard to put into
words how messy an issue it will be for WMF. Think the VE debacle plus
the MV dustup to the second power — with no easy solution, since all
existing talk pages will be archived and going back nearly impossible
without fully reverting every page which it touched.

Flow must, must, must be proven to be not only 100% fully functional
software but to represent an improvement over the status quo in actual
practice on some wiki other than En-WP or De-WP before even a limited roll
out is made in En-WP or De-WP.

This software is a mere blip on the horizon for most En-WP volunteers at
the moment. It will become the biggest of issues. If the software doesn't
work perfectly, if the introduction is not done incrementally and with full
community consent, things are going to go nuclear. That's not a threat or
an idle prediction, that's a statement of a mathematically certain fact.

Tim Davenport
Carrite on WP /// Randy from Boise on WPO
Corvallis, OR  (USA)
___
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

Re: [Wikimedia-l] To Flow or not to Flow

[Andy Mabbett]

On 6 September 2014 05:49, Erik Moeller e...@wikimedia.org wrote:

 Fundamentally, there's one key question to answer for talk pages in
 Wikimedia projects: Do we want discussions to occur in document mode,
 or in a structured comment mode?

I rather think the more fundamental question is (for any software
solution) does this tool enable us to build the encyclopedia, better
than its predecessor?.

 - Update author names after a username change without having to update 
 documents

So if I say in a discussion in which you participated, much earlier,
I agree with what Eloqeunce said, and you subsequently change your
user name to ErikM, my comment would be made nonsensical?

-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

___
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

Re: [Wikimedia-l] To Flow or not to Flow

[Yann Forget]

Hi,

That seems a sensible plan. I am thinking of the help desk on Commons
(in English or in another language) as a good testbed.

Regards,

Yann

2014-09-06 17:09 GMT+05:30 Quim Gil q...@wikimedia.org:
 On Saturday, September 6, 2014, Erik Moeller e...@wikimedia.org wrote:

 So we think a
 support forum like the Teahouse, and its equivalent in other languages
 may be a good place to start -- provided the hosts agree that there
 are no dealbreaker issues for them.


 What about setting up some kind of Flow self-service for projects? Let play
 to those wiling to play, in the way they think it's best for their projects.

 Potential requirements to join the Flow self-service:

 * At least one tech ambassador volunteering to act as contact between the
 project and the Flow team, summarizing community feedback in the channels
 agreed (mw:Talk:Flow, etc).
 * Community agreement after a public discussion in the project.
 * Selection of a first page to try Flow.

 When the requirements are met, Flow is enabled in that project and
 activated in that page. A month of trial follows, and after that the
 community must evaluate whether it is worth activating Flow in more pages
 or wait. Maybe at some point the admins of the project can control in which
 pages Flow is deployed?

 While we (Wikimedia movement) dedicate so much time to negotiate
 incremental deployments of Flow in some sensitive and tough arenas, maybe
 there are huge regions in our communities where editors would welcome a
 test of this feature. The feedback of these early adopters would help
 fine-tuning Flow and to better define the development priorities, since
 longer term use of regular editors provides a more complete perspective
 than power users in mediawiki.org alone.


 --
 Quim Gil
 Engineering Community Manager @ Wikimedia Foundation
 http://www.mediawiki.org/wiki/User:Qgil
 ___
 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

Re: [Wikimedia-l] To Flow or not to Flow

[Magnus Manske]

On Sat, Sep 6, 2014 at 9:50 AM, Fæ fae...@gmail.com wrote:

 On 6 September 2014 07:11, Gerard Meijssen gerard.meijs...@gmail.com
 wrote:
  Hoi,
  We includes anyone who wants to be involved and does not exclude him or
  herself by his or her own actions or choices.
  Thanks,
  GerardM

 Incorrect.

 Erik's email includes phrases like We're not pushing an aggressive
 schedule on Flow. This clearly means that we refers to the
 Wikimedia Foundation and excludes unpaid volunteers who hold no
 responsibility or authority for the deployment schedule.


Incorrect.

In such a long text, we can obviously refer to both the Foundation and
the community (both of which Erik is a member of), depending on context.
There would be little point in Erik asking Do we want discussions to occur
in document mode, or in a structured comment mode? on a public mailing
list, when he just wants to ask a Foundation-internal question, right?
Pretty obvious, really, unless your goal is to distract from the actual
topic.
___
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

Re: [Wikimedia-l] To Flow or not to Flow

[Fæ]

Refer to the signature Erik used. The rationale that employees when acting
as employees somehow are to be wearing a hat of an unpaid volunteer was
worn out when superprotect was invented.
On 6 Sep 2014 14:22, Magnus Manske magnusman...@googlemail.com wrote:

 On Sat, Sep 6, 2014 at 9:50 AM, Fæ fae...@gmail.com wrote:

  On 6 September 2014 07:11, Gerard Meijssen gerard.meijs...@gmail.com
  wrote:
   Hoi,
   We includes anyone who wants to be involved and does not exclude him
 or
   herself by his or her own actions or choices.
   Thanks,
   GerardM
 
  Incorrect.
 
  Erik's email includes phrases like We're not pushing an aggressive
  schedule on Flow. This clearly means that we refers to the
  Wikimedia Foundation and excludes unpaid volunteers who hold no
  responsibility or authority for the deployment schedule.
 

 Incorrect.

 In such a long text, we can obviously refer to both the Foundation and
 the community (both of which Erik is a member of), depending on context.
 There would be little point in Erik asking Do we want discussions to occur
 in document mode, or in a structured comment mode? on a public mailing
 list, when he just wants to ask a Foundation-internal question, right?
 Pretty obvious, really, unless your goal is to distract from the actual
 topic.
 ___
 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

Re: [Wikimedia-l] To Flow or not to Flow

[Yaroslav M. Blanter]

On 06.09.2014 13:39, Quim Gil wrote:
On Saturday, September 6, 2014, Erik Moeller e...@wikimedia.org 
wrote:



So we think a
support forum like the Teahouse, and its equivalent in other 
languages

may be a good place to start -- provided the hosts agree that there
are no dealbreaker issues for them.



What about setting up some kind of Flow self-service for projects? Let 
play
to those wiling to play, in the way they think it's best for their 
projects.


Potential requirements to join the Flow self-service:

* At least one tech ambassador volunteering to act as contact between 
the
project and the Flow team, summarizing community feedback in the 
channels

agreed (mw:Talk:Flow, etc).
* Community agreement after a public discussion in the project.
* Selection of a first page to try Flow.



Hi Quim,

actually, this is exactly what is happening now and this is what caused 
this turmoil yesterday night.


FLOW was once deployed on two en.wp WikiProjects in the past, 
Wikiroject:Breakfast and another one, i do not remember which on off the 
top of my head. The Wikiproject participants agreed to use their talk 
pages as a testbed, and it was announced reasonably broadly. Volunteers, 
including me, tried installed FLOW and discovered that it is substandard 
and can not be used for any reasonable discussion. The test was 
terminated, some feedback was generated, some of it was taken onboard, 
the rest presumably not.


Yesterday, we discovered that FLOW was installed as a test in the 
Teahouse, a place whose purpose is to welcome newbies. I am not using 
the Teahouse, but the argument which I have heard was that FLOW was 
installed on a page inaccessible from the main Teahouse page and thus 
unlikely to be visited by newbies. Apparently, there was some discussion 
in the Teahouse, and the consensus was that FOW should not be installed. 
Since FLOW was installed clearly against the community will and since it 
is clearly still substandard, we had to act somehow. Danny got a warning 
at his talkage, the FLOW page was protected, and I had to send a message 
here, which in the end of the day started this discussion.


This is not the way FLOW should be deployed.

To me, Wikidata deployment was an example of successful Wikimedia 
project deployment which went relatively easily (even though there are 
still users having a strong opinion against Wkidata). The reasons it 
went so smoothly were that (i) it was clear what the end goal is, what 
should happen at what stage, and what are the needed steps; (ii) there 
were a large amount of volunteers and ambassadors from the first day 
sharing the idea and helping to explain it and to fix the bugs; (iii) 
Support was always and easily available, including Danny and Lydia, and 
they were really willing to listen to us and to help us, not to impose 
their vision.


I am afraid with Flow we are still not even at (i). Whereas after 
Erik's message I understand what he wants in very general terms, the 
implementation is completely open. In these terms, Facebook or PHP are 
both FLOW. I guess we start from the concept, and the next step would be 
for volunteers to instal Flow a their talk pages. If they can survive 
for a couple of months, we can talk about it further.


Cheers
Yaroslav

___
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

Re: [Wikimedia-l] To Flow or not to Flow

[Dedalus]

Quim Gil q...@wikimedia.org wrote:


 Potential requirements to join the Flow self-service:

 * At least one tech ambassador volunteering to act as contact between the
 project and the Flow team, summarizing community feedback in the channels
 agreed (mw:Talk:Flow, etc).
 * Community agreement after a public discussion in the project.
 * Selection of a first page to try Flow.

 When the requirements are met, Flow is enabled in that project and
 activated in that page.


Thank you Quim!

Yes, I would like to have Flow enabled on a test page on Dutch Wikipedia.
To acquire community agreement I have started a topic in the village pump
of the Dutch Wikipedia [1]. Essentially I asked if there exist objections
against enabling Flow on a test page, and, if yes, what those objections
are.

Best regards,


Dedalus

[1]
https://nl.wikipedia.org/wiki/Wikipedia:De_kroeg#Aanvraag_testpagina_voor_Flow_op_de_Nederlandstalige_Wikipedia

[2]
https://upload.wikimedia.org/wikipedia/commons/c/c0/WMF_StrategicPlan2011_spreads.pdf
___
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

Re: [Wikimedia-l] To Flow or not to Flow

[Martijn Hoekstra]

On Sat, Sep 6, 2014 at 6:49 AM, Erik Moeller e...@wikimedia.org wrote:

 Hi all,

 snip

 Sincerely,
 Erik

 [1]
 https://lists.wikimedia.org/pipermail/wikipedia-l/2003-July/011069.html
 [2]
 https://meta.wikimedia.org/w/index.php?title=LiquidThreadsoldid=100760
 [3] https://translatewiki.net/wiki/Support
 [4] https://www.mediawiki.org/wiki/Project:Support_desk
 [5]
 https://upload.wikimedia.org/wikipedia/commons/5/5c/LQT-v2-TalkPage-Full.png
 [6] https://www.mediawiki.org/wiki/LiquidThreads_3.0/Design
 [7] https://gerrit.wikimedia.org/r/#/c/119243/
 [8] https://www.mediawiki.org/wiki/Flow/Architecture
 --
 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



This email almost exactly embodies what I mean when I say that we are told
not to worry, everything will be OK in the earlier stages of development,
when in the later stages near deployment we're being told that the feature
has been under development for months or even years, and only *now* we come
with all these demands.

-- Martijn
___
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

Re: [Wikimedia-l] [Chapters] Recognition of Wikimedia Belgium as a Wikimedia chapter by the WMF Board

[Tonmoy Khan]

Congratulations to Wikimedia Belgium and everyone involved.

Ali Haidar Khan
FDC Member
Treasurer, Wikimedia Bangladesh
On Sep 6, 2014 11:28 AM, Balázs Viczián balazs.vicz...@wikimedia.hu
wrote:

 Congrats from Wikimedia Hungary!

 Balázs
 2014.09.02. 19:46, Carlos M. Colina ma...@wikimedia.org.ve ezt írta:

   Dear all,
 
  It is an honour for me to announce that during Wikimania, the WMF
 resolved
  [1] to recognise Wikimedia Belgium as a Wikimedia chapter. The resolution
  was made public a few days ago.
 
  The first discussions towards the establishment of a Belgian chapter
  started many years ago, with the local community doing projects related
 to
  freedom of knowledge since then, like organisation of WLM Belgium 
  Luxembourg in 2011, 2012 and 2013. Along with these and other activities,
  the idea of a chapter grew and evolved to the moment when, the decision
 was
  taken to start officially the chapter creation process.
 
  This process took longer than usual, due to many reasons, among those the
  change in the chapter approval process by the WMF Board last year.
  Nevertheless, after months of intensive discussion and interaction
 between
  all parties involved, a recommendation from the AffCom was sent to the
 WMF
  regarding Wikimedia Belgium. And here we are :-)
 
  Please welcome the newest member of the family of Wikimedia affiliates!
 
  Regards,
  Carlos
 
 
  1:
 
 https://wikimediafoundation.org/wiki/Resolution:Recognition_of_Wikimedia_Belgium
 
  --
  *Jülüjain wane mmakat* ein kapülain tü alijunakalirua jee wayuukanairua
  junain ekerolaa alümüin supüshuwayale etijaanaka. Ayatashi waya junain.
  Carlos M. Colina
  Vicepresidente, A.C. Wikimedia Venezuela | RIF J-40129321-2 |
  www.wikimedia.org.ve http://wikimedia.org.ve
  Chair, Wikimedia Foundation Affiliations Committee
  Phone: +972-52-4869915
  Twitter: @maor_x
 
  ___
  Chapters mailing list
  chapt...@wikimedia.ch
  https://intern.wikimedia.ch/lists/listinfo/chapters
 
 ___
 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

Re: [Wikimedia-l] Endless drama around solutions to non-problems as misdirection

[Gerard Meijssen]

Hoi,
The lack of usability that is inherent in the current tools is enough to
drive me away from editing Wikipedia. At to this the atmosphere that is all
too often just not interested in anything but vested interests and you have
a cocktail that is powerful enough to have me respond to your challenge.
Our environment is long overdue on an update and, this is really hard to
do. I welcome the much anticipated editor and media viewer. Sure, it is not
the finished product yet but it has way more finesse then what we had
before.

What distracts me most is the constant bickering that suggests that we are
not moving forward or that fails to appreciate the extend that we need
change in order to remain relevant with our content. We find that new
editors are mainly from a mobile environment (i include tablets here) and
they are NOT attached to the old ways some aim to have us stick to at all
costs.

We need to change and our aim should be to remain relevant for the next
decennia.
Thanks,
  GerardM


On 6 September 2014 10:54, James Salsman jsals...@gmail.com wrote:

 Where does the idea that user interface changes to the system which
 has already produced the most monumental reference work in the history
 of humanity are going to help with its only actual problem, that
 people aren't sufficiently inclined to stick around and maintain it?

 If there was any evidence that VE or Media Viewer or Flow will make
 the projects more attractive to volunteers, I'm sure we would have
 heard it by now. But there isn't. Nor is there any evidence that any
 of the several Editor Engagement projects have made a dent in
 volunteer attrition rates, despite their success in encouraging tiny
 subsets of very new editors to contribute a few minutes more work.

 The present set of dramatic distractions from attention to the
 vanishing volunteer corps only highlights that Foundation leadership
 has no ability to focus on the only strategic goal they haven't
 achieved: retaining volunteers. Because it is so much easier to
 pretend that readers need WYSIWYG or a lightbox or can't figure out
 how to indent replies; since readership numbers aren't an actual
 problem (when mobile users are added to desktop pageviews) this
 guarantees the false appearance of success in the eyes of everyone who
 doesn't see through the transparent cop-out. Where is the evidence
 that the status quo user interface from 2005 would not have done just
 as well in every measurable aspect of movement success?

 Steven Walling wrote:
 ...
  We practically can't and don't take on initiatives that directly
  try to provide more free time or money to editors

 That is absolutely false. Individual Engagement Grants have recently
 been proven to be substantially more cost-effective in achieving the
 Foundation's stated goals than any other form of grant spending, on a
 per-dollar basis. Is there any evidence that any Foundation
 engineering effort of the past five years has done as well? I haven't
 seen any.

 When the Foundation spends on copyright advocacy, those initiatives
 directly try to provide more economic empowerment to the small
 fraction of contributors who stand to benefit from whatever additional
 government documents or panorama images they hope to free up. But
 volunteers who want to update information on the side effects of
 commonly prescribed drugs get nothing.

 When the Foundation spends on attempts to oppose the Trans Pacific
 Partnership, those initiatives directly try to provide more free time
 and money to the small subset of editors threatened by lengthening of
 copyright terms. But editors who want to help translate introductory
 material foundational to engineering skills literacy get nothing.

 Who at the Foundation bears the responsibility for deciding which of
 initiatives that might benefit the real needs of vanishing volunteers
 are funded, and why aren't they held accountable for their record
 since 2007?

 ___
 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

Re: [Wikimedia-l] To Flow or not to Flow

[Todd Allen]

Erik,

I think a lot of reasons for the document mode commenting system got
missed. But there are very good reasons we must retain that.

One huge thing is that article talk pages are not only for discussions, but
also for metadata (article assessments, history, Wikiproject data, as
examples from the English Wikipedia). The top of the talk page also, on
many pages, serves notices and FAQs to new visitors to the talk page.

For reviews like that, it may be necessary to have wikitext act as
wikitext, another very significant concern. (Your use of Template:Example
is what's causing the text formatting to break in that section, because it
does like this: (insert example). You should actually use
{{example|arg1|arg2}}.) In other cases, subpages or other pages need to be
transcluded in, and all the functions of the transcluded page must be
preserved. Discussion pages aren't -only- used for discussion.

I think there's a serious flaw in thinking with the current development
processes, that Wikipedia needs to be more like Facebook, or Instagram, or
Twitter to attract new users. Jan-Bart has even mentioned Quora at several
points. Quora is cool. I love Quora. But that's not Wikipedia, and it's not
what Wikipedia should aspire to. They're not a competitor. (For that
matter, there -are- no competitors, we give our product away for free,
not only to read but to repackage and reuse!)

Making the interface easier to use is fine, but never at the expense of
quality or flexibility. The second is the real sticking point here. We need
maximum flexibility to handle complex discussions and complex problems. We
may need some stuff at the top of the page, not left in infinite scroll
hell. (Infinite scroll has to be one of the worst, user-unfriendliest UI
ideas I've ever seen.) We need the ability to rapidly archive forum style
posts or stuff that's become unproductive, and we need -any- editor able to
do that, not just admins. Non-admin editors help out all the time in that
regard. We need the ability to have real archives; again, infinite scroll
with or without search is nowhere near a replacement for that. We need the
ability to easily wikilink to specific sections.

Adding some rails is fine, but never at the expense of the underlying
functionality. VE, once it works, is the model to look at there: It
supplements, not supplants, the existing functions. That will be a huge
step in the right direction, the problem there was not design but
execution. Once it works properly, that issue goes away.

With Flow, the issue is flawed design. Supplanting current talk page
functionality will not work. We need the flexibility of subpages and freely
editable documents. The only other option there would be to use
article-space subpages for that, and that would be messy and horribly
inefficient.

 Facebook, Twitter, forums, etc., don't need that, but it cannot be
emphasized enough that we ***are not, and should not aspire to be or look
like, a social media site***. We handle complexity that sites designed
around LOL OMGZ LOLCAT PIX! do not need to handle.

The resistance you're seeing here is you're trying to take things right out
of someone's hand, while they shout Hey, I was USING that, and this thing
you're trying to hand me won't do the same thing!. No amount of tweaks to
Flow will change that, unless you can somehow layer it onto existing talk
pages rather than replacing them. But any workable solution must retain
that backwards compatibility, as VE will.

Maybe Flow could see limited use in a few newbie help areas to aid them in
making the transition from reader to editor, but serious editors will by
and large not want it sitewide. Ease-of-use helpers will be much more
easily accepted, provided they're actually ready for wide scale use when
rolled out as site defaults and have easy opt outs. Why not, at the very
least, try the less radical change first and see how it works?

Todd


On Fri, Sep 5, 2014 at 10:49 PM, Erik Moeller e...@wikimedia.org wrote:

 Hi all,

 I'm breaking out this discussion about Flow/talk pages (apologies for
 repeatedly breaking the megathread, but this is a well-scoped subject
 which deserves its own thread).

 Fundamentally, there's one key question to answer for talk pages in
 Wikimedia projects: Do we want discussions to occur in document mode,
 or in a structured comment mode? All else flows from there (pun
 intended).

 == Document mode ==

 There are not many examples of document mode discussion systems beyond
 wikis. You sometimes see people use collaborative realtime editors as
 such, because people want to talk in the same space where they work,
 but Google Docs provided alternatives (a pretty powerful
 comments/margin system and built-in chat) early on, for example.

 The current talk page system is a document mode system. Individual
 comments have unclear boundaries (a single transaction can result in
 multiple comments, signed or unsigned; indentation levels are
 unpredictable and often 

Re: [Wikimedia-l] To Flow or not to Flow

[WereSpielChequers]

Since we already know two of the changes that will come from Flow, the end of 
signature personalisation and only three levels of talk indentation; Surely it 
makes sense for the WMF to put those to the community now and see if it can win 
consensus for those two changes?

On a less contentious note, has anyone costed how much cheaper than FLOW it 
would be to introduce auto sign on talk pages, with all new accounts opted in 
from the implementation date onwards and all new accounts opted out? We would 
need a button on the edit screen marked sign my comment so that people could 
uncheck an edit where they were adding a wiki project tag or fixing a typo in 
their post. But it would make things a lot easier for newbies. The indentation 
is relatively easy to pick up, but currently every welcome message has to 
introduce the concept of four tildas. It would be much easier and the site much 
more welcoming if that no longer had to be explained to newbies.

Regards

WereSpielChequers/Jonathan Cardy


___
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

Re: [Wikimedia-l] Next steps regarding WMF-community disputes about deployments

[Isarra Yos]

On 06/09/14 07:41, Erik Moeller wrote:

On Sat, Sep 6, 2014 at 12:23 AM, Isarra Yos zhoris...@gmail.com wrote:


Why in the world would posts not be editable? I've never used a platform
where discussion was important in which users couldn't at least edit their
own posts (along with mods) where the lack of such wasn't often complained
about (for instance bugzilla and gerrit don't allow it; moodle and tumblr
do).

Sorry, I should have been clearer. By default, Flow lets you edit your
own comments, and lets admins edit all comments, just like typical
forum conventions. It just doesn't let everyone edit everything.


But that's not how wikis work. On other platforms that do support such 
editing at all, users edit their own articles, and their own comments, 
with only moderators trusted to change them. But on wikis, the users are 
also the moderators. This applies to content and comments, and admins 
are only required where things can become sensitive (where concerns of 
privacy, site stability, or simply dangerous tools in terms of vandalism 
come into play). Why the sudden divergence that only admins can be mods 
here? Discussions aren't sensitive.


This sort of thing is a large part of why some of us are so skeptical of 
Flow currently - if the designers do not even understand the basic 
principles behind a wiki, how can what is developed possibly suit our 
needs? The thing is, they - you - need to start really listening, and 
not just arguing (or not responding at all), because otherwise things 
are just going to get messier and messier.


-I

___
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

Re: [Wikimedia-l] Next steps regarding WMF-community disputes about deployments

[Yaroslav M. Blanter]

On 06.09.2014 19:18, Gerard Meijssen wrote:

Hoi,
The subject is discussion / talk space not article space editing.. 
Yaroslav
please stay on topic..Surely Marc has more than 13 edits in all kinds 
of

discussion on multiple wikis.
Thanks,
   GerardM


On 6 September 2014 19:14, Yaroslav M. Blanter pute...@mccme.ru 
wrote:



On 06.09.2014 19:06, Marc A. Pelletier wrote:


 Sadly, there *are* people who get offended that the vast unwashed 
masses
could start contributing to *their* project without having gone 
through

a painful, demanding rite of passage.  Truth is, most people of the
world don't have the time for that, or if they do, (perfectly
reasonably) believe that you shouldn't have to pay to volunteer to 
help.


-- Marc


Marc, with all my due respect, this statement would be more 
convincing if

spelled out by someone with more than 13 edits in the article space
combined in 2013 and 2014.

Cheers
Yaroslav




Sure. However, contributing to *our* project, meaning (I guess) in this 
case the English Wikipedia, is most and foremost contributing content. 
And sadly we have enough users around who try to contribute content 
without having time to go through the rite of passage, and we have to 
spend way too much time reverting and rewriting their contribution to 
make it appropriate for an encyclopedia.


I agree though that this is off-topic in this thread.

Cheers
Yaroslav


___
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

Re: [Wikimedia-l] Next steps regarding WMF-community disputes about deployments

[Marc A. Pelletier]

On 09/06/2014 01:12 PM, Todd Allen wrote:
 But dismissing them by setting up a (rather
 ridiculous) straw man is not helpful.

I *wish* it was a strawman.  How else would you qualify:

And sadly we have enough users around who try to contribute content
without having time to go through the rite of passage, and we have to
spend way too much time reverting and rewriting their contribution to
make it appropriate for an encyclopedia.

It's more than a little sad to not even have had to /look/ for that
comment, it was offered in response to Gerard not even five minutes ago.

-- Marc


___
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

Re: [Wikimedia-l] Recognition of Wikimedia Belgium as a Wikimedia chapter by the WMF Board

[Nurunnaby Hasive]

Congratulations to Wikimedia Belgium!



User: Nhasive | @nhasive
Sysop, Bengali Wikipedia
Member, IEG, WMF
On Saturday, September 6, 2014, Tonmoy Khan tonmoy...@gmail.com wrote:

 Congratulations to Wikimedia Belgium and everyone involved.

 Ali Haidar Khan
 FDC Member
 Treasurer, Wikimedia Bangladesh
 On Sep 6, 2014 11:28 AM, Balázs Viczián balazs.vicz...@wikimedia.hu
 javascript:;
 wrote:

  Congrats from Wikimedia Hungary!
 
  Balázs
  2014.09.02. 19:46, Carlos M. Colina ma...@wikimedia.org.ve
 javascript:; ezt írta:
 
Dear all,
  
   It is an honour for me to announce that during Wikimania, the WMF
  resolved
   [1] to recognise Wikimedia Belgium as a Wikimedia chapter. The
 resolution
   was made public a few days ago.
  
   The first discussions towards the establishment of a Belgian chapter
   started many years ago, with the local community doing projects related
  to
   freedom of knowledge since then, like organisation of WLM Belgium 
   Luxembourg in 2011, 2012 and 2013. Along with these and other
 activities,
   the idea of a chapter grew and evolved to the moment when, the decision
  was
   taken to start officially the chapter creation process.
  
   This process took longer than usual, due to many reasons, among those
 the
   change in the chapter approval process by the WMF Board last year.
   Nevertheless, after months of intensive discussion and interaction
  between
   all parties involved, a recommendation from the AffCom was sent to the
  WMF
   regarding Wikimedia Belgium. And here we are :-)
  
   Please welcome the newest member of the family of Wikimedia affiliates!
  
   Regards,
   Carlos
  
  
   1:
  
 
 https://wikimediafoundation.org/wiki/Resolution:Recognition_of_Wikimedia_Belgium
  
   --
   *Jülüjain wane mmakat* ein kapülain tü alijunakalirua jee
 wayuukanairua
   junain ekerolaa alümüin supüshuwayale etijaanaka. Ayatashi waya
 junain.
   Carlos M. Colina
   Vicepresidente, A.C. Wikimedia Venezuela | RIF J-40129321-2 |
   www.wikimedia.org.ve http://wikimedia.org.ve
   Chair, Wikimedia Foundation Affiliations Committee
   Phone: +972-52-4869915
   Twitter: @maor_x
  
   ___
   Chapters mailing list
   chapt...@wikimedia.ch javascript:;
   https://intern.wikimedia.ch/lists/listinfo/chapters
  
  ___
  Wikimedia-l mailing list, guidelines at:
  https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
  Wikimedia-l@lists.wikimedia.org javascript:;
  Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
  mailto:wikimedia-l-requ...@lists.wikimedia.org javascript:;
 ?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 javascript:;
 ?subject=unsubscribe



-- 
Nurunnaby Chowdhury Hasive
Sent from My iPhone
___
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] To Flow or not to Flow

[Quim Gil]

(The self-service suggestion and the opinions below are mine, posted here
with the best of my community intentions.)

Hi Yaroslav,

On Saturday, September 6, 2014, Yaroslav M. Blanter pute...@mccme.ru
javascript:_e(%7B%7D,'cvml','pute...@mccme.ru'); wrote:

 actually, this is exactly what is happening now and this is what caused
 this turmoil yesterday night.


The situation you describe and the hypothetical self-service process I
suggested are different.

I guess we start from the concept, and the next step would be for
 volunteers to instal Flow a their talk pages. If they can survive for a
 couple of months, we can talk about it further.


Discussing concepts is better done while trying prototypes, alphas, betas
(and we have been doing this for Flow for about a year now). For instance,
I believe mw:Winter is progressing in the way it is progressing thanks to a
good balance between conceptual discussions, prototyping iterations, and
actual testing. Flow itself is progressing well thanks to the limited
deployments in some real pages.

Allowing users to activate Flow in their Talk pages would fit in the
self-service idea. If the development team decides to open this
possibility, I will not hesitate in joining the trial.


-- 
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
___
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] Feedback with Android on Commons

[Yann Forget]

Hi,

I am not a mobile user. So for the first time, I used the Mobile App
on a Samsung S4 to upload a few pictures. I am quite disappointed, to
say the least. I stopped counting how many times the application
crashed while uploading just a few pictures. Then in reviewing my
uploads, I can't see the description or the license, the field is
blank. Then I discovered that the Application does not check if the
name already exists, and uploads over the old file without warning.
Luckily I didn't upload over someone else files. Then the categories I
choose were not included, and also no warning there. It is a bit less
bad on a tablet, where I can read the description and the license, but
I can't add any category. I wonder how a software in such a bad
condition gets deployed... Now it is much easier than on the desktop,
and I understand why we get so many useless pictures from mobile
uploads.

https://commons.wikimedia.org/wiki/Commons_talk:Mobile_app#Feedback_on_Android

Regards,

Yann

___
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

Re: [Wikimedia-l] To Flow or not to Flow - it does not flow

[Romaine Wiki]

Hello all,

I did a couple if simple tests on MediaWiki on Flow pages with often
occurring edits. The tests failed.

I am an admin on Commons, and I regularly have to remove an image on a talk
page because it is for example a violation of copyright. I see no way to
remove the copyright violation from the message.

Another thing I tried is the removal of a personal attack or a privacy
issue. It is common on nl-wiki to remove a personal attack out of a message
and replacing it by a template which says what happened. This is impossible
to do.

If a template is changed, its parameters on the various places where the
template is added need to be changed as well. This is done by hand or with
a bot (like AWB), both ways seems impossible with flow.

If someone added a message to the wrong page, it is relocated to another
talk page. Seems impossible to do here. If a message is considered to be
inappropriate for a certain page, it is relocated, seems impossible with
Flow.

Another thing I noticed is that I can't get a complete overview of all
messages added to a certain talk page. After 10 messages, everything is
hidden. A quick ctrl + F is impossible. When I know there was a discussion
about a specific thing, I want to check the talk page easily by searching
it completely, not possible. It is very annoying that I can't get a
complete overview of all messages on a talk page, this is a basic need!

As I read on mw:Flow: to make the wiki discussion system more efficient
for experienced users (as goal of Flow)
I get it! By making normal things impossible to do, the experienced users
have indeed less work...

For the rest I have seen no way why this method is more efficient for
experienced users, as it is not.


So, there is flow, and instead of the community can work with it as it
needs to work with, it does not flow but got stuck...

To answer the question, To Flow or not to Flow, it does not flow. I am not
able to do simple edits which are done every day.

Romaine



2014-09-06 6:49 GMT+02:00 Erik Moeller e...@wikimedia.org:

 Hi all,

 I'm breaking out this discussion about Flow/talk pages (apologies for
 repeatedly breaking the megathread, but this is a well-scoped subject
 which deserves its own thread).

 Fundamentally, there's one key question to answer for talk pages in
 Wikimedia projects: Do we want discussions to occur in document mode,
 or in a structured comment mode? All else flows from there (pun
 intended).

 == Document mode ==

 There are not many examples of document mode discussion systems beyond
 wikis. You sometimes see people use collaborative realtime editors as
 such, because people want to talk in the same space where they work,
 but Google Docs provided alternatives (a pretty powerful
 comments/margin system and built-in chat) early on, for example.

 The current talk page system is a document mode system. Individual
 comments have unclear boundaries (a single transaction can result in
 multiple comments, signed or unsigned; indentation levels are
 unpredictable and often inconsistent). All the joys and pain points of
 working on the same document are present (a heavily trafficked talk
 page will see many edit conflicts). You can't easily show comments in
 multiple contexts (cross-wiki, via email, as a notification, etc.)
 because of the boundary problem.

 You could try to make a document mode system work better. On the basis
 of wikitext, you can do some very basic things, like the new section
 link I added to MediaWiki back in July 2003 [1], when I wrote: This
 feature could also be the first stage of a more sophisticated
 discussion system, where the next stage would be auto-appending
 signatures and providing a 'Reply to this' link after each comment.

 But due to the aforementioned unpredictability, even making a reply
 link work consistently (and do the right thing) is non-trivial. You
 can get some of the way there, and the Wikipedia Teahouse actually has
 a gadget, written by Andrew Garrett (more on him below) that does
 precisely that.

 https://en.wikipedia.org/wiki/Wikipedia:Teahouse/Questions

 Note the Join this discussion link. It does give you a pop-up, and
 posts the comment for you in the right place, with indentation (it
 does not auto-sign, but instead tries to teach users the signature
 habit which they'll need to use on other talk pages).

 It may be worth doing more research and development on this, to see
 just how far we can get without changing the fundamentals, since a
 wholly new system may still be years out for wide use. However, there
 are inherent limitations due to the lack of a predictable and
 consistent structure.

 You could go further down the road of a document mode or hybrid
 system, but IMO not without introducing fully predictable comment
 markers (think comment id=234234Bla ~~~/comment) -- which would
 pollute the wikitext, be fragile (e.g. accidental or deliberate
 corruption of identifiers), and probably be considered unacceptable in
 a system 

Re: [Wikimedia-l] To Flow or not to Flow

[Erik Moeller]

On Sat, Sep 6, 2014 at 8:03 AM, Todd Allen toddmal...@gmail.com wrote:
 Erik,
 One huge thing is that article talk pages are not only for discussions, but
 also for metadata (article assessments, history, Wikiproject data, as
 examples from the English Wikipedia). The top of the talk page also, on
 many pages, serves notices and FAQs to new visitors to the talk page.

Yes, this is supported in Flow through wiki-editable headers. These
are community-editable like a wiki page. LQT simply used the existing
talk page for this purpose and hooked into its history and
permissioning, while Flow manages them separately, and its history
features are still very rudimentary for that reason.

 For reviews like that, it may be necessary to have wikitext act as
 wikitext, another very significant concern. (Your use of Template:Example
 is what's causing the text formatting to break in that section, because it
 does like this: (insert example). You should actually use
 {{example|arg1|arg2}}.)

There's nothing in Flow's design that makes this impossible. There are
some inconsistencies to work through due to the use of Parsoid's HTML
for comment storage, and some extensions that may just be
fundamentally incompatible with a comment-based approach in their
current form (e.g. page-level translation, etc).

 We need the ability to rapidly archive forum style
 posts or stuff that's become unproductive, and we need -any- editor able to
 do that, not just admins.

Flow has a few features relevant to this right now, all still experimental:

- You can hide a topic from view (collapses it, others can undo)
- You can summarize or close a topic (others can reopen, both
actions update the summary, close also collapses)
- You can edit a topic's title
- You can hide an individual comment (collapses it, others can undo)

In the current permission system (which is easy to change)
the only thing that is lightly restricted is editing other people's
comments.

The underlying reasoning here is to try to support patterns that exist
in our community, while discouraging problematic changes. Comments
that solely consist of personal attacks can still be collapsed by
anyone, editing is discouraged except in special circumstances (and
hence restricted to admins); users don't have to monitor their own
comments for inappropriate edits.

Whether that's correct or not, I personally don't have a strong
opinion on. In LQT, we left comments openly editable, and I never
observed a problem with it; I think the arguments on both sides of
this issue are a bit out of proportion.

Back in 2004 I tried a little experiment by creating
https://en.wikipedia.org/wiki/User:Eloquence/Comment_policy and adding
it to my signature, to see if a subtle indicator would have more
people actually do anything interesting with my comments. It never
did. A year before I also tried to introduce a policy called Remove
personal attacks on en.wp:
https://en.wikipedia.org/w/index.php?title=Wikipedia:Remove_personal_attacksoldid=1622559

This was hotly debated, and when/where to edit other people's comments
is actually still somewhat ambiguous in policies across wikis. English
Wikipedia acknowledges: There is no official policy regarding when or
whether most personal attacks should be removed, although it has been
a topic of substantial debate. 

Just yesterday, as I was talking with Fram on Danny's talk page about
his .. slight escalation, another user popped in striking out Fram's
comments, then another user reverted that, ... so, there's a fair bit
of potential for conflict in this, which we do see a little bit of
every day.

German Wikipedia more explicitly encourages anyone to remove attacks
except people who are the subject of them, but cautions that users who
are subject of personal attacks should be careful, because it can
exacerbate a conflict. It then proceeds to explain that administrators
are encouraged to completely delete personal attacks using revision
deletion.
https://de.wikipedia.org/wiki/Wikipedia:Keine_pers%C3%B6nlichen_Angriffe

I think the strongest argument to keep comments openly editable, at
least initially, is that it's most consistent with policies as
currently written (most policies I've seen generally discourage
editing other people's comments, but have a few exceptions like the
one above). If, after much debate, communities want to adopt different
policies, then Flow's permissioning could be changed to reflect them.
Keeping the Hide type functionality in place for now would be a good
way to play with alternatives without immediately limiting options.

 We need the ability to have real archives; again, infinite scroll
 with or without search is nowhere near a replacement for that.

100% agreed. But with actual metadata for comments that's structured
and searchable, you can build much better search features -- search by
author, by date range, or even categorize/tag individual threads.
Archives in a well-built discussion system can be much more useful
than 

Re: [Wikimedia-l] To Flow or not to Flow - it does not flow

[Yaroslav M. Blanter]

On 06.09.2014 23:14, Romaine Wiki wrote:

Hello all,

I did a couple if simple tests on MediaWiki on Flow pages with often
occurring edits. The tests failed.


...


So, there is flow, and instead of the community can work with it as it
needs to work with, it does not flow but got stuck...

To answer the question, To Flow or not to Flow, it does not flow. I am 
not

able to do simple edits which are done every day.

Romaine


Hi Romaine

thanks for the great post.

May be indeed a good starting point would be to invite the community 
(not only en.wp and large projects, but also non-wikipedia and small 
projects) to list all functionalities of the talk pages they need and 
then discuss whether they are absolutely needed or we can survive 
without them. I am not aware of this discussion ever taken place (at 
least I am fairly active in several Wikimedia projects for a pretty long 
time and I have never heard about it).


Cheers
Yaroslav

___
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

Re: [Wikimedia-l] To Flow or not to Flow - it does not flow

[Romaine Wiki]

Hi,

I forgot to mention that we use a lot of template messages on talk pages to
inform users about something. In a part of these templates we automatically
add categories because we want to track the users who have problematic
behaviour. Testing this by adding a category to a message in Flow gives no
result.

Another issue I think of are deleted files and templates. They show up in
categories and special pages to be fixed.

Also often messages are copied to another page, including all the
wikisyntax. I haven't found any way to do that. Going from a Flow page to a
non-Flow page. This is a basic thing.

Also, so far I have seen, it is not possible to create a page with all the
discussions about a certain topic. This is currently possible to keep an
overview.

The option Permanent link is not working as I would expect. It is good that
there is a way to link to an individual topic (that is what Permanent link
currently does), but we also like and need the possibility to link to a
certain revision of a message. (This also would mean that if I post a
message, someone else reacts on it, I have to change my message and the
other person does it as well in his, that the permanent link to an earlier
version should show the topic as it was on that certain moment in time.)


I also found a bug, the links of the history page do not work in Dutch:
https://www.mediawiki.org/w/index.php?title=Topic:S1uggs1vsnq6d8g8action=historyuselang=nl


One last thing I somehow notice that Flow gives me some feeling of
clumsiness. I can't qualify it yet somehow. Some buttons are not on
intuitive places. But what concerns me is that it is no longer a wiki way
of editing/responding. The community loses control over their pages and
messages as it is all fixed in the software. Flow takes away the ability to
organize and I do not think that is good development. I can understand and
imagine that Flow can be handy to reply on each other, but the thing that
Wikipedia (and MediaWiki) makes great is the ability to re-organize. The
community loses with the current state of Flow to much their control over
the content of talk pages.

Greetings,
Romaine






2014-09-06 23:23 GMT+02:00 Yaroslav M. Blanter pute...@mccme.ru:

 On 06.09.2014 23:14, Romaine Wiki wrote:

 Hello all,

 I did a couple if simple tests on MediaWiki on Flow pages with often
 occurring edits. The tests failed.

  ...

  So, there is flow, and instead of the community can work with it as it
 needs to work with, it does not flow but got stuck...

 To answer the question, To Flow or not to Flow, it does not flow. I am not
 able to do simple edits which are done every day.

 Romaine


 Hi Romaine

 thanks for the great post.

 May be indeed a good starting point would be to invite the community (not
 only en.wp and large projects, but also non-wikipedia and small projects)
 to list all functionalities of the talk pages they need and then discuss
 whether they are absolutely needed or we can survive without them. I am not
 aware of this discussion ever taken place (at least I am fairly active in
 several Wikimedia projects for a pretty long time and I have never heard
 about it).

 Cheers
 Yaroslav


 ___
 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

Re: [Wikimedia-l] To Flow or not to Flow - it does not flow

[Dan Garry]

On 6 September 2014 15:33, Erik Moeller e...@wikimedia.org wrote:

 Flow doesn't automatically update template output -- it retains the
 output as it was when the user posted the comment. We can argue
 whether that's good or bad behavior, but it's worth doing so in the
 context of real examples. When would this cause problems?


I noticed this a few months ago and I think that in almost every case it's
not actually a problem. Many common talk pages templates are meant to be
substituted – in fact, some even spit out an error if you don't substitute
them! – so in most cases there's no substantial difference between
substitution and the way Flow currently does it; in both systems, using a
template generates a snapshot of the template at the time the post was made.

There is one notable exception to the above, which is talk page header
templates. One expects updates to a template used as a talk page header to
update every page the template is currently transcluded on, which is not
happening presently. {{talk header}} is currently transcluded on over
250,000 pages, so were these all Flow pages it would be excessively
laborious to edit all of those headers to force a reparsing of the template
were it updated. So this functionality, or something similar, should
probably be included in the Flow MVP [1] if it's deployed on a larger
scale. I think it's fine for now.

I expect that the reason most people find this so frustrating is not
because it results in any problems in and of itself, but because it
represents an inconsistency in the way that templates are handled in Flow
compared to how they're handled everywhere else, and therefore results in
Flow not behaving as an experienced user would expect. As I talked about
above though, the actual severity of that inconsistency is minor bordering
on trivial [2] in most cases.

Dan

[1]: https://en.wikipedia.org/wiki/Minimum_viable_product
[2]: https://www.mediawiki.org/wiki/Bugzilla/Fields#Severity

-- 
Dan Garry
Associate Product Manager, Mobile Apps
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] [Wikimedia Announcements] The Signpost -- Volume 10, Issue 34 -- 03 September 2014

[Wikipedia Signpost]

Arbitration report: ''Media viewer'' case is suspended
http://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/2014-09-03/Arbitration_report

Featured content: 1882 × 5 in gold, and thruppence more
http://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/2014-09-03/Featured_content

Op-ed: Automated copy-and-paste detection under trial
http://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/2014-09-03/Op-ed

Recent research: A Wikipedia-based Pantheon; new Wikipedia analysis tool suite; 
how AfC hamstrings newbies
http://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/2014-09-03/Recent_research

Traffic report: Holding Pattern
http://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/2014-09-03/Traffic_report

WikiProject report: Gray's Anatomy (v. 2)
http://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/2014-09-03/WikiProject_report


Single page view
http://en.wikipedia.org/wiki/Wikipedia:Signpost/Single

PDF version
http://en.wikipedia.org/wiki/Book:Wikipedia_Signpost/2014-09-03


https://www.facebook.com/wikisignpost / https://twitter.com/wikisignpost
--
Wikipedia Signpost Staff
http://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost

___
Please note: all replies sent to this mailing list will be immediately directed 
to Wikimedia-l, the public mailing list of the Wikimedia community. For more 
information about Wikimedia-l:
https://lists.wikimedia.org/mailman/listinfo/wikimedia-l
___
WikimediaAnnounce-l mailing list
wikimediaannounc...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikimediaannounce-l
___
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

Re: [Wikimedia-l] To Flow or not to Flow - it does not flow

[Romaine Wiki]

2014-09-07 0:33 GMT+02:00 Erik Moeller e...@wikimedia.org:

 On Sat, Sep 6, 2014 at 2:14 PM, Romaine Wiki romaine.w...@gmail.com
 wrote:

  I am an admin on Commons, and I regularly have to remove an image on a
 talk
  page because it is for example a violation of copyright. I see no way to
  remove the copyright violation from the message.
 
  Another thing I tried is the removal of a personal attack or a privacy
  issue. It is common on nl-wiki to remove a personal attack out of a
 message
  and replacing it by a template which says what happened. This is
 impossible
  to do.

 Please see my response to Todd here explaining the current permissioning:

 https://lists.wikimedia.org/pipermail/wikimedia-l/2014-September/074358.html


Okay. One point I miss there, which I tried to mention in the post I typed
before I saw this one, is that there is a fundamental question to be
answered. The question is: who is in control of the content of pages.
Should the software be in control of pages or the local community? Maybe
this sounds strange, but the community has now the ability to rearrange a
talk page to reflect better the needs.

I know examples of people who added a new header about the same topic which
was discussed above, and then the two headers were merged into one. Or the
order of the messages being changed. To split up a topic into two topics to
keep the subject on topic. Rearranging large topics by adding 3rd and 4th
degree headers in what messages are grouped. These changes are now used to
keep the overview over an topic.

But hiding a complete message while only a very small part, usually one or
two words, is requested to be hidden, is unbalanced.



  If a template is changed, its parameters on the various places where the
  template is added need to be changed as well. This is done by hand or
 with
  a bot (like AWB), both ways seems impossible with flow.

 Flow doesn't automatically update template output -- it retains the
 output as it was when the user posted the comment. We can argue
 whether that's good or bad behavior, but it's worth doing so in the
 context of real examples. When would this cause problems?

 Contrary to some descriptions, it's not quite the same as {{subst}}ing
 the template. You can still get back to the wikitext used produce the
 output, and change it, and potentially re-parse it. It just doesn't do
 so automatically (which is also not an inherent limitation).


Interesting way of handling templates. I need to think of what consequences
that would have, how it influences the way of using talk pages.

One question that already comes in my mind is what happens when in one
message a template is added, the template got deleted and later the user
who posted the original message wants to change the text. Will the template
stay look the same as the original post or will it be updated with saving
the change? (Sorry, I have not tested this yet.)


  If someone added a message to the wrong page, it is relocated to another
  talk page. Seems impossible to do here. If a message is considered to be
  inappropriate for a certain page, it is relocated, seems impossible with
  Flow.

 It doesn't support any kind of moving yet, that's still (like many
 features) to be developed, but unlike talk pages, it's architecturally
 viable to move a whole thread and its history, rather than copying and
 pasting content around, losing history, as we currently do routinely.


Good to read that it is something which is already thought of.
I think it is considered more important to have the possibility to move a
text (with a link to the source page for the history) than having the
history with it. But I think it can be an improvement if moving is possible
with history.


  Another thing I noticed is that I can't get a complete overview of all
  messages added to a certain talk page. After 10 messages, everything is
  hidden. A quick ctrl + F is impossible. When I know there was a
 discussion
  about a specific thing, I want to check the talk page easily by searching
  it completely, not possible. It is very annoying that I can't get a
  complete overview of all messages on a talk page, this is a basic need!

 Of course, which is why it's a high priority feature.


Good to know.


  To answer the question, To Flow or not to Flow, it does not flow. I am
 not
  able to do simple edits which are done every day.

 It's a system in early development, and has never been advertised as
 anything else. To draw conclusions about what it can and cannot do is,
 by definition, premature. A much more useful discussion is whether a
 system like it (provided some of its properties are clarified and
 improved) is desirable, and if not, what alternative ways there are to
 make talk pages more user-friendly, and what the limitations of those
 methods are. Also, to the extent that there are aspects of the Flow
 architecture that really are dealbreakers, we should fix them now.


Someone (a user) gave me today another 

Re: [Wikimedia-l] To Flow or not to Flow - it does not flow

[Erik Moeller]

On Sat, Sep 6, 2014 at 4:15 PM, Dan Garry dga...@wikimedia.org wrote:
 There is one notable exception to the above, which is talk page header
 templates. One expects updates to a template used as a talk page header to
 update every page the template is currently transcluded on, which is not
 happening presently. {{talk header}} is currently transcluded on over
 250,000 pages, so were these all Flow pages it would be excessively
 laborious to edit all of those headers to force a reparsing of the template
 were it updated. So this functionality, or something similar, should
 probably be included in the Flow MVP [1] if it's deployed on a larger
 scale. I think it's fine for now.

That makes perfect sense -- thanks for pointing it out. Stale headers
would suck indeed.

And now I'm taking a break from wikimedia-l til Monday. The weather's
nice, and the monthly posting limit is starting to loom into view. ;-)
Hope everyone has a nice weekend.

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

Re: [Wikimedia-l] Next steps regarding WMF-community disputes about deployments

[Risker]

I'm not going to reply in-line here, because I think there's been an
undoubtedly unintentional missing of the point here.  Instead I will tell a
story about a friend of mine.

Some years ago, when her children were 3 and 4, their family had a lovely
traditional Christmas Day, but something felt like it was missing.  She
told her husband about a tradition in her own family, where she and her
siblings had (since they were very young children) always bought their
mother a Terry's Chocolate Orange for Christmas - no matter what else her
mom got, that was considered the one essential Christmas gift under the
tree.  Mom would glow with joy when she unwrapped it, and her most
heartfelt thanks was for this specific present.  Some time later in the
day, she'd smack it open and everyone would get a piece.  My friend thought
it would be wonderful to start a similar tradition in her own young family.

Her husband remembered this story in the weeks leading up to the next
Christmas.  He plotted with the children, now 4 and 5; he researched the
best types of similar treats; and ultimately he helped the children
obtain a chocolate orange made of the finest Swiss chocolate, filled with
Grand Marnier liqueur, presented in an elegant marquetry box.  Everyone was
surprised when she burst into tears instead of smiles, and spent the whole
day snapping at people and generally being a grouch.  Finally her husband
confronted her and insisted she explain her behaviour.

What happened, of course, was that despite his best efforts, he'd missed
the real purpose of the chocolate orange.  He thought it was symbolic of
the esteem in which the matriarch was held. Really, it was about the
familial sharing of a special treat; the joy that the sharing brought to
both the recipient and the presenters.  But she couldn't share
liqueur-filled chocolate with her children, and could barely bring herself
to smack open the beautifully designed and presented chocolate.  In other
words, even though the gift looked brilliant on paper, it missed the point.

I think the design of Flow is much like the liqueur-filled chocolates.
It's missed the point of a discussion space on Wikimedia projects.  All the
use cases in the world, no matter how carefully researched and accounted
for, will help you build a discussion system to effectively replace a
discussion system if you don't understand that the one overriding,
incontrovertible feature of the current system is that it is a page that
acts just like all the other wiki pages, with all the same functions, and
anyone who can work on one wiki-page can work on any of them.  In other
words, you're building something that is explicitly different from
wiki-pages - but the expectation of the majority of the people who will use
these pages is that they work exactly like any other wiki-page.

This is what I mean when I say that you've not really understood how
wiki-discussion functions, and you've created the bells and whistles
without demonstrating an understanding of what the real, core functions of
these pages are.  The priority in design should focus on being able to
produce identical results for basic wiki-editing and page management: we
move pages, we protect them, we undo and revert edits, we fix typos and
correct URLS and links in each other's posts, we quote each other and
copy/paste, we modify each other's words when collaborating on the wording
of a complex section of an article, we get rid of trolling, we delete and
sometimes suppress personal attacks, we hat and archive individual
discussions.  Whether or not a post gets auto-signed is a frill compared
to those basic functions, and it is inevitable that the deprioritization of
the basics will result in people not really caring much about the frills
(no  matter how well they are executed) and focusing instead on what the
new system doesn't do.  This is the real parallel between Flow and Visual
Editor - focusing on the difference between the new product and that it
was intended to replace, instead of ensuring that things that had to be
similar or identical were considered the first step of design.

Risker/Anne




On 6 September 2014 02:13, Erik Moeller e...@wikimedia.org wrote:

 On Fri, Sep 5, 2014 at 10:42 PM, Risker risker...@gmail.com wrote:
  The major deficiencies that have long been identified in the current
  discussion system (and that can be addressed by technology) are all able
 to
  be addressed in MediaWiki software or by extensions. Automatic signatures
  have been done by bots for years; indenting could be added to the editing
  function gadget and moved to an extension; much work has already been
 done
  on graceful resolution of edit conflicts.  The ability to watchlist an
  individual thread or section of a page is more challenging but, I have
 been
  told, still possible.

 Let's just acknowledge that the limitations of what can reasonably be
 layered onto wikitext-based representation of comments have not been
 fully explored, rather 

Re: [Wikimedia-l] Next steps regarding WMF-community disputes about deployments

[Romaine Wiki]

2014-09-06 1:07 GMT+02:00 Steven Walling steven.wall...@gmail.com:

 On Fri, Sep 5, 2014 at 1:48 PM, John Mark Vandenberg jay...@gmail.com
 wrote:

  IMO the WMF should stop focusing on English Wikipedia as a target
  deploy site, and stop allowing its product management team and WMF
  staff in general to be salesman for it - it is scaring the community
  that all WMF staff seem to be so heavily vested in this 'product' as
  the salvation of the wikis.
 

 This is rank hyperbole.

 The MediaWiki deployment train delivers new software to all projects every
 week. One stage is to non-Wikipedia projects, which actually get new
 software *first.* Then in a second stage is for all Wikipedias
 simultaneously. So the default behavior for rollouts, if all you do is
 merge your code and wait, is that English Wikipedia gets basically no
 special treatment..[1]

 Now, for larger feature rollouts like VisualEditor or MediaViewer, the
 testing stage and eventual launch set their own special schedule. We have
 used English Wikipedia as a testing ground a lot in the past, which is
 natural when you consider a variety of factors.[2] That doesn't mean we
 haven't worked hard to test things out with non-English projects. Some
 examples:




I am sure you have tested things out on various wikis, but I can confirm
that seeing things been rolled out from a non-English wiki, they multiple
times look like if the English community has requested it or has been
copied from. One (large) example is the TemplateData part of the
VisualEditor which seems to us (nl-wiki) copied from the English Wikipedia,
in multiple ways. This is not how we work with templates. And I can name
many more examples.

Maybe it is not intended to adopt or specially fit with the English
Wikipedia, if I compare software changes with the English Wikipedia and
with the Dutch Wikipedia, most changes seem to fit exactly like the English
Wikipedia and not with the Dutch Wikipedia. So many times it is locally
thought and said that a change is likely requested by the English
community.

Not that we make such big deal of it as we are already used to it, still
this is how it is seen by at least some communities.

Romaine
___
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] new Code of Ethics from the Society of Professional Journalists

[James Salsman]

Today the Society of Professional Journalists updated its Code of
Ethics in two ways pertinent to wikimedians and Wikimedia projects:

1. The term journalist has been replaced with references to
journalism in areas that were seen to perpetuate the idea that the
practice of journalism requires official credentials distinguishing
professionals from citizen journalists.

2. The Code now states that all advocacy journalism and commentary
should be labeled as such.

http://www.spj.org/news.asp?ref=1282

http://www.spj.org/ethicscode.asp

___
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

Re: [Wikimedia-l] To Flow or not to Flow - it does not flow

[Pine W]

rik, I appreciate your engaging with this *early* enough for design
decisions to be adjusted before Flow gets to major rollouts.

Romaine, if the Dutch uses of features like templates are not being taken
into account in how features are designed, I suggest contacting the
Engineering community liaisons to make your needs known. I'm also sending
this email to Rachel so she can consider having one of her employees reach
out to you and the Dutch Wikipedia community.

Pine


On Sat, Sep 6, 2014 at 5:01 PM, Erik Moeller e...@wikimedia.org wrote:

 On Sat, Sep 6, 2014 at 4:15 PM, Dan Garry dga...@wikimedia.org wrote:
  There is one notable exception to the above, which is talk page header
  templates. One expects updates to a template used as a talk page header
 to
  update every page the template is currently transcluded on, which is not
  happening presently. {{talk header}} is currently transcluded on over
  250,000 pages, so were these all Flow pages it would be excessively
  laborious to edit all of those headers to force a reparsing of the
 template
  were it updated. So this functionality, or something similar, should
  probably be included in the Flow MVP [1] if it's deployed on a larger
  scale. I think it's fine for now.

 That makes perfect sense -- thanks for pointing it out. Stale headers
 would suck indeed.

 And now I'm taking a break from wikimedia-l til Monday. The weather's
 nice, and the monthly posting limit is starting to loom into view. ;-)
 Hope everyone has a nice weekend.

 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

Re: [Wikimedia-l] To Flow or not to Flow - it does not flow

[Keegan Peterzell]

On Sat, Sep 6, 2014 at 10:03 PM, Pine W wiki.p...@gmail.com wrote:

 rik, I appreciate your engaging with this *early* enough for design
 decisions to be adjusted before Flow gets to major rollouts.

 Romaine, if the Dutch uses of features like templates are not being taken
 into account in how features are designed, I suggest contacting the
 Engineering community liaisons to make your needs known. I'm also sending
 this email to Rachel so she can consider having one of her employees reach
 out to you and the Dutch Wikipedia community.

 Pine


Thanks for the initiative Pine. Romaine and I know each other and spent a
great deal of last July talking about template usage on the Dutch Wikipedia
in the context of VisualEditor :) . I'm not on the Flow team (I don't work
with VE anymore either) so I can't speak for experience there, but I do
know that thanks to Romaine's advocacy within the community and to me that
VisualEditor was never enabled by default on the Dutch Wikipedia. This
occurred because of consideration of the special-use case that community
has built with templates. It was intense time for sure, but the right
decision was certainly made as far as the Dutch Wikipedia goes.

-- 
Keegan Peterzell
Community Liaison, Product
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

Re: [Wikimedia-l] To Flow or not to Flow - it does not flow

[Keegan Peterzell]

On Sat, Sep 6, 2014 at 10:27 PM, Keegan Peterzell kpeterz...@wikimedia.org
wrote:

 ..last July...


July 2013, for clarity.

-- 
Keegan Peterzell
Community Liaison, Product
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

Re: [Wikimedia-l] To Flow or not to Flow - it does not flow

[Tim Davenport]

Erik Möller wrote:

 It's [Flow is] a system in early development, and has never been
advertised as anything else.

==

*This statement is simply not true.*

See the WMF's 2014-15 annual plan:
https://archive.org/details/WikimediaFoundation2014-15AnnualPlan

Page 20 (DIRECT QUOTE FOLLOWS):

*FLOW*

* Current state (June 2014): Flow is an experimental but already feature
rich alternative to talk pages which can be enabled by WMF on a per-page
basis and is currently used in production on a small number of 'real world'
pages, including a couple of WikiProjects and feedback pages for new
features.

*Key Milestones*

* We will aim to cover one major set of new deployments per quarter,
carefully picking use cases. Example use cases may include: additional
WikiProjects, shared conversation spaces like Teahouse and Village Pump,
entire wikis willing to switch to Flow, etc. Success will be reflected in
adoption/participation metrics, targeting improved participation dynamics
relative to talk pages.
* By the end of the fiscal year [i.e. June 30, 2015 --t.d.], we expect to
cover one major use case thoroughly (e.g. all user talk pages, all Village
Pump type pages, etc.)
* By the end of the fiscal year [i.e. June 30, 2015. --t.d.], the team will
be a multi-device team, ready to maintain and develop the user experience
for phones, tablets, and desktops.

(END QUOTE)


It is shocking to see an assertion from WMF's VP of Engineering and Product
Development that Flow has been consistently portrayed by WMF as nothing
more than a system in early development. In actual fact, it has been
portrayed as more or less finished software heading for a rollout in the
near future, as the above clearly illustrates.

Tim Davenport
Carrite on En-WP /// Randy from Boise on WPO
Corvallis, OR  (USA)
___
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

Re: [Wikimedia-l] Next steps regarding WMF-community disputes about deployments

[John Mark Vandenberg]

On Sun, Sep 7, 2014 at 12:18 PM, Romaine Wiki romaine.w...@gmail.com wrote:
 2014-09-06 1:07 GMT+02:00 Steven Walling steven.wall...@gmail.com:

 On Fri, Sep 5, 2014 at 1:48 PM, John Mark Vandenberg jay...@gmail.com
 wrote:

  IMO the WMF should stop focusing on English Wikipedia as a target
  deploy site, and stop allowing its product management team and WMF
  staff in general to be salesman for it - it is scaring the community
  that all WMF staff seem to be so heavily vested in this 'product' as
  the salvation of the wikis.
 

 This is rank hyperbole.

 The MediaWiki deployment train delivers new software to all projects every
 week. One stage is to non-Wikipedia projects, which actually get new
 software *first.* Then in a second stage is for all Wikipedias
 simultaneously. So the default behavior for rollouts, if all you do is
 merge your code and wait, is that English Wikipedia gets basically no
 special treatment..[1]

 Now, for larger feature rollouts like VisualEditor or MediaViewer, the
 testing stage and eventual launch set their own special schedule. We have
 used English Wikipedia as a testing ground a lot in the past, which is
 natural when you consider a variety of factors.[2] That doesn't mean we
 haven't worked hard to test things out with non-English projects. Some
 examples:




 I am sure you have tested things out on various wikis, but I can confirm
 that seeing things been rolled out from a non-English wiki, they multiple
 times look like if the English community has requested it or has been
 copied from. One (large) example is the TemplateData part of the
 VisualEditor which seems to us (nl-wiki) copied from the English Wikipedia,
 in multiple ways. This is not how we work with templates.

IIRC Visual Editor depends on writing TemplateData JSON for all your
projects templates, using a mix of local language (parameter
descriptions) and English (JSON keywords), which works real well for
languages like Arabic and Hebrew.

--
John Vandenberg

___
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

Re: [Wikimedia-l] To Flow or not to Flow - it does not flow

[Pine W]

Tim, I read that a bit differently.

Flow is an *experimental* but already feature
rich alternative...

We will aim to cover one major set of new deployments per quarter,
*carefully picking use cases*.

This looks to me like the kind of incremental rollout that is appropriate.
The idea of users opting into Flow on their personal talk pages would also
be a good development for testing purposes.

I think Lila may also have some ideas about how to stage rollouts and
integrate user feedback into the development process early and often.

Pine


On Sat, Sep 6, 2014 at 8:34 PM, Tim Davenport shoehu...@gmail.com wrote:

 Erik Möller wrote:

  It's [Flow is] a system in early development, and has never been
 advertised as anything else.

 ==

 *This statement is simply not true.*

 See the WMF's 2014-15 annual plan:
 https://archive.org/details/WikimediaFoundation2014-15AnnualPlan

 Page 20 (DIRECT QUOTE FOLLOWS):

 *FLOW*

 * Current state (June 2014): Flow is an experimental but already feature
 rich alternative to talk pages which can be enabled by WMF on a per-page
 basis and is currently used in production on a small number of 'real world'
 pages, including a couple of WikiProjects and feedback pages for new
 features.

 *Key Milestones*

 * We will aim to cover one major set of new deployments per quarter,
 carefully picking use cases. Example use cases may include: additional
 WikiProjects, shared conversation spaces like Teahouse and Village Pump,
 entire wikis willing to switch to Flow, etc. Success will be reflected in
 adoption/participation metrics, targeting improved participation dynamics
 relative to talk pages.
 * By the end of the fiscal year [i.e. June 30, 2015 --t.d.], we expect to
 cover one major use case thoroughly (e.g. all user talk pages, all Village
 Pump type pages, etc.)
 * By the end of the fiscal year [i.e. June 30, 2015. --t.d.], the team will
 be a multi-device team, ready to maintain and develop the user experience
 for phones, tablets, and desktops.

 (END QUOTE)


 It is shocking to see an assertion from WMF's VP of Engineering and Product
 Development that Flow has been consistently portrayed by WMF as nothing
 more than a system in early development. In actual fact, it has been
 portrayed as more or less finished software heading for a rollout in the
 near future, as the above clearly illustrates.

 Tim Davenport
 Carrite on En-WP /// Randy from Boise on WPO
 Corvallis, OR  (USA)
 ___
 Wikimedia-l mailing list, guidelines at:
 https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
 Wikimedia-l@lists.wikimedia.org
 https://meta.wikimedia.org/wiki/Mailing_lists/guidelineswikimedi...@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

Re: [Wikimedia-l] Feedback with Android on Commons

[Wil Sinclair]

Hi Yann, most of the issues you're describing sound like straight-up bugs.

When it comes to Android, it helps to know about issues that affect
some models but may not come up on the model/version that the
developer is using for testing. I think it's safe to say that the S4
is a '''must work''' Android platform. Some of the open bugs already
filed might apply; if there are closed bugs that aren't fixed on S4,
they may need to be reopened with a comment. And some of the issues
you've mentioned don't seem to be captured at all:

https://bugzilla.wikimedia.org/buglist.cgi?component=Androidlist_id=342313product=Commons%20App

IMO, we should be as diligent as possible when it comes to filing bugs
in the bug tracker. There are lots of concerns about the quality of
software that have been expressed here. Whether you happen to be
technical or not, this is one of the best ways each and every one of
us can do our part to build better software for our community.

Now that I've preached it, it's off to practice for me. I'm
downloading the commons app on both of my Nexus devices now and will
file any bugs I see. If anyone would like to join me and Yann, you can
install the app on your Android device here:

https://play.google.com/store/apps/details?id=org.wikimedia.commonshl=en

,Wil

On Sat, Sep 6, 2014 at 11:54 AM, Yann Forget yan...@gmail.com wrote:
 Hi,

 I am not a mobile user. So for the first time, I used the Mobile App
 on a Samsung S4 to upload a few pictures. I am quite disappointed, to
 say the least. I stopped counting how many times the application
 crashed while uploading just a few pictures. Then in reviewing my
 uploads, I can't see the description or the license, the field is
 blank. Then I discovered that the Application does not check if the
 name already exists, and uploads over the old file without warning.
 Luckily I didn't upload over someone else files. Then the categories I
 choose were not included, and also no warning there. It is a bit less
 bad on a tablet, where I can read the description and the license, but
 I can't add any category. I wonder how a software in such a bad
 condition gets deployed... Now it is much easier than on the desktop,
 and I understand why we get so many useless pictures from mobile
 uploads.

 https://commons.wikimedia.org/wiki/Commons_talk:Mobile_app#Feedback_on_Android

 Regards,

 Yann

 ___
 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

Re: [Wikimedia-l] To Flow or not to Flow

[Diego Moya]

 These are just assertions, however. I liked your earlier comments
 because they are testable against the architecture (even if the
 current implementation, early as it is, will fail many of these
 tests). What real world needs cannot be met by a comment-centric
 architecture for .. commenting? How important are they?


Erik, a major property of a document-centric architecture that is lost in a
structured one is that it's open-ended, which means that end users can
build new features and flows on top of it, without the need to request the
platform developers to build support for them (sometimes even without
writing new software at all; new workflows can be designed and maintained
purely through social convention).

That's not something that's easy to do when the basic raw material for
communication is split into comments and compartmentalized as table records
with different owners. Such change means that a community that now can
handle their own growth is made to utterly depend on the developers as
gatekeepers for its expansion. In a project where the development team is
understaffed, that's not a healthy proposition.

Sure, you have proposed a Workflow management system in the works, but with
all respect that's pie in the sky. That possibility is under-specified,
would require a lot of research and development with unclear goals and
requirements, and there's no guarantee that it would ever be fit for the
purpose. Please understand why we are wary of such proposal as the solution
for all the flexibility requirements.

Sincerely, it looks like you have this grand vision on how a comment
platform should work, and there's this blind spot to it. Despite repeated
attempts by several experienced editors trying to explain to you how this
architectural change would affect the essence of the project smooth
operation and well-being, you dismiss them by focusing on a single feature
at a time and missing the forest for the trees.

The point is not how we could replicate this or that feature on Flow, it's
how we allow support for all future workflows that we don't know about yet,
without requiring that software changes are made to the platform for each
new need. We know that Wiki systems are valid platforms to support such
expansion requirements, because we have seen them working; but we don't
know how the structured architecture will behave, and there's no reason to
believe it would work - no other structured system have achieved anything
similar. You ask how important are these needs? I tell you they are
*essential* to the community; the existing encyclopedia couldn't have been
built without this openness.

You asked Todd to make requirements that are testable against the
architecture. Well, I have one: how well does it allow end-users to build
new unforeseen workflows without requiring development of ad-hoc software
and changes to the platform?

I hope you give consideration to this argument before dismissing it as
inconsequential. So far it seems that the decision has already been made
and that your question (Do we want discussions to occur in document mode, or
in a structured comment mode?) is rhetorical. I hope that this happens not
to be true, and the decision is still open to debate from the community.
___
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