subject:"\\\\\\\[Wikimedia\\\\\\\-l\\\\\\\] Let's have the courage to sit down and talk about VisualEditor"

Re: [Wikimedia-l] Let's have the courage to sit down and talk about VisualEditor

2013-08-05 Thread Craig Franklin

Erik,

I don't agree with everything you're saying here, but I for one appreciate
the candour and openness you're displaying in this discussion, not to
mention a willingness to act on ideas from the community. You've already
implemented what my suggestion was going to be (sticking the word Beta in
the tab so people know what they're getting), so there's not much left
except to say thanks and I appreciate it.

Cheers,
Craig Franklin

On 2 August 2013 03:05, Erik Moeller e...@wikimedia.org wrote:

On Thu, Aug 1, 2013 at 9:36 AM, Kevin Wayne Williams
kwwilli...@kwwilliams.com wrote:
The editor was able to change a 4 to a 5 in an existing table, that's
true.
Could that editor add a row? No. Add a column? No. Delete a row or a
column?
No. Are all of those operations part of the bare minimum feature set for
table editing? Absolutely.

No, I don't agree -- it's actually totally fine to say for now if you
want to add rows etc., use the source editor. And as you know, once
you start going into complex table manipulations, the product becomes
a _lot_ more complex, because you need to be able to do so in a way
that matches existing expectations of how a table should be
structured, which vary by page (some augmented by templates, some
using various inline CSS approaches, etc.). However, I do agree that
we should do a better job communicating VE's limitations (they are
listed pretty clearly in a bunch of places, but obviously you're not
going to look if you're a new editor).

This is why I think the approach of adding VE as a second tab with a
clear beta label and an explanation when you open it is a reasonable
way forward.

It's not dirty diffs: the articles get converted to gibberish on saves:

http://en.wikipedia.org/w/index.php?title=List_of_Big_Time_Rush_episodesdiff=565906957oldid=565898974

Wholesale destruction of articles is *not* a dirty diff.

The use of dirty diff was not intended to minimize that - we've seen
destructive changes with VE, and we take them very seriously. Like I
said, cleanly roundtripping has always been a top priority. The way
we've prioritized them is by handcoding actual diffs we see in the
real world and fixing things that occur frequently first. I also like
the approach of shielding page content if needed. I just don't agree
that providing a clean experience for _editing_ that type of
masterfully template-constructed table is a fair expectation for a
first release.

You're right that copy/paste is badly broken across tabs, and still
pretty broken even inside tabs, and we should have tried harder for
the first release. But if I have time later today, I'll make you a
video of how badly broken and slow copy/paste is in Google Docs across
tabs, which has been around for many years now and seen a huge amount
of world-wide usage -- not to even mention other less widely used
web-based RTEs. Again, I'm not minimizing it -- just saying that what
look like obvious easy issues often turns out to be a very complex
problem that you end up being better served iterating on in the real
world.

What I do agree with is that we need to now make a change to the user
experience to acknowledge the legitimate issues with the current
experience, dial back the firehose, and more prominently inform users
about VE's limitations.

Erik

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

___
Wikimedia-l mailing list
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] Let's have the courage to sit down and talk about VisualEditor

2013-08-01 Thread Steven Walling

On Wed, Jul 31, 2013 at 10:24 PM, Kevin Wayne Williams 
kwwilli...@kwwilliams.com wrote:

 If you had followed that, and understood that the Minimum Viable Product
 included cut-and-paste, table editing, and maybe the ability to
 successfully and completely edit the hundred or so most edited articles out
 of all the millions, you wouldn't have hit the level of pushback you've
 encountered. You released a sub-viable product, which is what caused the
 storm you encountered.


Minimum viable product does not mean anything and everything works
perfectly just like you want right out of the box, and it definitely does
not mean feature parity with an existing product (i.e. wikitext editing).
The purpose is to release something that can help us gather feedback and
test the concept behind the product in the real world instead of in a
lab.[1] Table editing and other advanced markup is not really necessary to
test the concept with the target audience, and decide whether to move
forward.

We all know VE didn't and doesn't edit everything in a way that's perfectly
up to snuff. No one has been claiming it doesn't have warts. What the team
is pushing back against is the idea that they can just turn it off and
develop a great new editor in a vacuum, away from real use by a
representative swath of current editors (registered and anonymous, new and
old). The lack of use by a sufficiently large and representative group of
editors is a big part of why the _seven months_ of original opt-in use
didn't fix most issues.

Erik and James have clearly admitted we can achieve our goals while moving
at a slower pace than the initial rollout and making other concessions.
Despite this, the attitude of some seems to be that they should be
committing seppuku for daring to release something not 100% perfect
according to [insert personal criteria for editing perfection here]. That's
not the kind of reaction that drew me to Wikipedia back in 2006, not by a
long shot. Rather, most of us find Wikipedia so rewarding because there is
room to be bold in the name of helping the encyclopedia. Which is precisely
what the VE team has been attempting to do.

Do I really really wish editing references and tables and templates was
easier when I'm writing articles in my off hours? Holy smokes yes. Is it
helping us get there to be making bitter comments about how Erik or anybody
else at WMF doesn't care about editors? No.

Steven

1. https://en.wikipedia.org/wiki/Minimum_viable_product
2. https://www.youtube.com/watch?v=qVR82uP_f6Q
___
Wikimedia-l mailing list
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] Let's have the courage to sit down and talk about VisualEditor

2013-08-01 Thread Erik Moeller

Hey Kevin,

contrary to your belief (and in spite of your desire to blame me ;-),
I actually have a ton of respect for the opinions you've expressed
throughout the process, and for the level of detail and time you've
committed to it, including helping in a hands-on manner. I don't agree
with you on quite a few issues, obviously, but I've really enjoyed
reading your comments, which are always well-reasoned and on point.
:-) I hope you don't lose your patience with us, as you really are the
kind of person we enjoy working with due to your diligence and the
quality of your reports.

So, if you've personally felt that it's been disruptive for you and
caused you annoyance and frustration, I'm sorry, because I do respect
your opinion and your work as an editor.

On the subject of an appropriate MVP:

 If you had followed that, and understood that the Minimum Viable Product
 included cut-and-paste, table editing, and maybe the ability to successfully
 and completely edit the hundred or so most edited articles out of all the
 millions, you wouldn't have hit the level of pushback you've encountered.

Couple of diffs from a few minutes ago of table edits:
https://en.wikipedia.org/w/index.php?title=Major_League_Soccercurid=71802diff=566676293oldid=59395
https://en.wikipedia.org/w/index.php?title=List_of_True_Blood_characterscurid=23290782diff=566675268oldid=565993704

That's not just plain vanilla tables, but tables with inline CSS
specified by hand, templates inside cells, etc. No roundtripping
issues or other problems as far as I can tell.

The kind of table you want us to make work well is this type:

onlyinclude{| class=wikitable style=margin: auto; width: 100%
|-
! colspan=2 rowspan=2 style=width:3%;|Season
! rowspan=2 style=width:5%;|Episodes
! colspan=2|Originally aired
! colspan=2|DVD release
|-
(...)
| style=background:green; color:#134; text-align:center;|
| style=text-align:center; colspan=2| '''[[List of Big Time Rush
episodes#Film|Film]]'''
| style=text-align:center; colspan=2| {{Start date|2012|3|10}}
| style=text-align: center; top {{N/a}}
| style=text-align: center; top {{N/a}}

which injects this kind of template:
https://en.wikipedia.org/w/index.php?title=Template:N/aaction=edit

In other words, a table partially constructed out of table cell templates.

Now, I understand that you've dealt with dirty diffs resulting from
people editing pages using those templates, and I know that sucks, so
sorry about that - but it's a hard problem, and I don't think it's
reasonable to frame it as an MVP-level one. The reasonable expectation
is to fix roundtripping issues on those hairy tables as soon as
possible, and ideally avoid any kind of accidental leakage of CSS into
the UI. But as you know, some of these templates don't even map
against HTML elements, so it's not a trivial issue.

We could spend literally months trying to make
tables-constructed-out-of-templates work nicely, and it would still be
a shitty experience, and those would be months not spent on actual MVP
features. Before we sink countless person hours into
tables-constructed-out-of-templates, I think we need to step back and
see what our options are for solving that particular problem well in
the long run. Perhaps there's a type of table-template we can support
well, and gradually migrate all tables to it, but it won't be easy.

I appreciate that you created the Disable VE template which makes it
possible to shield pages that are vulnerable to dirty diffs from VE.
That was a great hack (we should have included _that_ one with the
MVP, it would have saved users a lot of pain), and should help in
cases where an immediate fix isn't feasible.

As for copy-and-paste, yes, it's pretty wonky still, and I'm sure
causes a fair bit of frustration for first-time VE users who have no
experience with wikitext. However, it is there within a VE session,
and we see very few diffs where users are causing problems due to
broken copy-and-paste. Does that not match your experience? I've just
inspected another round of 100 diffs and didn't see a single
copy-and-paste related issue. Contrary to Andreas' claim, copying
references isn't completely broken, but the bug is pretty nasty when
it hits, so we'll get it fixed soon.

As for performance, it already was a high priority before release, and
we made huge gains in server-side performance thanks to the deployment
of a completely new caching infrastructure for VisualEditor and lots
of optimizations on Parsoid (still more to come). Where we could have
done better prior to release was client-side performance -- we didn't
do sufficient profiling there, and pushed it off to later; but we've
made pretty significant improvements in the last month already to the
point that even Adam Cuerden remarked on it. :-)

