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  wrote:
> Hi,
>
> 2014-09-04 12:34 GMT+05:30 Erik Moeller :
>> On Sun, Aug 31, 2014 at 8:59 AM, Yann Forget  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, 

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  wrote:

> On Fri, Sep 5, 2014 at 11:13 PM, Erik Moeller  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,
> 
>
___
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, 

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 :
> On Sun, Aug 31, 2014 at 8:59 AM, Yann Forget  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, 

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 :
> 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 Bla ~~~) -- 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 t

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

[Erik Moeller]

On Fri, Sep 5, 2014 at 11:13 PM, Erik Moeller  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, 

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

[Erik Moeller]

On Fri, Sep 5, 2014 at 10:42 PM, Risker  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 noti

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  wrote:

> On Fri, Sep 5, 2014 at 9:49 PM, Erik Moeller  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 
>
>
> 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,
> 
>
___
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, 

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

[Risker]

Wil, the tl;dr here is "Philosophical beliefs aren't an effective
underpinning for good software design. Start over."


It's taken me a while to piece together much from the early discussions
about Flow and figure out how we got to where we are now.  It's my opinion
that the root of the problem is that, much as the WMF wants to move toward
being a "software" or "tech" organization, it really doesn't have very much
history or experience in the kind of  ground-up software design and
deployment that is conducive to successful implementation.  Tech
organizations seeking to redevelop a core function normally start by
gathering extensive data on the current system,  identifying key functions
that must be incorporated into the new system, understanding how the
current system is used, what its strengths and weaknesses are, and ensuring
that even early iterations will at least include the key functions and
strengths from the soon-to-be-deprecated system.  This baseline background
research was never really done before investing in the development of Flow.
Instead, Flow very much comes across as software being designed according
to philosophical principles rather than function.

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.

Several of the features identified as "must-do" have turned out not to
quite work out.  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, and there is no method by which users can add an
"explanatory" note to their signature such as "formerly known as
User:Whatever".  The "more efficient" indenting has reduced possible
indents to three levels, without exception; even in simple discussions,
it's pretty clear that hasn't really worked out as it's often difficult to
figure out who is responding to which post.  "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.  With broader early discussion, some of these would
probably have been fleshed out before getting this far.


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.  This is a philosophical question, and doesn't actually have that
much to do with technology - and this conversation has never really taken
place anywhere but by a bunch of guys who are into making cool software
and, often as not, have little interest in the kinds of discussions that
normally occur on Wikimedia projects.  There has certainly never really
been a discussion with the broader community about what would better serve
in discussions. More importantly, some of the core assumptions and goals
upon which Flow has been built[1] have very little to do with technology at
all - plenty of research indicates that new users are driven away by the
nature of discussions rather than the technological challenges of
participation -  and the lack of active broad community consultation means
that the development team really doesn't know what's working well, what's
problematic, and what kind of efficiencies experienced users are looking
for. There's absolutely no basis to believe that Flow  is in any way likely
"to encourage [more] *meaningful conversations* that support
collaboration".  (I'd love to see what kind of metrics would be used to
assess the meaningfulness of conversations!)


And the other key issue is a complete lack of recognition that the more UIs
a new user needs to learn to develop competency, the lower the likelihood
that they'll actually be able to develop the necessary skills to become
fully functioning members of the editing community.  The Wikimedia "family"
has largely bought in to the necessity to introduce a WYSIWYG editing
interface (that would be VisualEditor), and to recognize that wikitext
editing needs to remain in existence as well.  Adding a third one whose
primary purpose will be to talk about the content being created using the
other two is counterintuitive at best.


Risker/Anne


[1] https://www.mediawiki.org/wiki/Flow


On 5 September 2014 21:53, Wil Sinclair  wrote:

> Risker, what do you think might get us all back on track for Flow?
> Shou

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

[Balázs Viczián]

Congrats from Wikimedia Hungary!

Balázs
2014.09.02. 19:46, "Carlos M. Colina"  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 
> 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, 

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

[Pete Forsyth]

On Fri, Sep 5, 2014 at 9:49 PM, Erik Moeller  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 


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, 

[Wikimedia-l] To Flow or not to Flow

[Erik Moeller]

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 Bla ~~~) -- 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
- It had a full history model for the thread itself, not just comments
- It preserved comments essentially as individual wiki pages, with
their own history
- It had a built-in notion of thread summaries, collaboratively
written, for closing comments

As WMF started to grow, it took on development of LiquidThreads --
with one developer, Andrew Garrett, who did an amazing job cleaning up
the codebase and rethinking many of the assumptions David had made.
LQT got to a point where some Wikimedia wikis actu

[Wikimedia-l] [Wikimedia Announcements] [PRESS RELEASE] Wikimedia Commons celebrates its 10th anniversary

[Tilman Bayer]

(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
. 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

(To be unsubscribed from this press release distribution list, please reply 
with 'UNSUBSCRIBE' in the subject line)___
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, gu

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

[Wil Sinclair]

Risker, what do you think might get us all back on track for Flow?
Should the WMF consider a reset of the project and proceed only after
making specific and enforceable commitments to work with the
community? Is a total rewrite in order? Should we go completely tabla
rasa on it and revisit whether we need something like this at all?

,Wil

On Fri, Sep 5, 2014 at 10:58 AM, Risker  wrote:
> I think there have been some pretty strong indications over the years that
> the current talk page system needs to be improved.  However, there's been
> little discussion at all about whether Flow is that improvement.  I have
> been following the development for quite a while, and it really looks like
> the system was developed backwards: essential functions for effective
> discussion that already exist and are used on a daily basis were not
> included in the initial designs, while the design incorporated plenty of
> bells and whistles that were considered desirable (although the reasons for
> desirability weren't necessarily universally held or particularly clear).
> This has resulted in a huge amount of re-engineering to incorporate (some
> of the) needed functions , and a lot of downplaying of the feedback given
> because the feedback has conflicted with the "bells and whistles" of the
> original design.  There is also the fact that it would add another
> completely different user interface to the editing process, which increases
> barriers for existing users but even more so for new users.
>
> In other words, the issues with Flow are so deeply rooted in its core
> design and philosophy that it may not be possible to come up with a product
> that is actually useful on the projects we have to replace the discussion
> system we have.  It seems that the Flow team has assembled the ingredients
> to make a chocolate cake with the hope that it will be a suitable
> replacement for vegetable stew.
>
> Risker/Anne
>
>
>
>
> On 5 September 2014 13:29, 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
>>
>> On Fri, Sep 5, 2014 at 9:34 AM, Marc A. Pelletier 
>> wrote:
>> > On 09/05/2014 11:12 AM, Yaroslav M. Blanter wrote:
>> >> On 25.08.2014 06:07, Marc A. Pelletier wrote:
>> >> FLOW?
>> >
>> > Last I checked, Flow isn't deployed except as experiments in a handful
>> > of places, and is still in active deployment.
>> >
>> > But you're correct that this would constitute a replacement rather than
>> > a new method alongside the old.  A long, long overdue and desperately
>> > needed replacement -- but a replacement nonetheless.
>> >
>> > That also explains the very deliberate development and feedback loop.
>> >
>> > -- 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,
>> 
>>
>> ___
>> 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,
>> 
>>
> ___
> Wikimedia-l mailing list, guidelines at: 
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l@list

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

[Wil Sinclair]

Actually, Tim, you're not giving me credit for all the other mistakes I made. :D

FWIW, lessons have been learned, and there is a new version in the
works. But many people on this list have specifically said that they
don't want to talk about Offwiki, and we should respect their wishes.

I did make a big mistake that's relevant to this thread when I
deployed Liquid Threads on a project that shall remain nameless ;): I
didn't look in to it enough to know that it would essentially take
over all talk pages. I thought I had sandboxed it on a single page. I
accidentally surprised my users with it, and they did not like it.

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.
The WMF '''must''' get this one right. And that's not possible without
our help.

When I see that a problem I care about needs to be solved, my first
question is "what can I do to help?" Telling others what they can do
is just too easy; after all, it's not like I commit to making an
effort in doing so. So, starting with myself, I'd say the first step
is figuring out what the community's expectations are in building and
rolling out the release. How can I help prevent the WMF's simply
making a death march to a debacle by ignoring our expectations? Maybe
organizing our thoughts might help.

Here's a start to a list based on stuff I've read here so far:

1) The WMF should not only involve the community in setting feature
priority, but commit to honoring community sentiment when it is
expressed overwhelmingly on any given feature. A very rough example
would be something like if there are 250 more "increase priority"
votes than "decrease priority" votes, the feature would be bumped up.