I don't agree that focusing more on the pain points you name would
have reduced the level of pushback significantly. You don't mention
nowiki issues, but guess what, across the communities, aside from
performance,

Re: [Wikimedia-l] Let's have the courage to sit down and talk about VisualEditor

2013-08-01 Thread Robert Rohde

If we are going to discuss Minimal Viable Product, then we might want
to take note of the line in the Wikipedia article that says:

The product is typically deployed to a subset of possible customers,
such as early adopters that are thought to be more forgiving, more
likely to give feedback, and able to grasp a product vision from an
early prototype or marketing information.

More than any specific deficiency in VE, I think the aggressive roll
out did the most to cause user dissatisfaction.  If you want to claim
that VE is a minimal product, then it stands to reason that it
wouldn't be ready for all users.  There are plenty of ways to stage a
deployment and gather feedback that are intermediate between the early
opt-in and turning it on for all users everywhere.  The WMF took
nearly the most aggressive deployment path possible while the quality
of the software really didn't warrant that.

-Robert Rohde

On Thu, Aug 1, 2013 at 12:00 AM, Erik Moeller e...@wikimedia.org wrote:
 Hey Kevin,

 contrary to your belief (and in spite of your desire to blame me ;-),
 I actually have a ton of respect for the opinions you've expressed
 throughout the process, and for the level of detail and time you've
 committed to it, including helping in a hands-on manner. I don't agree
 with you on quite a few issues, obviously, but I've really enjoyed
 reading your comments, which are always well-reasoned and on point.
 :-) I hope you don't lose your patience with us, as you really are the
 kind of person we enjoy working with due to your diligence and the
 quality of your reports.

 So, if you've personally felt that it's been disruptive for you and
 caused you annoyance and frustration, I'm sorry, because I do respect
 your opinion and your work as an editor.

 On the subject of an appropriate MVP:

 If you had followed that, and understood that the Minimum Viable Product
 included cut-and-paste, table editing, and maybe the ability to successfully
 and completely edit the hundred or so most edited articles out of all the
 millions, you wouldn't have hit the level of pushback you've encountered.

 Couple of diffs from a few minutes ago of table edits:
 https://en.wikipedia.org/w/index.php?title=Major_League_Soccercurid=71802diff=566676293oldid=59395
 https://en.wikipedia.org/w/index.php?title=List_of_True_Blood_characterscurid=23290782diff=566675268oldid=565993704

 That's not just plain vanilla tables, but tables with inline CSS
 specified by hand, templates inside cells, etc. No roundtripping
 issues or other problems as far as I can tell.

 The kind of table you want us to make work well is this type:

 onlyinclude{| class=wikitable style=margin: auto; width: 100%
 |-
 ! colspan=2 rowspan=2 style=width:3%;|Season
 ! rowspan=2 style=width:5%;|Episodes
 ! colspan=2|Originally aired
 ! colspan=2|DVD release
 |-
 (...)
 | style=background:green; color:#134; text-align:center;|
 | style=text-align:center; colspan=2| '''[[List of Big Time Rush
 episodes#Film|Film]]'''
 | style=text-align:center; colspan=2| {{Start date|2012|3|10}}
 | style=text-align: center; top {{N/a}}
 | style=text-align: center; top {{N/a}}

 which injects this kind of template:
 https://en.wikipedia.org/w/index.php?title=Template:N/aaction=edit

 In other words, a table partially constructed out of table cell templates.

 Now, I understand that you've dealt with dirty diffs resulting from
 people editing pages using those templates, and I know that sucks, so
 sorry about that - but it's a hard problem, and I don't think it's
 reasonable to frame it as an MVP-level one. The reasonable expectation
 is to fix roundtripping issues on those hairy tables as soon as
 possible, and ideally avoid any kind of accidental leakage of CSS into
 the UI. But as you know, some of these templates don't even map
 against HTML elements, so it's not a trivial issue.

 We could spend literally months trying to make
 tables-constructed-out-of-templates work nicely, and it would still be
 a shitty experience, and those would be months not spent on actual MVP
 features. Before we sink countless person hours into
 tables-constructed-out-of-templates, I think we need to step back and
 see what our options are for solving that particular problem well in
 the long run. Perhaps there's a type of table-template we can support
 well, and gradually migrate all tables to it, but it won't be easy.

 I appreciate that you created the Disable VE template which makes it
 possible to shield pages that are vulnerable to dirty diffs from VE.
 That was a great hack (we should have included _that_ one with the
 MVP, it would have saved users a lot of pain), and should help in
 cases where an immediate fix isn't feasible.

 As for copy-and-paste, yes, it's pretty wonky still, and I'm sure
 causes a fair bit of frustration for first-time VE users who have no
 experience with wikitext. However, it is there within a VE session,
 and we see very few diffs where users are causing problems due to

Re: [Wikimedia-l] Let's have the courage to sit down and talk about VisualEditor

2013-08-01 Thread Erik Moeller

On Thu, Aug 1, 2013 at 9:36 AM, Kevin Wayne Williams
kwwilli...@kwwilliams.com wrote:
The editor was able to change a 4 to a 5 in an existing table, that's true.
Could that editor add a row? No. Add a column? No. Delete a row or a column?
No. Are all of those operations part of the bare minimum feature set for
table editing? Absolutely.

This is why I think the approach of adding VE as a second tab with a
clear beta label and an explanation when you open it is a reasonable
way forward.

It's not dirty diffs: the articles get converted to gibberish on saves:
http://en.wikipedia.org/w/index.php?title=List_of_Big_Time_Rush_episodesdiff=565906957oldid=565898974

Wholesale destruction of articles is *not* a dirty diff.

Erik

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

___
Wikimedia-l mailing list
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] Let's have the courage to sit down and talk about VisualEditor

2013-07-31 Thread Lodewijk

Thanks Erik for the helpful attitude.

Out of curiosity (not sure if this was discussed in more detail before -
apologies for that), is it indeed true that Visual Editor is significantly
slower than the regular editor (it feels like that to me, but might be my
computer playing tricks on me), and is there any chance this will be
overcome soon? I'm asking because you state that you want VE to move
outside the small group of users - and making it faster might quite easily
make it more popular with the non-diehard-non-new users. Right now I often
simply use the regular editor for simple edits, because it is just quicker
(less clicks, but also faster loading).

Lodewijk


2013/7/31 rupert THURNER rupert.thur...@gmail.com

 Am 30.07.2013 20:14 schrieb David Gerard dger...@gmail.com:
 
  On 30 July 2013 17:03, Erik Moeller e...@wikimedia.org wrote:
 
  If the overwhelming community sentiment
   is that the cost of continuous improvement with a large scale user
   base is larger than the benefit (as it was on dewiki), we'll switch
   back (or to a compromise), and use a more rigid set of acceptance
   criteria and a less rigid deadline for getting back into large scale
   usage later in the year.
 
 
  de:wp convinced you. What would it take to convince you on en:wp? (I'm
  asking for a clear objective criterion here. If you can only offer a
  subjective one, please explain how de:wp convinced you when en:wp
  hasn't.)

 Hi David, i am editing on dewp and enwp. I consider myself an experienced
 editor, but not an expert. I did not participate voting in dewp, but i like
 to try ve from time to time. Beeing a software developper I fully support
 eriks arguments before. Imo pragmatic and flexible decisions help such
 development a lot, just like Erik explained.

 What i would have hoped though is that the wiki syntax gets changed where
 it is difficult to implement. And what i would have expected are more ideas
 to just edit parts of a page, like e.g. hotcat does it, to avoid such a
 mammoth dealing with everything which feels slow then.

 To give three examples:
 1. why not define a metadata section for every page, where categories, and
 access rights are stored? Then these parts already can be split out of the
 page ve.

 2. Why not having a read and edit mode? Edit mode just adds edit links to
 all applicable parts of a page.

 3. Why not decide references can only be after paragraphs, and edited via
 edit links showing up in Edit mode? so this part can be split out of page
 ve.

 Rupert
 ___
 Wikimedia-l mailing list
 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
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] Let's have the courage to sit down and talk about VisualEditor