2) Priorities should be fully transparent to the community, and they
should mean something. For example, all "must-haves" must be
implemented before any "should-haves" are worked on.

3) User studies should be invoked to convince the community that
something is of value to users who may not have as much experience,
and not offered as an excuse while shoving features down the
community's throat.

4) (My own addition, here) A mechanism to make it easy to gather
community feedback and quantify community sentiment '''in one place
per feature''' should be set up. No hopping from onwiki to bugzilla to
trello to whatever the WMF engineering team decides they want to use
next. If the WMF wants to use a new tool, it should integrate with the
toolset we're already used to IMO so that information doesn't get lost
behind links.

,Wil

On Fri, Sep 5, 2014 at 2:43 PM, Tim Davenport  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
> Carr

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

[James Forrester]

On 5 September 2014 17:25, John Mark Vandenberg  wrote:

> One of the more recent WMF products:
>
> https://www.mediawiki.org/wiki/Extension:PageTriage
>
> "An important note is that some of the configuration and code is
> specific to the English-language Wikipedia's workflows and as it's
> constructed now the extension is pretty much impossible to
> internationalize: developing a universal, stripped-down version is on
> our to-do list. (See bugzilla:48552.)"
>
> [bugzilla 48552 was created May 2013, and prioritised as "Lowest" by
> James Forrester, and no change since.]
>

​As a quick note, I prioritised it on behalf of the team who owned the
product based on asking them; it's not my product, so it's not my call as
to what the priority should be…​

​J.
-- 
James D. Forrester
Product Manager, Editing
Wikimedia Foundation, Inc.

jforres...@wikimedia.org | @jdforrester
___
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, 

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

[John Mark Vandenberg]

On Sat, Sep 6, 2014 at 9:07 AM, Steven Walling  wrote:
> On Fri, Sep 5, 2014 at 1:48 PM, John Mark Vandenberg 
> 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.

Oh, I love you too.

> 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]

That is unrelated; I am talking about 'features', which you address below...

> 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.

I urge the WMF to rethink using English Wikipedia as their testing
ground, as using it as the "natural" choice results in 'bad' designs
and community engagement around deployment.

One of the more recent WMF products:

https://www.mediawiki.org/wiki/Extension:PageTriage

"An important note is that some of the configuration and code is
specific to the English-language Wikipedia's workflows and as it's
constructed now the extension is pretty much impossible to
internationalize: developing a universal, stripped-down version is on
our to-do list. (See bugzilla:48552.)"

[bugzilla 48552 was created May 2013, and prioritised as "Lowest" by
James Forrester, and no change since.]

A lot of what I am suggesting is found in:

https://meta.wikimedia.org/wiki/User:Okeyes_(WMF)/Localising_page_curation

Flow is going to be a very major deploy.  Do not make decisions about
that deployment based on which language your engineers use at the
water cooler or in commit messages.  Employ the right people now to
assist in a gradual deploy to communities that are ready for the pain
involved.

My guess is the English Wikipedia community would prefer to know that
Flow has been accepted on quite a few projects before it commences any
migration.  But maybe I am wrong; maybe that community will want to be
a testing ground.  Will you ask them?

--
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, 

Re: [Wikimedia-l] AffCom - Call for candidates 2015 [UPDATE]

[Pine W]

Hi Varnet,

I have emailed Affcom or individual members on more than one occasion for
an update about the Cascadia Wikimedians user group application. We
finished our response to Affcom's last question on August 7, which was
almost a month ago. We have projects that we would like to start that are
waiting on Affcom's approval. Is the delay related to the call for new
members and the change to an on-wiki process for user group applications?

Thanks,

Pine