2013-07-31 Thread David Gerard

On 31 July 2013 10:59, rupert THURNER rupert.thur...@gmail.com wrote:

 de:wp convinced you. What would it take to convince you on en:wp? (I'm
 asking for a clear objective criterion here. If you can only offer a
 subjective one, please explain how de:wp convinced you when en:wp
 hasn't.)

 Hi David, i am editing on dewp and enwp. I consider myself an experienced
 editor, but not an expert. I did not participate voting in dewp, but i like
 to try ve from time to time. Beeing a software developper I fully support
 eriks arguments before. Imo pragmatic and flexible decisions help such
 development a lot, just like Erik explained.


Certainly. However, it's the obvious question to ask, and a curious
question to spend several paragraphs not answering.

Erik, James - how did de:wp convinced you when en:wp hasn't?


- d.

___
Wikimedia-l mailing list
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] Let's have the courage to sit down and talk about VisualEditor

2013-07-31 Thread Federico Leva (Nemo)


Erik Moeller, 31/07/2013 07:28:

We can't just work through a
mountain of feedback in a waterfall development model and hope that
all our assumptions about how to fix this or that complex issue will
work out in practice.


+1
Also, such an important feature cannot be based on biased feedback from 
a subset of users and projects.


Erik Moeller, 30/07/2013 18:03:
 The steady stream of feedback has
 been invaluable, and I think the changelog of the last few weeks
 demonstrates that beyond all doubt.

I think it would be helpful, if possible, to give some guesstimates of 
this, i.e.: how longer a wait it would cost us to reach some rank of 
quality if the deployment was downscaled; or, what would be the 
deadline for feedback on aspects X and Y to be actually able to be 
processed and worked on, before previous development decisions become 
irreversible or the developers move on to something else.
	We have seen some other products stuck for a few weeks or months in 
semi-ready state, which have then been deployed and have experienced 
some problems that were not predicted; or other products which have been 
used only on en.wiki (with dozens of WMF staffers involved in processing 
the feedback from one single wiki) and which are later deployed to other 
wikis when the product is already in maintenance mode, so that those 
wikis will never have a chance to influence the development.
	If de.wiki users or other users discussing/voting on whether to delay 
wider VE deployment could do so knowing that delaying by x months will 
make us wait y months more to get use case w to work, or if we delay 
after day z, feedback from our community will not influence the 
deployment of w, the conclusions would be more meaningful. If one 
assumes that the cost of delaying is 0, as it's what we've been using 
for 12 years, of course the benefits will always seem to outweigh the 
downsides.


Nemo

___
Wikimedia-l mailing list
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] Let's have the courage to sit down and talk about VisualEditor

2013-07-31 Thread Marc A. Pelletier

On 07/31/2013 10:52 AM, Federico Leva (Nemo) wrote:
 I think it would be helpful, if possible, to give some guesstimates of
 this, i.e.: how longer a wait it would cost us to reach some rank of
 quality if the deployment was downscaled; or, what would be the
 deadline for feedback on aspects X and Y to be actually able to be
 processed and worked on, before previous development decisions become
 irreversible or the developers move on to something else.

Is it even possible to quantify this without just pulling numbers out of
one's ass?  It's not just a matter of 10 times the number of users
means 10 times the number of bugs found since the /profile/ of the
users changes drastically as well.

For instance, allowing the VE only for registered editors is guaranteed
to never reveal bugs/issues that only affects anonymous editing or
interaction between anons and registered editors.

Likewise, requiring opt-in or allowing opt-out changes the makeup of the
users a great deal (the former making certain that only editors with at
least some familiarity with how we work use it and thus preventing
usability issues for true newbies from being found, the latter by
allowing the more vocal and knowing segments of editors to hide the VE
and no longer see issues they alone are well-equipped to notice or
evaluate).

-- Marc


___
Wikimedia-l mailing list
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] Let's have the courage to sit down and talk about VisualEditor

2013-07-31 Thread Gerard Meijssen

Hoi,
Quality like beauty is in the eye of the beholder. One thing that I learned
today is that the Visual Editor will have functionality that only the more
accomplished editors will enter directly or they will use templates. With
VE these templates are redundant.

From my perspective, the future will be with the VE and not with the
horrible tortuous templates that require study to use. One of the reasons
why I prefer Wikidata over Wikipedia is that Wikidata does not have
templates and is certainly as relevant. When I notice the improvements in
the Wikidata experience, I can only applaud the improvements made.

What is truly beyond me is that people protest the availability of the VE
edit button. It is the choice of everybody to use VE or not. When they do
they will have a similar experience I have with Wikidata.. You can only
rejoice for the improvements that are made. Given that the improvements to
the VE are a top priority, this experience can only be that much more
enjoyable..

For all the oldies who complain about VE I want to remind them about the
Commons experience; Commons existed without any functionality. It took
months before we could use the images in any Wikipedia.

Really stop moaning and let that button be.
Thanks,
Gerard


On 31 July 2013 18:26, Marc A. Pelletier m...@uberbox.org wrote:

 On 07/31/2013 10:52 AM, Federico Leva (Nemo) wrote:
  I think it would be helpful, if possible, to give some guesstimates of
  this, i.e.: how longer a wait it would cost us to reach some rank of
  quality if the deployment was downscaled; or, what would be the
  deadline for feedback on aspects X and Y to be actually able to be
  processed and worked on, before previous development decisions become
  irreversible or the developers move on to something else.

 Is it even possible to quantify this without just pulling numbers out of
 one's ass?  It's not just a matter of 10 times the number of users
 means 10 times the number of bugs found since the /profile/ of the
 users changes drastically as well.

 For instance, allowing the VE only for registered editors is guaranteed
 to never reveal bugs/issues that only affects anonymous editing or
 interaction between anons and registered editors.

 Likewise, requiring opt-in or allowing opt-out changes the makeup of the
 users a great deal (the former making certain that only editors with at
 least some familiarity with how we work use it and thus preventing
 usability issues for true newbies from being found, the latter by
 allowing the more vocal and knowing segments of editors to hide the VE
 and no longer see issues they alone are well-equipped to notice or
 evaluate).

 -- Marc


 ___
 Wikimedia-l mailing list
 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
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] Let's have the courage to sit down and talk about VisualEditor

2013-07-31 Thread rupert THURNER

Am 31.07.2013 15:07 schrieb Risker risker...@gmail.com:

 On 31 July 2013 08:36, David Gerard dger...@gmail.com wrote:

  On 31 July 2013 10:59, rupert THURNER rupert.thur...@gmail.com wrote:
 
   de:wp convinced you. What would it take to convince you on en:wp?
(I'm
   asking for a clear objective criterion here. If you can only offer a
   subjective one, please explain how de:wp convinced you when en:wp
   hasn't.)
 
   Hi David, i am editing on dewp and enwp. I consider myself an
experienced
   editor, but not an expert. I did not participate voting in dewp, but i
  like
   to try ve from time to time. Beeing a software developper I fully
support
   eriks arguments before. Imo pragmatic and flexible decisions help such
   development a lot, just like Erik explained.
 
 
  Certainly. However, it's the obvious question to ask, and a curious
  question to spend several paragraphs not answering.
 
  Erik, James - how did de:wp convinced you when en:wp hasn't?
 
 
 
 I would also like to see a direct answer to David's very specific
 question.

From a software developers standpoint its nice to have the 2 biggest wikis
following a different strategy. Enwp is enough to get a lot of testers. But
some accommodation of the users comes with it. Switching over wpde later
gets again not accommodated and more critical feedback.
___
Wikimedia-l mailing list
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] Let's have the courage to sit down and talk about VisualEditor

2013-07-31 Thread Risker

On 31 July 2013 13:32, rupert THURNER rupert.thur...@gmail.com wrote:

 Am 31.07.2013 15:07 schrieb Risker risker...@gmail.com:
 
  On 31 July 2013 08:36, David Gerard dger...@gmail.com wrote:
 
   On 31 July 2013 10:59, rupert THURNER rupert.thur...@gmail.com
 wrote:
  
de:wp convinced you. What would it take to convince you on en:wp?
 (I'm
asking for a clear objective criterion here. If you can only offer a
subjective one, please explain how de:wp convinced you when en:wp
hasn't.)
  
Hi David, i am editing on dewp and enwp. I consider myself an
 experienced
editor, but not an expert. I did not participate voting in dewp, but
 i
   like
to try ve from time to time. Beeing a software developper I fully
 support
eriks arguments before. Imo pragmatic and flexible decisions help
 such
development a lot, just like Erik explained.
  
  
   Certainly. However, it's the obvious question to ask, and a curious
   question to spend several paragraphs not answering.
  
   Erik, James - how did de:wp convinced you when en:wp hasn't?
  
  
  
  I would also like to see a direct answer to David's very specific
  question.
 
 From a software developers standpoint its nice to have the 2 biggest wikis
 following a different strategy. Enwp is enough to get a lot of testers. But
 some accommodation of the users comes with it. Switching over wpde later
 gets again not accommodated and more critical feedback.


Without rejecting your position, what we really want to hear is Erik
Moeller's reasoning, in his role as VP Engineering.  It was Erik's
decision, and we want him to explain his reasoning in his own words.

Risker
___
Wikimedia-l mailing list
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] Let's have the courage to sit down and talk about VisualEditor

2013-07-31 Thread Brad Jorsch (Anomie)

On Wed, Jul 31, 2013 at 12:47 PM, Gerard Meijssen
gerard.meijs...@gmail.com wrote:
 Quality like beauty is in the eye of the beholder. One thing that I learned
 today is that the Visual Editor will have functionality that only the more
 accomplished editors will enter directly or they will use templates. With
 VE these templates are redundant.

Some, perhaps. But would you rather use a template or remember the
multiple buttons in VE and the right CSS style/class string (if that's
even possible in VE?) to do the same thing manually?

 From my perspective, the future will be with the VE and not with the
 horrible tortuous templates that require study to use. One of the reasons
 why I prefer Wikidata over Wikipedia is that Wikidata does not have
 templates and is certainly as relevant. When I notice the improvements in
 the Wikidata experience, I can only applaud the improvements made.

Wikidata also deals with discrete bits of usually-unformatted data,
rather than heavily-formatted encyclopedia articles. I'm not sure
you're comparing apples to apples there.

___
Wikimedia-l mailing list
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] Let's have the courage to sit down and talk about VisualEditor

2013-07-31 Thread Amir E. Aharoni

2013/7/31 Brad Jorsch (Anomie) bjor...@wikimedia.org:
 On Wed, Jul 31, 2013 at 12:47 PM, Gerard Meijssen
 gerard.meijs...@gmail.com wrote:
 Quality like beauty is in the eye of the beholder. One thing that I learned
 today is that the Visual Editor will have functionality that only the more
 accomplished editors will enter directly or they will use templates. With
 VE these templates are redundant.

 Some, perhaps. But would you rather use a template or remember the
 multiple buttons in VE and the right CSS style/class string (if that's
 even possible in VE?) to do the same thing manually?

God no. The whole idea of VE is to make people NOT have to remember
CSS class names.

If a template is a very common in a project, it should be a button
with complete GUI in the VE's toolbar in that project. If a template
is very common in many projects, it should be a button with complete
GUI in all projects.

--
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
http://aharoni.wordpress.com
‪“We're living in pieces,
I want to live in peace.” – T. Moore‬

___
Wikimedia-l mailing list
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] Let's have the courage to sit down and talk about VisualEditor

2013-07-31 Thread Erik Moeller

On Wed, Jul 31, 2013 at 5:36 AM, David Gerard dger...@gmail.com wrote:
 Certainly. However, it's the obvious question to ask, and a curious
 question to spend several paragraphs not answering.

 Erik, James - how did de:wp convinced you when en:wp hasn't?

Hi David,

I don't really agree with your framing - it's not about who's
convincing who, but being on a sustainable path to making VisualEditor
continually better, with an appropriately diverse and large base of
users. That's a balancing act with any community. In the case of
dewiki, it became clear pretty quickly that any additional benefit of
continued feedback would be outweighed by strife and upset about the
change to the default experience. In enwiki and other deployments, in
spite of upset, we've received a ton of useful and actionable feedback
through all of July that's enabled us to continually improve, but
given the enwiki RFC on default state, it's clear that the full-on
change of the default experience isn't yet sustainable in the long run
as a way to run the beta. So we're looking at alternatives, as per my
prior note, rather than waiting for the RFC to come to a close. Once
again, the only way to continually improve VisualEditor is to ensure
that we have a large base of continued use from a diverse group of
users, minimizing self-selection bias, but we'll explore different
ways to get there.

I don't believe in hard and fast rules - in managing big and complex
changes, we need to be patient with each other. On your end, we ask
for forgiveness because we're going to sometimes do things that get in
your way, confuse and annoy you in the process of finding ways to
improve the user experience. On our end, we need to show flexibility
and willingness to find a workable solution for the main problem:
ensuring we're making development decisions in a real world context,
not in a laboratory.

All best,
Erik

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

___
Wikimedia-l mailing list
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] Let's have the courage to sit down and talk about VisualEditor

2013-07-31 Thread David Gerard

On 31 July 2013 19:27, Erik Moeller e...@wikimedia.org wrote:
 On Wed, Jul 31, 2013 at 5:36 AM, David Gerard dger...@gmail.com wrote:

 Erik, James - how did de:wp convinced you when en:wp hasn't?

 I don't really agree with your framing - it's not about who's
 convincing who, but being on a sustainable path to making VisualEditor
 continually better, with an appropriately diverse and large base of


This comes across to me as a full and reasonable answer. Thanks :-)


- d.

___
Wikimedia-l mailing list
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] Let's have the courage to sit down and talk about VisualEditor

2013-07-31 Thread Andreas Kolbe

On Wed, Jul 31, 2013 at 7:28 PM, David Gerard dger...@gmail.com wrote:

On 31 July 2013 19:27, Erik Moeller e...@wikimedia.org wrote:
On Wed, Jul 31, 2013 at 5:36 AM, David Gerard dger...@gmail.com wrote:

Erik, James - how did de:wp convinced you when en:wp hasn't?

I don't really agree with your framing - it's not about who's
convincing who, but being on a sustainable path to making VisualEditor
continually better, with an appropriately diverse and large base of

This comes across to me as a full and reasonable answer. Thanks :-)

- d.

Commiserations. If would hazard a guess that 450+ clear and indignant votes
against the VisualEditor on the German Wikipedia, collected within the
space of a weekend, spoke much louder than a trickle of moans by a few
dozen people on the English Wikipedia, where almost everybody was at first
inclined to be polite and assume good faith. Most people did not want to
rain on the Foundation's parade.

I mean, look at how Jimbo sold the VisualEditor to the press at the start
of the roll-out:

http://www.telegraph.co.uk/technology/wikipedia/10196578/Wikipedia-introduces-new-features-to-entice-editors.html

---o0o---

“VisualEditor is a user interface that is much more familiar to people.
When you click edit you get something that looks very much like any word
processor, and you can change things and do whatever you want.”

---o0o---

Whatever you want indeed. Except add a citation:

http://www.dnaindia.com/blogs/1863070/post-wikipedia-editing-session-for-journalism-students-at-sophia-polytechnic

---o0o---

After spending a bit of time dealing with connectivity issues and *finding
out that the Visual Editor doesn’t function on mobile devices and Internet
Explorer*, everyone started rolling on the demo-cum-live editing session.
The volunteers had chosen two biography articles for creation on the
English language Wikipedia, based on a list of possible subjects provided
by the department. Rohini did a step-by-step demo of how to create a page,
how to ensure there are enough third-party references available etc, and
created a biographical stub on Dina Vakil. The exact same exercise was
given to the students, who followed the same process in their groups, and
created a stub article on Ritu Menon. *All the groups got stuck at using
the reference/ citations templates on the Visual Editor, so we switched
back to wiki syntax.*

---o0o---

In part, the German Wikipedia had the advantage of seeing the problems
accumulate on the English Wikipedia before it was their turn to
experience the same horrors. They had a chance to see the reality as
opposed to the PR spin, and to see how big the gap was between what was
promised and what was delivered. Seeing the mountain of unfixed bugs
assembled as a result of the English Wikipedia's feedback, they wisely said
nein, danke.

I also don't understand why the Foundation would need any more feedback at
this point in time. Developers haven't even fixed bugs that have been known
for months. It seems just catching up with Bugzilla would be enough to keep
them busy for a while.

For example, I just learnt that it was reported almost two months ago that
you cannot take a reference into the clipboard. If you try, you either
can't do it at all, or you actually end up accidentally deleting the
reference content, leaving Wikipedia with just the plain-character string
[1]. This is a problem that can do pretty nasty damage to an article,
besides angering editors, or making newbies feel incompetent if the next
person shouts at them because they deleted a perfectly good reference.

That bug was first reported on 13 June.

https://bugzilla.wikimedia.org/show_bug.cgi?id=49396

It was reported again on 2 July.

https://bugzilla.wikimedia.org/show_bug.cgi?id=50594

It was reported again on 29 July (by me).

https://bugzilla.wikimedia.org/show_bug.cgi?id=52212

It still hasn't been fixed. I fail to see the point in having the same
error reported time and again, and having developers spend their time
marking reports Resolved because they are duplicates of earlier reports
of the same, still unsolved issue, rather than spending their time actually
fixing the bug.