On Thu, Sep 4, 2014 at 11:06 PM, Gregory Varnum 
wrote:

> Thank you everyone for your feedback and ideas. They're already being
> discussed internally by AffCom and may be reflected in our next call for
> candidates. There will not be any changes to the process for this call.
>
> Some additional information folks may find helpful...
>
> This call will add at least four people to fill some openings on the
> committee created by Cynthia's passing earlier this year, to replace a
> couple members transitioning into non-voting advisor roles (out of personal
> necessity), and expansion by one seat (to help with our growing workload
> and respond to concerns of response time).
>
> This does not replace our usual annual call for members, which will be
> coming later this year. That call will fill vacancies left by members whose
> terms are expiring (or possibly re-elect those members) and another
> possible expansion of the committee, that call is also anticipated to fill
> at least four seats on the committee.
>
> Before each annual call for members, we do a review of the process, and
> sometimes make slight tweaks. Prior to this email, we had committed to
> reviewing the process with our new, recently appointed, WMF board liaisons.
> This feedback is helpful and will be taken into consideration. For a
> variety of reasons, we decided not to delay this call for candidates any
> further (and risk having to delay or merge it with the next call) and
> instead use the process previously established.
>
> As to the specific suggestions, I have heard compelling arguments for our
> existing approach, and for changes. I have not personally come to any final
> conclusions on what changes, if any, should be made, and I suspect the same
> is true for the rest of AffCom. In part, we wanted to fill the vacancies to
> help provide additional input on any changes to this process we may make.
> Keep in mind, we are also engaging in a much larger discussion internally
> and with affiliates, the WMF Board, and WMF staff about AffCom's
> activities, scope, processes, etc. This is done annually (and currently
> ongoing), and has resulted in some already visible changes this year (such
> as the liaisons, introduction of new resources for affiliates, etc.) with
> more to come, and may result in changes to things like the AffCom charter,
> which requires a WMF Board vote. I am not yet sure if that will happen, but
> I want to give you some sense of the overall scope of our current
> conversation and why this specific process was not changed this time
> around.
>
> I generally try to avoid comparisons between the WMF committees as they are
> each rather unique in purpose and composition needs. Speaking specifically
> to AffCom, I can say that we look a great deal at the combined skills
> voting members will bring to the committee, which sometimes means qualified
> candidates are passed for a year to prevent too much overlap of any one
> existing skill area (such as legal or nonprofit capacity building) or
> consideration such as diversity or language. There have been concerns that
> a public process would discourage people from subjecting themselves to the
> process more than once, some candidates also fear retaliation given the
> complex politics within the affiliates world, and the current process is
> believed to have helped us with encouraging candidates to apply who can
> help us fill our diversity or skill gaps. I offer that not as a defense,
> but as some insight into how the process got to this point.
>
> We recently finished the conversion of the Wikimedia user group application
> process from email based to an on-wiki based process and a faster approval
> process based on feedback we received (details are on-wiki and coming
> on-listserv soon). So that is certainly an option we are considering. Our
> last request for an additional committee mailing list took several weeks to
> process, and we try not to burden operations with urgent requests. That
> said, frankly, we have leaned towards convenience and the idea of moving it
> to a WMF hosted address simply has not come up recently and we will seek
> input from WMF operations on their preferences and ideas. I am personally
> intrigued by the suggestion of OTRS usage, but for for broader applications
> as well.
>
> From just a few years ago as ChapCom to today as AffCom, this committee has
> consistently changed and evolved based on feedback and movement needs. I
> appreciate not always to some people's liking, but let's face 

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

[Pine W]

FWIW, ironically the tangled discussions about MediaViewer across multiple
pages have made me think that having a more organized way to read
discussions would be a good idea. My understanding is that this is one of
Flow's objectives. If Flow can achieve this in a way that is helpful and
non-disruptive then I think Flow may save power users time because we may
be able to follow multi-page discussions easily. I would appreciate it if
Flow helped with that. Of course, the design, implementation and testing
need to be done carefully, and I hope there is heavy community involvement
in reviewing Flow long before it gets sent to the largest and most
sophisticated wikis.

Pine