Andreas
___
Wikimedia-l mailing list
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] Let's have the courage to sit down and talk about VisualEditor

2013-07-31 Thread Erik Moeller

On Wed, Jul 31, 2013 at 1:41 PM, Andreas Kolbe jayen...@gmail.com wrote:

I mean, look at how Jimbo sold the VisualEditor to the press at the start
of the roll-out:

http://www.telegraph.co.uk/technology/wikipedia/10196578/Wikipedia-introduces-new-features-to-entice-editors.html

---o0o---

Except that of course the narrative you're trying to establish here is
completely wrong. Wikimedia Foundation did not launch VisualEditor
with great fanfare, promising a panacea of perfect and beautiful
software. We announced it through a single blog post, inviting
feedback and support with the rollout. We launched a community portal
which had the following statements on it from day one:

---o0o--- (I like your quotation markup, let's add it to wikitext .. j/k)
At the moment, the VisualEditor has a number of bugs; this is
inevitable. The only way to only deploy software when it is bug-free
is not to deploy it at all - we're still finding errors in MediaWiki,
and that's 10 years old. If you encounter an issue, please do not
hesitate to report it on the Feedback page. There are also some areas
where we still have to build entirely new features. Current
limitations include:

* Odd-looking — We currently struggle with making the HTML we produce
look like what you are used to seeing, so styling and so on may look a
little (or even very) odd. We're increasing the time we put into this,
but so far our focus has been on making sure that the VisualEditor
does not alter wikitext unexpectedly.
* Incomplete editing — Some elements of complex formatting will
display and let you edit their contents, but not let users edit their
structure or add new entries – such as tables or definition lists.
Adding features in this area is one of our priorities.
* Limited browser support — Right now, we have only got VisualEditor
to work in the most modern versions of Firefox, Chrome and Safari. It
does not work in very old versions of each browser, and does not work
in Opera, although a volunteer is working on Opera support. Internet
Explorer currently does not work, but we aim to have support for the
latest versions of IE by the time we release the VisualEditor more
widely.
* Articles and User pages only — The VisualEditor will only be enabled
for the article and user namespaces (so you can make changes in a
personal sandbox). In time, we will build out the kinds of specialised
editing tools needed for non-articles, but our focus has been on
articles.

Because of these limitations, and inevitable bugs, we recommend that
users click review your changes before saving the page, and report
any problems they encounter.
---o0o---

This list has been community-updated since then and is a transparent
and honest reflection of the known areas of improvement.

In terms of media, when we've received inquiries, our response has
generally been We're still in beta, talk to us in a few months. The
article you're quoting from is a single story that's about new
features that WMF is launching, of which VisualEditor is one; it also
discusses Echo and Flow. It also includes the following quote from
Jimmy about the VisualEditor.

---o0o---
“This is version 1.0, which means it is the first one that has really
had mass adoption and mass use,” said Wales. “We've had a lot of
feedback and there's going to be a lot of upgrades and changes, and
we're investing a lot in that kind of thing.”
---o0o---

The VisualEditor itself has a Beta button which, when clicked, shows
the following text:

---o0o---
VisualEditor is in 'beta'. You may encounter software issues, and you
may not be able to edit parts of the page.
---o0o---

Is the Beta notice too small and obscure? Fair criticism. But if you
want to claim that we're somehow misleading users about the state of
VisualEditor, you'll have to do a lot better.

I also don't understand why the Foundation would need any more feedback at
this point in time.

James has written a very good and detailed response to this here.
Please read it:
https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:VisualEditor/Default_State_RFColdid=56714#Suggested_changes

In a nutshell, it's not about volume of feedback, but about iterating
with a representative real world set of users, rather than in
isolation. In terms of volume, right now we're dealing with a
firehose, which is more than we strictly need, but has the huge
advantage of being an unbiased sample of users. We understand it's
very disruptive, which is why we've been responsive to RFCs and
community consensus asking us to slow down. But we can't do it with a
trickle of self-selected users. We need a steady stream of real user
interactions and user feedback from different groups (IPs, new users,
experienced users) in order to iterate effectively. That's not trivial
to

Re: [Wikimedia-l] Let's have the courage to sit down and talk about VisualEditor

2013-07-31 Thread Kevin Wayne Williams


Op 2013/07/31 21:58, Erik Moeller schreef:

There's a reason every start-up on the planet follows the idea of the
Minimum Viable Product like a religion.
If you had followed that, and understood that the Minimum Viable Product 
included cut-and-paste, table editing, and maybe the ability to 
successfully and completely edit the hundred or so most edited articles 
out of all the millions, you wouldn't have hit the level of pushback 
you've encountered. You released a sub-viable product, which is what 
caused the storm you encountered.

  I personally will never judge a team too
harshly for releasing too early, because the normal bias is the
opposite, and it's counterproductive.
I'll be content with just blaming you, then. You value your team's 
productivity over everyone else's. I don't know why you expected 
everyone that has worked on Wikipedia for years to cheerfully clean up 
after you when you make it abundantly clear that you hold everything we 
have worked on in disdain.


KWW

___
Wikimedia-l mailing list
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] Let's have the courage to sit down and talk about VisualEditor

2013-07-30 Thread Erik Moeller

Hey Tomasz,

this is a good way to start a new thread here, so let me respond.

We've done the following with regard to the VE beta so far:
- We've overall slowed down the beta rollout schedule;
- We've excluded nlwiki from the phase 2 beta rollout;
- We've switched dewiki back to opt-in;
- We've offered an easy way to hide VisualEditor (it was always
possible not to use it).

We've also pushed out lots of fixes  improvements, including a first
round of performance improvements, a better (still not awesome)
citations dialog, improvements to the template dialog, etc.

If we have to globally go back to opt-in for a while, or some
middle-ground (instant opt-out, or advertised beta) we'll do that too.
We'd prefer not to, because having developers quickly see the impact
of their changes at scale, positive and negative, is essential to
making the product better quickly. The steady stream of feedback has
been invaluable, and I think the changelog of the last few weeks
demonstrates that beyond all doubt.

We see very few roundtripping errors. We do see incidents of
problematic edits that are unique to a visual editing environment
(e.g. backspace-deleting an infobox vs. having to select  delete all
the markup representing it; reduced precision in applying formatting
to content due to mouse selection). Some of those we can help reduce,
some of them are inherent and we'll likely have to accept as a cost of
introducing a new editor. And we do see the much-discussed issues with
complex templates where the question isn't really who is at fault
but what the right long term solution is.

There are quite a few ugly bugs (it's a beta), but most of those
aren't that hard to squash. It'll take longer to make really big gains
in performance, though -- that's a genuinely hard problem.

We don't think going back into opt-in mode is in the interests of
advancing Wikimedia's mission -- maintaining VE as the edit button
while making it trivial to edit source forces us to really stay at a
high pace of continuous improvement that meets user needs. Nothing
constrains choice and imposes urgency like reality.

Our preference is therefore to work with the community to stay in
continuous improvement mode. If the overwhelming community sentiment
is that the cost of continuous improvement with a large scale user
base is larger than the benefit (as it was on dewiki), we'll switch
back (or to a compromise), and use a more rigid set of acceptance
criteria and a less rigid deadline for getting back into large scale
usage later in the year.

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

___
Wikimedia-l mailing list
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] Let's have the courage to sit down and talk about VisualEditor

2013-07-30 Thread David Gerard

On 30 July 2013 17:03, Erik Moeller e...@wikimedia.org wrote:

If the overwhelming community sentiment
 is that the cost of continuous improvement with a large scale user
 base is larger than the benefit (as it was on dewiki), we'll switch
 back (or to a compromise), and use a more rigid set of acceptance
 criteria and a less rigid deadline for getting back into large scale
 usage later in the year.


de:wp convinced you. What would it take to convince you on en:wp? (I'm
asking for a clear objective criterion here. If you can only offer a
subjective one, please explain how de:wp convinced you when en:wp
hasn't.)


- d.

___
Wikimedia-l mailing list
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] Let's have the courage to sit down and talk about VisualEditor

2013-07-30 Thread Risker

On 30 July 2013 14:13, David Gerard dger...@gmail.com wrote:

 On 30 July 2013 17:03, Erik Moeller e...@wikimedia.org wrote:

 If the overwhelming community sentiment
  is that the cost of continuous improvement with a large scale user
  base is larger than the benefit (as it was on dewiki), we'll switch
  back (or to a compromise), and use a more rigid set of acceptance
  criteria and a less rigid deadline for getting back into large scale
  usage later in the year.


 de:wp convinced you. What would it take to convince you on en:wp? (I'm
 asking for a clear objective criterion here. If you can only offer a
 subjective one, please explain how de:wp convinced you when en:wp
 hasn't.)



Just noting in passing:
https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Default_State_RFC

Risker
___
Wikimedia-l mailing list
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] Let's have the courage to sit down and talk about VisualEditor

2013-07-30 Thread Steven Walling

On Tue, Jul 30, 2013 at 11:13 AM, David Gerard dger...@gmail.com wrote:

 de:wp convinced you. What would it take to convince you on en:wp? (I'm
 asking for a clear objective criterion here. If you can only offer a
 subjective one, please explain how de:wp convinced you when en:wp
 hasn't.)


[Speaking personally, not for the VE team in any way.]

Why should a consensus of any arbitrary number of power editors be allowed
to define the defaults for all editors, including anonymous and
newly-registered people? Anonymous edits make up about 1/3 of enwiki edits,
IIRC. Every day, 3,000-5,000 new accounts are registered on English
Wikipedia. These people are not even being asked to participate in these
RFCs. Even if they were, they typically don't know how to participate and
find it very intimidating.

This system of gauging the success of VE is heavily biased toward the
concerns of people most likely to dislike change in the software and
frankly, to not really need VE in its current state. That doesn't mean
they're wrong, just that they don't speak for everyone's perspective. The
sad fact is that the people who stand to benefit the most from continued
use and improvements to VE can't participate in an RFC about it, in part
because of wikitext's complexities and annoyances. It is a huge failure of
the consensus process and the Wikimedia movement if we pretend that it's
truly open, fair, and inclusive to make a decision about VE this way.

In WMF design and development, we work our butts off trying to do research,
design, and data analysis that guides us toward building for _all_ the
stakeholders in a feature. We're not perfect at it by a long shot, but I
don't see a good faith effort by English and German Wikipedians running
these RFCs to solicit and consider the opinions of the huge number of
new/anonymous editors. And why should they? That's not their job, they just
want to express their frustration and be listened to.

To answer David's question: I think we need a benchmark for making VE
opt-in again that legitimately represents the needs of _all the people_ who
stand to benefit from continuing the rapid pace of bug fixing and feature
additions. I don't think an on-wiki RFC is it.

Steven
___
Wikimedia-l mailing list
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] Let's have the courage to sit down and talk about VisualEditor

2013-07-30 Thread Fred Bauder

 On Tue, Jul 30, 2013 at 11:13 AM, David Gerard dger...@gmail.com wrote:

 de:wp convinced you. What would it take to convince you on en:wp? (I'm
 asking for a clear objective criterion here. If you can only offer a
 subjective one, please explain how de:wp convinced you when en:wp
 hasn't.)


 [Speaking personally, not for the VE team in any way.]

 Why should a consensus of any arbitrary number of power editors be
 allowed
 to define the defaults for all editors, including anonymous and
 newly-registered people? Anonymous edits make up about 1/3 of enwiki
 edits,
 IIRC. Every day, 3,000-5,000 new accounts are registered on English
 Wikipedia. These people are not even being asked to participate in these
 RFCs. Even if they were, they typically don't know how to participate and
 find it very intimidating.

 This system of gauging the success of VE is heavily biased toward the
 concerns of people most likely to dislike change in the software and
 frankly, to not really need VE in its current state. That doesn't mean
 they're wrong, just that they don't speak for everyone's perspective. The
 sad fact is that the people who stand to benefit the most from continued
 use and improvements to VE can't participate in an RFC about it, in part
 because of wikitext's complexities and annoyances. It is a huge failure
 of
 the consensus process and the Wikimedia movement if we pretend that it's
 truly open, fair, and inclusive to make a decision about VE this way.

 In WMF design and development, we work our butts off trying to do
 research,
 design, and data analysis that guides us toward building for _all_ the
 stakeholders in a feature. We're not perfect at it by a long shot, but I
 don't see a good faith effort by English and German Wikipedians running
 these RFCs to solicit and consider the opinions of the huge number of
 new/anonymous editors. And why should they? That's not their job, they
 just
 want to express their frustration and be listened to.

 To answer David's question: I think we need a benchmark for making VE
 opt-in again that legitimately represents the needs of _all the people_
 who
 stand to benefit from continuing the rapid pace of bug fixing and feature
 additions. I don't think an on-wiki RFC is it.

 Steven

Let me confess, I hate all new things. I hate the constantly changing
complicated wiki markup and I hate the new editor, cause I don't know how
to work it even if it would be simpler if I were starting from scratch.
The point was to design an editor that would be better for casual and new
editors; I have nothing whatever to add from my own experience because I
can't duplicate from my experience that of a casual or new editor.

Fred


___
Wikimedia-l mailing list
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] Let's have the courage to sit down and talk about VisualEditor

2013-07-30 Thread David Gerard

On 30 July 2013 21:47, Steven Walling steven.wall...@gmail.com wrote:

 Why should a consensus of any arbitrary number of power editors be allowed
 to define the defaults for all editors, including anonymous and


OK - so why were those people listened to on de:wp? What happened
there that they convinced you?


- d.

___
Wikimedia-l mailing list
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] Let's have the courage to sit down and talk about VisualEditor

2013-07-30 Thread Ziko van Dijk

Dear Steven, I think I understand what you mean, and I am concerned about a
certain conservatism among the editors, too. Some editors complain all the
time anyway. But when 87% reject such a software feature I suppose they
cannot be all wrong (by the way, I am one of this huge majority). There are
two groups among the rejectors: Those who object a VE in general, and
those who are eager to have one but have experienced major problems using
it (I am one of them).
One of my compatriots has expressed it as I feel it: we often see beta
phase software, and sometimes after the beta phase there has never been a
final version. But those beta versions usually work well. This is
different to the VE version we have experienced.
I do appreciate Erik's explanations from above, see that the Foundation
does notice what happens, and I agree that the existing community should
not have an absolute veto power with regard to the potential community of
the future. I do have the impression that people were used as guinea pigs
who did not ask for being that. :-)
Kind regards
Ziko









Ziko van Dijk
voorzitter / president Wikimedia Nederland
deputy chair Wikimedia Chapters Association Council

Vereniging Wikimedia Nederland
Postbus 167
3500 AD Utrecht
http://wikimedia.nl



2013/7/30 Steven Walling steven.wall...@gmail.com

 On Tue, Jul 30, 2013 at 11:13 AM, David Gerard dger...@gmail.com wrote:

  de:wp convinced you. What would it take to convince you on en:wp? (I'm
  asking for a clear objective criterion here. If you can only offer a
  subjective one, please explain how de:wp convinced you when en:wp
  hasn't.)
 

 [Speaking personally, not for the VE team in any way.]

 Why should a consensus of any arbitrary number of power editors be allowed
 to define the defaults for all editors, including anonymous and
 newly-registered people? Anonymous edits make up about 1/3 of enwiki edits,
 IIRC. Every day, 3,000-5,000 new accounts are registered on English
 Wikipedia. These people are not even being asked to participate in these
 RFCs. Even if they were, they typically don't know how to participate and
 find it very intimidating.

 This system of gauging the success of VE is heavily biased toward the
 concerns of people most likely to dislike change in the software and
 frankly, to not really need VE in its current state. That doesn't mean
 they're wrong, just that they don't speak for everyone's perspective. The
 sad fact is that the people who stand to benefit the most from continued
 use and improvements to VE can't participate in an RFC about it, in part
 because of wikitext's complexities and annoyances. It is a huge failure of
 the consensus process and the Wikimedia movement if we pretend that it's
 truly open, fair, and inclusive to make a decision about VE this way.

 In WMF design and development, we work our butts off trying to do research,
 design, and data analysis that guides us toward building for _all_ the
 stakeholders in a feature. We're not perfect at it by a long shot, but I
 don't see a good faith effort by English and German Wikipedians running
 these RFCs to solicit and consider the opinions of the huge number of
 new/anonymous editors. And why should they? That's not their job, they just
 want to express their frustration and be listened to.

 To answer David's question: I think we need a benchmark for making VE
 opt-in again that legitimately represents the needs of _all the people_ who
 stand to benefit from continuing the rapid pace of bug fixing and feature
 additions. I don't think an on-wiki RFC is it.

 Steven
 ___
 Wikimedia-l mailing list
 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
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] Let's have the courage to sit down and talk about VisualEditor

2013-07-30 Thread David Gerard

On 30 July 2013 22:27, David Gerard dger...@gmail.com wrote:
 On 30 July 2013 21:47, Steven Walling steven.wall...@gmail.com wrote:

 Why should a consensus of any arbitrary number of power editors be allowed
 to define the defaults for all editors, including anonymous and

 OK - so why were those people listened to on de:wp? What happened
 there that they convinced you?


And I would remind you - I've been an ardent advocate of the absolute
necessity for a Visual Editor for Wikipedia for the past few years. My
qualms are not with change, but this particular instance and the
serious problems on many levels the project of its implementation has
manifested. It's possible the present project is recoverable into
something usable, but it's really not going to just happen.