On Fri, Sep 5, 2014 at 4:07 PM, Steven Walling 
wrote:

> On Fri, Sep 5, 2014 at 1:48 PM, John Mark Vandenberg 
> 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:
>
> -- MediaViewer spent a long time being tested outside English Wikipedia
> before it ever touched that project. It started with pilots in non-English
> Wikipedias and English Wikivoyage.[3]
> -- Flow is currently soliciting editors on non-English projects to test it
> out voluntarily on a sub-set of pages. Any projects that want to help shape
> the future of this software should pick a discussion space they want to use
> for testing and speak up.
> -- My team (Growth) has begun waiting for translations of experimental
> interfaces, so we can A/B test in many languages simultaneously. We're
> about to do this again in this month, by testing task recommendations in 12
> languages right from the start.[4] We've done with other projects as well,
> like A/B testing changes aimed at anonymous editors in four languages.
> -- The Content Translation project is starting with Spanish and Catalan
> Wikipedias.[5]
>
> After we get past the testing stage, none of this erases the fact that
> English Wikipedia is still the largest project by far, and is a major
> problem spot to be dealt with regarding issues related to new editor
> acquisition and retention. The data clearly suggests that it's a project we
> should be focusing on if we want to fix these problems, but we're certainly
> not ignoring others.
>
> 1). wikitech.wikimedia.org/view/Deployments
> 2). All technical staff and community contributors share English as their
> working language. Software gets built in English first obviously, so we
> don't have to wait on translations as a blocker for deployment. English
> Wikipedia is also our largest project, so we can get larger randomized
> samples during A/B tests. Making A/B tests shorter while also retaining
> accuracy is good.
> 3). https://www.mediawiki.org/wiki/Multimedia/Media_Viewer/Release_Plan
> 4).
>
> https://meta.wikimedia.org/wiki/Research:Task_recommendations/Experiment_one
> 5). https://www.mediawiki.org/wiki/Content_translation/Roadmap
> ___
> 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,
> 
>
___
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, 

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

[Steven Walling]

On Fri, Sep 5, 2014 at 1:48 PM, John Mark Vandenberg 
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:

-- MediaViewer spent a long time being tested outside English Wikipedia
before it ever touched that project. It started with pilots in non-English
Wikipedias and English Wikivoyage.[3]
-- Flow is currently soliciting editors on non-English projects to test it
out voluntarily on a sub-set of pages. Any projects that want to help shape
the future of this software should pick a discussion space they want to use
for testing and speak up.
-- My team (Growth) has begun waiting for translations of experimental
interfaces, so we can A/B test in many languages simultaneously. We're
about to do this again in this month, by testing task recommendations in 12
languages right from the start.[4] We've done with other projects as well,
like A/B testing changes aimed at anonymous editors in four languages.
-- The Content Translation project is starting with Spanish and Catalan
Wikipedias.[5]

After we get past the testing stage, none of this erases the fact that
English Wikipedia is still the largest project by far, and is a major
problem spot to be dealt with regarding issues related to new editor
acquisition and retention. The data clearly suggests that it's a project we
should be focusing on if we want to fix these problems, but we're certainly
not ignoring others.

1). wikitech.wikimedia.org/view/Deployments
2). All technical staff and community contributors share English as their
working language. Software gets built in English first obviously, so we
don't have to wait on translations as a blocker for deployment. English
Wikipedia is also our largest project, so we can get larger randomized
samples during A/B tests. Making A/B tests shorter while also retaining
accuracy is good.
3). https://www.mediawiki.org/wiki/Multimedia/Media_Viewer/Release_Plan
4).
https://meta.wikimedia.org/wiki/Research:Task_recommendations/Experiment_one
5). https://www.mediawiki.org/wiki/Content_translation/Roadmap
___
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, 

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

[Tim Davenport]

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, 

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

[John Mark Vandenberg]

On Sat, Sep 6, 2014 at 3:29 AM, 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?
>
> ...
>
> What can we do to make the Flow rollout as smooth as starting '''now'''?

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.