- d.

___
Wikimedia-l mailing list
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] Let's have the courage to sit down and talk about VisualEditor

2013-07-30 Thread Steven Walling

On Tue, Jul 30, 2013 at 2:27 PM, David Gerard dger...@gmail.com wrote:

 OK - so why were those people listened to on de:wp? What happened
 there that they convinced you?


If you're replying to me... this is why I said I wasn't speaking for the VE
team. I didn't make that call. :)

Steven
___
Wikimedia-l mailing list
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] Let's have the courage to sit down and talk about VisualEditor

2013-07-30 Thread Robert Rohde

It is absolutely true that the power users can't directly speak for
the new users or anons.

That said, it would be unusual (though not impossible) if 85% of one
group held an opinion without a large fraction of other related
communities also sharing that view.  If the WMF or someone else wants
to commission a study of anon and new users opinions, that would
definitely be interesting to see.  Personally, I think VE is probably
still too immature to be spending a lot of money asking people about
it.  (In other words, many of the problems and missing features are
pretty obvious and we don't need to query large numbers of people to
hear about things we already know.)  Once it is a bit more stable and
the low hanging fruit have been addressed, it could be quite
instructive to get some user interaction studies on how people think
it could be made better.

We also might be able to get some useful data by further A/B testing.
For example, if VE is disabled, then assigning some anons to a VE
enabled group (perhaps by a cookie) could provide a valuable
comparison that we don't presently have.

For the moment, the thing we do have is edit counts over time (and
similar data).  Such data is certainly subject to various confounding
influences, but the data we do have for anons and new users isn't
exactly exciting.  New users are only choosing VE at the 30-40% level
for article edits, while anons are at the 20% use level.  Not exactly
a sign of wild enthusiasm for the new editing platform.  By itself,
these lowish use numbers are probably enough to conclude that neither
group is overwhelmingly excited by VE, though admittedly both numbers
are much higher than the 6% usage seen by established users.

The number I worry a bit more about is that total anon editing of
articles has fallen 9% in the two weeks since introduction (compared
to the prior two weeks).  During the same time period total editing of
articles by registered users rose 2%.  Again, correlation is not
causation, but if novice editors really liked VE then I would rather
have expected total anon editing to increase relative to established
users.  Even though anons and power user undoubtedly have different
needs.  I can't help worrying that the bugs, missing features, and
sluggish performance that power users complain about might also be
discouraging some of the anonymous and new users.  If the present
state of VE is actually discouraging new editors then that would be a
good sign that it isn't yet ready for wide deployment.

If I were designing a research program to study VE, I would certainly
make getting additional information on anon behaviors a high priority,
either by conducting new comparison trials or by finding better ways
to tease out patterns in editing trends.

-Robert Rohde





On Tue, Jul 30, 2013 at 1:47 PM, Steven Walling
steven.wall...@gmail.com wrote:
 On Tue, Jul 30, 2013 at 11:13 AM, David Gerard dger...@gmail.com wrote:

 de:wp convinced you. What would it take to convince you on en:wp? (I'm
 asking for a clear objective criterion here. If you can only offer a
 subjective one, please explain how de:wp convinced you when en:wp
 hasn't.)


 [Speaking personally, not for the VE team in any way.]

 Why should a consensus of any arbitrary number of power editors be allowed
 to define the defaults for all editors, including anonymous and
 newly-registered people? Anonymous edits make up about 1/3 of enwiki edits,
 IIRC. Every day, 3,000-5,000 new accounts are registered on English
 Wikipedia. These people are not even being asked to participate in these
 RFCs. Even if they were, they typically don't know how to participate and
 find it very intimidating.

 This system of gauging the success of VE is heavily biased toward the
 concerns of people most likely to dislike change in the software and
 frankly, to not really need VE in its current state. That doesn't mean
 they're wrong, just that they don't speak for everyone's perspective. The
 sad fact is that the people who stand to benefit the most from continued
 use and improvements to VE can't participate in an RFC about it, in part
 because of wikitext's complexities and annoyances. It is a huge failure of
 the consensus process and the Wikimedia movement if we pretend that it's
 truly open, fair, and inclusive to make a decision about VE this way.

 In WMF design and development, we work our butts off trying to do research,
 design, and data analysis that guides us toward building for _all_ the
 stakeholders in a feature. We're not perfect at it by a long shot, but I
 don't see a good faith effort by English and German Wikipedians running
 these RFCs to solicit and consider the opinions of the huge number of
 new/anonymous editors. And why should they? That's not their job, they just
 want to express their frustration and be listened to.

 To answer David's question: I think we need a benchmark for making VE
 opt-in again that legitimately represents the needs of _all the people_ who
 stand

Re: [Wikimedia-l] Let's have the courage to sit down and talk about VisualEditor

2013-07-30 Thread Erik Moeller

On Tue, Jul 30, 2013 at 11:13 AM, David Gerard dger...@gmail.com wrote:

 de:wp convinced you. What would it take to convince you on en:wp? (I'm
 asking for a clear objective criterion here. If you can only offer a
 subjective one, please explain how de:wp convinced you when en:wp
 hasn't.)

Hey David,

to me, this isn't about power dynamics (who decides, what is the
threshold, etc.) but about doing the right thing. It's pretty clear
where the en.wp RFC is going - a lot of users aren't comfortable
enough with the state of VE to give it the level of visibility it has.
Fair enough. I'm not going to dismiss that concern as conservatism
about change or any BS like that. There's plenty of that, and
there'll be more, but that's not the core issue right now.

Where we're coming from is simple. VE needed to get out of the
development model with a tiny group of users. It's been absolutely
critical to get the level of feedback we've been getting, and to have
thousands of users hit every edge case combination of
browser/OS/template complexity/editing operation. To get real world
reports on various aspects of the experience. To have people in India
or Argentina tell us We used VE in a workshop, and here are some of
the things that worked and didn't work.

And this is not a one-time thing. We can't just work through a
mountain of feedback in a waterfall development model and hope that
all our assumptions about how to fix this or that complex issue will
work out in practice. You can throw cheap user tests at every design,
but at the end of the day, you need to go into the real world. Doug
Engelbart put it well: The rate at which a person can mature is
directly proportional to the embarrassment he can tolerate.

This is why our preference is to keep fixing issues every day, as we
have been, addressing many of the highest priority real world issues,
including performance improvements, reducing nowiki escaping,
improving template/citation dialogs, etc. And every time we push out
one of those changes, we learn quickly whether it's working or not.

The opt-in alpha period wasn't sufficient to give us a large diversity
of users. The large-scale beta we're in right now, in spite of not
taking anything away from the ability to edit wikitext, is feeling too
disruptive for many at this time. What's a reasonable middle ground we
could shoot for?

In order to continually improve, we really need to build a large pool
of users that include IPs, new users, and experienced users. One
possibility is to aim for a prominent beta switch that's available to
all, similar to what we have on the mobile site. That would be an
opportunity to consolidate beta features, and to consistently treat
beta as opt-in as is being requested, while increasing the diversity
of the pool through increased prominence and recruiting. We'd have
some self-selection bias if we don't do better recruiting.

Another possibility would be to just maintain a separate, clearly
labeled tab for the VisualEditor that gives a prominent beta notice on
first-time invocation, with easy permanent dismissal.

We may also need to continue to run split A/B tests for different user
groups, in order to really get solid quantitative data on experience
differences.

Other thoughts  ideas? All of this is to say - to me this isn't a
game with a winner or a loser. We're working on this together to build
an awesome editing environment, not to score political points. So
let's iterate and find the best way forward together. :)

Cheers,
Erik

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

___
Wikimedia-l mailing list
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] Let's have the courage to sit down and talk about VisualEditor

2013-07-28 Thread Tomasz W. Kozlowski


Hi,
there is a famous quote on courage by Winston Churchill, a British Prime 
Minister, who once wisely said: Courage is what it takes to stand up 
and speak. Courage is also what it takes to sit down and listen.


Over the weekend, more than 440 editors of the German Wikipedia took 
part in an RfC-like process (Umfragen) at 
https://de.wikipedia.org/wiki/Wikipedia:Umfragen/VisualEditor_Opt-in 
and voted against the activation of the VisualEditor for anonymous 
users, asking the WMF to revert to an opt-in phase instead of the 
currently existing opt-out.


This is yet another signal coming from the community that there is 
something very broken about the process in which VisualEditor is being 
rolled out. Most of the criticism has been ignored so far, but on the 
other hand, we haven't yet seen such an enormous community objection 
against the VisualEditor anywhere.


Let us therefore use this opportunity, and have the courage to sit down 
and listen. Or, perhaps, in the wiki spirit, let's edit this quote, and 
let us sit down and talk.