Risker's assessment of the design problems is spot on.  As such, a
typical WMF-style big bang deploy of Flow is going to be the most
almighty bang the WMF has ever seen.  And the community is rightly
worried that 2015 is going to be the year that WMF forces Flow onto
the projects using its typical deploy methodology.

Start development of a rollout plan, and gain consent from the
communities on that rollout plan.

After rollout on MediaWiki has stablised, Meta-Wiki should be high on
the deploy list, as should any wiki which has LQT enabled by community
request.  Until discussion-focused wikis, such as Meta, universally
*likes* Flow, trialling it or rolling it out onto any
'work'/content-focused wiki without community consent is silly.  Until
it is satisfactorily deployed onto at least one non-English language
content project, it shouldnt be deployed onto English Wikipedia, as it
is safe to assume that the design will be too English Wikipedia
specific, and will fail badly on non-English projects, becoming
another WMF tool which looks nice on English Wikipedia but other
projects cant have it because it is designed wrong.

Allow project level opt-out of the Flow rollout plan.  Focus on the
projects that want it, and find/employ community advocates with the
necessary language skills for the projects at the top of the rollout
plan. They need to start work *now*.  They need to document existing
project workflows, talking with bot operators and site admins
especially when developing a migration plan.  Bot and gadget software
will need to be re-engineered *before* the deploy.

--
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, 

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

[Wil Sinclair]

Interesting. What I'm noticing in both this discussion and the
discussions around MV is that a lot of us think that the solution has
value, but the features are not prioritized well. I don't have much
experience with Trello, but I know of lots of other tools (Bugzilla is
one, I believe) that can support discussions from the community per
feature/bug and have a "voting" feature.