And, together, let's learn a lesson from this, and correct the errors so 
that they don't become mistakes.


  Tomasz

___
Wikimedia-l mailing list
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] Let's have the courage to sit down and talk about VisualEditor

2013-07-28 Thread Bence Damokos

Can somebody summarize the concerns raised in that RfC?

Best regards,
Bence


On Mon, Jul 29, 2013 at 2:36 AM, Tomasz W. Kozlowski tom...@twkozlowski.net
 wrote:

 Hi,
 there is a famous quote on courage by Winston Churchill, a British Prime
 Minister, who once wisely said: Courage is what it takes to stand up and
 speak. Courage is also what it takes to sit down and listen.

 Over the weekend, more than 440 editors of the German Wikipedia took part
 in an RfC-like process (Umfragen) at https://de.wikipedia.org/**
 wiki/Wikipedia:Umfragen/**VisualEditor_Opt-inhttps://de.wikipedia.org/wiki/Wikipedia:Umfragen/VisualEditor_Opt-in
 and voted against the activation of the VisualEditor for anonymous users,
 asking the WMF to revert to an opt-in phase instead of the currently
 existing opt-out.

 This is yet another signal coming from the community that there is
 something very broken about the process in which VisualEditor is being
 rolled out. Most of the criticism has been ignored so far, but on the other
 hand, we haven't yet seen such an enormous community objection against the
 VisualEditor anywhere.

 Let us therefore use this opportunity, and have the courage to sit down
 and listen. Or, perhaps, in the wiki spirit, let's edit this quote, and let
 us sit down and talk.

 And, together, let's learn a lesson from this, and correct the errors so
 that they don't become mistakes.

   Tomasz

 __**_
 Wikimedia-l mailing list
 Wikimedia-l@lists.wikimedia.**org Wikimedia-l@lists.wikimedia.org
 Unsubscribe: 
 https://lists.wikimedia.org/**mailman/listinfo/wikimedia-lhttps://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
 mailto:wikimedia-l-request@**lists.wikimedia.orgwikimedia-l-requ...@lists.wikimedia.org
 ?subject=**unsubscribe
___
Wikimedia-l mailing list
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] Let's have the courage to sit down and talk about VisualEditor

2013-07-28 Thread Robert Rohde

I don't speak German, but with the aid of Google Translate, I think
one can get a decent gist of the results.

Firstly, let me note that this German Umfragen process is structured
largely as a vote. Some participants added short explanatory
statements, but it is not a discussion forum so one shouldn't expect
detailed explanations.

Participants were asked their opinion about how VE should be deployed
on dewiki. The vote is still ongoing, but so far the results are:

22 individuals (4.4%) feel that VE should be deployed for anonymous
users as scheduled.

7 users (1.4%) feel that VE should stay at its present status, i.e.
deployed for registered users but not anons.

442 users (87.7%) feel that the VE deployment should be rolled back so
that it is only available to users who explicitly opt-in at this time.

33 users (6.5%) chose a fourth opinion, the meaning of which is
somewhat unclear to me using Google Translate, but which appears to
express the opinion that VE should continue to be active in the
interface but that it should be assigned a new button and not take
over the edit functions.

Some of the people voting for the fourth option also supported one of
the other three options as an alternative / supplemental preference.

Rather than continuing with the deployment to anons (scheduled for
tomorrow), it appears that most of the contributors in this poll would
prefer that VE be rolled back and only delivered as an opt-in process
at this time.

Among the users choosing to offer an explanatory statement, the most
common opinions offered in support of rollback (in no particular
order) were perceptions that:

VE is too buggy / error-prone.
VE is missing too many essential features.
The current performance of VE is too slow.
Various complaints about UI (edit section animation, button labels, etc.)
Creates more work than benefits.
Poor experience will deter rather than encourage new editors.
Not intuitive.

The overarching theme of the comments is that VE was perceived as too
immature/incomplete to justify any form of wide-scale deployment at
this time. It should also be acknowledged that many participants
agreed with the idea of a visual editor, in principle, but felt that
the current implementation wasn't yet adequate.

-Robert Rohde

On Sun, Jul 28, 2013 at 5:43 PM, Bence Damokos bdamo...@gmail.com wrote:
Can somebody summarize the concerns raised in that RfC?

Best regards,
Bence

On Mon, Jul 29, 2013 at 2:36 AM, Tomasz W. Kozlowski tom...@twkozlowski.net
wrote:

Hi,
there is a famous quote on courage by Winston Churchill, a British Prime
Minister, who once wisely said: Courage is what it takes to stand up and
speak. Courage is also what it takes to sit down and listen.

Over the weekend, more than 440 editors of the German Wikipedia took part
in an RfC-like process (Umfragen) at https://de.wikipedia.org/**
wiki/Wikipedia:Umfragen/**VisualEditor_Opt-inhttps://de.wikipedia.org/wiki/Wikipedia:Umfragen/VisualEditor_Opt-in
and voted against the activation of the VisualEditor for anonymous users,
asking the WMF to revert to an opt-in phase instead of the currently
existing opt-out.

This is yet another signal coming from the community that there is
something very broken about the process in which VisualEditor is being
rolled out. Most of the criticism has been ignored so far, but on the other
hand, we haven't yet seen such an enormous community objection against the
VisualEditor anywhere.

Let us therefore use this opportunity, and have the courage to sit down
and listen. Or, perhaps, in the wiki spirit, let's edit this quote, and let
us sit down and talk.

And, together, let's learn a lesson from this, and correct the errors so
that they don't become mistakes.

Tomasz

__**_
Wikimedia-l mailing list
Wikimedia-l@lists.wikimedia.**org Wikimedia-l@lists.wikimedia.org
Unsubscribe:
https://lists.wikimedia.org/**mailman/listinfo/wikimedia-lhttps://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
mailto:wikimedia-l-request@**lists.wikimedia.orgwikimedia-l-requ...@lists.wikimedia.org
?subject=**unsubscribe
___
Wikimedia-l mailing list
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
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] Let's have the courage to sit down and talk about VisualEditor

Re: [Wikimedia-l] Let's have the courage to sit down and talk about VisualEditor

Re: [Wikimedia-l] Let's have the courage to sit down and talk about VisualEditor

Re: [Wikimedia-l] Let's have the courage to sit down and talk about VisualEditor

Re: [Wikimedia-l] Let's have the courage to sit down and talk about VisualEditor

Re: [Wikimedia-l] Let's have the courage to sit down and talk about VisualEditor

Re: [Wikimedia-l] Let's have the courage to sit down and talk about VisualEditor

Re: [Wikimedia-l] Let's have the courage to sit down and talk about VisualEditor

Re: [Wikimedia-l] Let's have the courage to sit down and talk about VisualEditor

Re: [Wikimedia-l] Let's have the courage to sit down and talk about VisualEditor

Re: [Wikimedia-l] Let's have the courage to sit down and talk about VisualEditor

Re: [Wikimedia-l] Let's have the courage to sit down and talk about VisualEditor

Re: [Wikimedia-l] Let's have the courage to sit down and talk about VisualEditor

Re: [Wikimedia-l] Let's have the courage to sit down and talk about VisualEditor

Re: [Wikimedia-l] Let's have the courage to sit down and talk about VisualEditor

Re: [Wikimedia-l] Let's have the courage to sit down and talk about VisualEditor

Re: [Wikimedia-l] Let's have the courage to sit down and talk about VisualEditor

Re: [Wikimedia-l] Let's have the courage to sit down and talk about VisualEditor

Re: [Wikimedia-l] Let's have the courage to sit down and talk about VisualEditor

Re: [Wikimedia-l] Let's have the courage to sit down and talk about VisualEditor

Re: [Wikimedia-l] Let's have the courage to sit down and talk about VisualEditor

Re: [Wikimedia-l] Let's have the courage to sit down and talk about VisualEditor

Re: [Wikimedia-l] Let's have the courage to sit down and talk about VisualEditor

Re: [Wikimedia-l] Let's have the courage to sit down and talk about VisualEditor

Re: [Wikimedia-l] Let's have the courage to sit down and talk about VisualEditor

Re: [Wikimedia-l] Let's have the courage to sit down and talk about VisualEditor

Re: [Wikimedia-l] Let's have the courage to sit down and talk about VisualEditor

Re: [Wikimedia-l] Let's have the courage to sit down and talk about VisualEditor

Re: [Wikimedia-l] Let's have the courage to sit down and talk about VisualEditor

Re: [Wikimedia-l] Let's have the courage to sit down and talk about VisualEditor

[Wikimedia-l] Let's have the courage to sit down and talk about VisualEditor

Re: [Wikimedia-l] Let's have the courage to sit down and talk about VisualEditor

Re: [Wikimedia-l] Let's have the courage to sit down and talk about VisualEditor

33 matches

Site Navigation

Mail list logo

Footer information