I don't support RfC's on full systems. If we get to this point we've
all been doing it wrong for far too long to have an easy fix. But I
think that RfC-like discussions on every individual feature make a lot
of sense. And I think that one of the biggest steps the WMF can take
is to base prioritization of features on such "RfC"'s in a
well-defined and well-understood way. IMO, user studies are important,
but they'd be better used to '''convince''' the community that
something is useful from a perspective that may be very different from
a very experienced user's, rather than force features down our
throats.

I know that this is already happening to some degree. But is the WMF
'''obligated''' to prioritize features based on community feedback?

As a separate question, would we find it easier to do this onwiki, and
are there extensions that we can build with the WMF to facilitate such
discussions and feature management? Or we cool with the tools we
already have?

,Wil

On Fri, Sep 5, 2014 at 10:58 AM, Risker  wrote:
> I think there have been some pretty strong indications over the years that
> the current talk page system needs to be improved.  However, there's been
> little discussion at all about whether Flow is that improvement.  I have
> been following the development for quite a while, and it really looks like
> the system was developed backwards: essential functions for effective
> discussion that already exist and are used on a daily basis were not
> included in the initial designs, while the design incorporated plenty of
> bells and whistles that were considered desirable (although the reasons for
> desirability weren't necessarily universally held or particularly clear).
> This has resulted in a huge amount of re-engineering to incorporate (some
> of the) needed functions , and a lot of downplaying of the feedback given
> because the feedback has conflicted with the "bells and whistles" of the
> original design.  There is also the fact that it would add another
> completely different user interface to the editing process, which increases
> barriers for existing users but even more so for new users.
>
> In other words, the issues with Flow are so deeply rooted in its core
> design and philosophy that it may not be possible to come up with a product
> that is actually useful on the projects we have to replace the discussion
> system we have.  It seems that the Flow team has assembled the ingredients
> to make a chocolate cake with the hope that it will be a suitable
> replacement for vegetable stew.
>
> Risker/Anne

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

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

[Risker]

I think there have been some pretty strong indications over the years that
the current talk page system needs to be improved.  However, there's been
little discussion at all about whether Flow is that improvement.  I have
been following the development for quite a while, and it really looks like
the system was developed backwards: essential functions for effective
discussion that already exist and are used on a daily basis were not
included in the initial designs, while the design incorporated plenty of
bells and whistles that were considered desirable (although the reasons for
desirability weren't necessarily universally held or particularly clear).
This has resulted in a huge amount of re-engineering to incorporate (some
of the) needed functions , and a lot of downplaying of the feedback given
because the feedback has conflicted with the "bells and whistles" of the
original design.  There is also the fact that it would add another
completely different user interface to the editing process, which increases
barriers for existing users but even more so for new users.

In other words, the issues with Flow are so deeply rooted in its core
design and philosophy that it may not be possible to come up with a product
that is actually useful on the projects we have to replace the discussion
system we have.  It seems that the Flow team has assembled the ingredients
to make a chocolate cake with the hope that it will be a suitable
replacement for vegetable stew.

Risker/Anne




On 5 September 2014 13:29, 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
>
> On Fri, Sep 5, 2014 at 9:34 AM, Marc A. Pelletier 
> wrote:
> > On 09/05/2014 11:12 AM, Yaroslav M. Blanter wrote:
> >> On 25.08.2014 06:07, Marc A. Pelletier wrote:
> >> FLOW?
> >
> > Last I checked, Flow isn't deployed except as experiments in a handful
> > of places, and is still in active deployment.
> >
> > But you're correct that this would constitute a replacement rather than
> > a new method alongside the old.  A long, long overdue and desperately
> > needed replacement -- but a replacement nonetheless.
> >
> > That also explains the very deliberate development and feedback loop.
> >
> > -- 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,
> 
>
> ___
> 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,
> 
>
___
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, 

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

[Wil Sinclair]

Andreas, what would you do process-wise from the perspective of the
WMF and/or the broader community to improve communication and its
impact on development of Flow?

,Wil

On Fri, Sep 5, 2014 at 10:11 AM, Andreas Kolbe  wrote:
> I'm not sure the term "loop" is appropriate. So far, I see little evidence
> that feedback provided [1] is making any appreciable difference.
>
> [1] https://en.wikipedia.org/wiki/Wikipedia_talk:Flow
>
>
> On Fri, Sep 5, 2014 at 5:34 PM, Marc A. Pelletier  wrote:
>
>> On 09/05/2014 11:12 AM, Yaroslav M. Blanter wrote:
>> > On 25.08.2014 06:07, Marc A. Pelletier wrote:
>> > FLOW?
>>
>> Last I checked, Flow isn't deployed except as experiments in a handful
>> of places, and is still in active deployment.
>>
>> But you're correct that this would constitute a replacement rather than
>> a new method alongside the old.  A long, long overdue and desperately
>> needed replacement -- but a replacement nonetheless.
>>
>> That also explains the very deliberate development and feedback loop.
>>
>> -- 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,
>> 
>>
> ___
> 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, 
> 

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

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

[Wil Sinclair]

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

On Fri, Sep 5, 2014 at 9:34 AM, Marc A. Pelletier  wrote:
> On 09/05/2014 11:12 AM, Yaroslav M. Blanter wrote:
>> On 25.08.2014 06:07, Marc A. Pelletier wrote:
>> FLOW?
>
> Last I checked, Flow isn't deployed except as experiments in a handful
> of places, and is still in active deployment.
>
> But you're correct that this would constitute a replacement rather than
> a new method alongside the old.  A long, long overdue and desperately
> needed replacement -- but a replacement nonetheless.
>
> That also explains the very deliberate development and feedback loop.
>
> -- 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, 
> 

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

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

[Andreas Kolbe]

I'm not sure the term "loop" is appropriate. So far, I see little evidence
that feedback provided [1] is making any appreciable difference.

[1] https://en.wikipedia.org/wiki/Wikipedia_talk:Flow


On Fri, Sep 5, 2014 at 5:34 PM, Marc A. Pelletier  wrote:

> On 09/05/2014 11:12 AM, Yaroslav M. Blanter wrote:
> > On 25.08.2014 06:07, Marc A. Pelletier wrote:
> > FLOW?
>
> Last I checked, Flow isn't deployed except as experiments in a handful
> of places, and is still in active deployment.
>
> But you're correct that this would constitute a replacement rather than
> a new method alongside the old.  A long, long overdue and desperately
> needed replacement -- but a replacement nonetheless.
>
> That also explains the very deliberate development and feedback loop.
>
> -- 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,
> 
>
___
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, 

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

[Marc A. Pelletier]

On 09/05/2014 11:12 AM, Yaroslav M. Blanter wrote:
> On 25.08.2014 06:07, Marc A. Pelletier wrote:
> FLOW?

Last I checked, Flow isn't deployed except as experiments in a handful
of places, and is still in active deployment.

But you're correct that this would constitute a replacement rather than
a new method alongside the old.  A long, long overdue and desperately
needed replacement -- but a replacement nonetheless.

That also explains the very deliberate development and feedback loop.

-- 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, 

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

[Yaroslav M. Blanter]

On 25.08.2014 06:07, Marc A. Pelletier wrote:

On 08/24/2014 11:19 PM, Pine W wrote:

I have
heard people say "don't force an interface change on me that I don't 
think

is an improvement."


I do not recall a recent interface change deployment that wasn't
accompanied with, at the very least, some method of opting out.  Did I
miss one?

-- Marc



FLOW?

Unless you count leaving the project as opt-out.

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, 

Re: [Wikimedia-l] add use of wikimetrics to my resume

[Pine W]

Fortunately I haven't ever done a reply all accidentally. I'm pretty
vigilant about keeping sensitive data where it belongs. I have heard a
nightmare scenario about legally privileged documents being distributed to
opposing counsel, fortunately not by WMF.

Pine
On Sep 5, 2014 6:04 AM, "Liam Wyatt"  wrote:

> Note to self:
> Add "Familiarity with dangers of the 'reply-all' and 'auto-complete
> address' functions in e-mail clients.
>
> ;-)
>
> -Liam
>
> On 5 September 2014 13:52, Pine W  wrote:
>
> > Sorry, that was intended as a note to self.
> >
> >
> > On Fri, Sep 5, 2014 at 4:51 AM, Pine W  wrote:
> >
> > >
> > >
> > ___
> > 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,
> > 
> >
> ___
> 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,
> 
___
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, 

Re: [Wikimedia-l] Where should we organize ideas for the Strategic Plan update?

[Samuel Klein]

How about a category on Meta with a set of infobox templates like those on
the strategy wiki?  With a summary kept updated at [[m:strategy]]
On Sep 5, 2014 5:03 AM, "Pine W"  wrote:

> Heh. That was not my first time when I started typing my email address and
> instead Gmail autofilled wikimedia-l. This is what I get for choosing
> wiki.pine instead of pine.wiki. I need some coffee or more sleep.
>
> Anyway, this is what was supposed to go to Wikimedia-l:
>
> Do we have a central place for collecting ideas relevant to the strategic
> plan update? I suppose we could use Idealab but a dedicated space on Meta
> might be easier for everyone in the long run, or we could re-open the
> Strategy wiki.
>
> Thanks,
>
> Pine
> ___
> 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,
> 
___
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, 

Re: [Wikimedia-l] add use of wikimetrics to my resume

[Liam Wyatt]

Note to self:
Add "Familiarity with dangers of the 'reply-all' and 'auto-complete
address' functions in e-mail clients.

;-)

-Liam

On 5 September 2014 13:52, Pine W  wrote:

> Sorry, that was intended as a note to self.
>
>
> On Fri, Sep 5, 2014 at 4:51 AM, Pine W  wrote:
>
> >
> >
> ___
> 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,
> 
>
___
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, 

[Wikimedia-l] Where should we organize ideas for the Strategic Plan update?

[Pine W]

Heh. That was not my first time when I started typing my email address and
instead Gmail autofilled wikimedia-l. This is what I get for choosing
wiki.pine instead of pine.wiki. I need some coffee or more sleep.

Anyway, this is what was supposed to go to Wikimedia-l:

Do we have a central place for collecting ideas relevant to the strategic
plan update? I suppose we could use Idealab but a dedicated space on Meta
might be easier for everyone in the long run, or we could re-open the
Strategy wiki.

Thanks,

Pine
___
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, 

Re: [Wikimedia-l] add use of wikimetrics to my resume

[Pine W]

Sorry, that was intended as a note to self.


On Fri, Sep 5, 2014 at 4:51 AM, Pine W  wrote:

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

[Wikimedia-l] add use of wikimetrics to my resume

[Pine W]

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