Re: [Wikimedia-l] Transition plans for WMF leadership

2016-02-22 Thread Ryan Lane
Pine W  writes:

> 
> I would hope that the Board is now planning an executive transition for
> WMF. I would like to ask the Board to be transparent about this, including
> making timely posts to this mailing list and proactively posting documents
> and timelines on Meta and Commons.
> 

+1. Numerous staff members have publicly asked the the ED to step down or be
removed. The situation at this point is obviously unsalvageable. Even if
things were to magically turn around tomorrow and start going in the right
direction, this series of threads would be the new seeds of discontent. Even
if everyone says they'll forgive and forget, no one really forgets who
called for them to be fired.

It shouldn't take a public staff revolt for an ED to be removed from the
board. It shouldn't have lasted past the internal staff revolt months ago.
The only way to start healing the org is to start moving forward.

- Ryan


___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 


Re: [Wikimedia-l] Collaboration team reprioritization

2015-09-09 Thread Ryan Lane
MZMcBride  mzmcbride.com> writes:

> 
> Forwarding this to wikimedia-l as it doesn't seem to be very technical in
> nature, but definitely seems worthy of discussion.
> 
> MZMcBride
> 
> Danny Horn wrote:
> >For a while now, the Collaboration team has been working on Flow, the
> >structured discussion system. I want to let you know about some changes in
> >that long-term plan.
> >
> >While initial announcements about Flow said that it would be a universal
> >replacement for talk pages, the features that were ultimately built into
> >Flow were specifically forum-style group discussion tools. But article and
> >project talk pages are used for a number of important and complex
> >processes that those tools aren't able to handle, making Flow unsuitable
> >for deployment on those kinds of pages.
> >
> >To better address the needs of our core contributors, we're now focusing
> >our strategy on the curation, collaboration, and admin processes that take
> >place on a variety of pages. Many of these processes use complex
> >workarounds -- templates, categories, transclusions, and lots of
> >instructions -- that turn blank wikitext talk pages into structured
> >workflows. There are gadgets and user scripts on the larger wikis to help
> >with some of these workflows, but these tools aren't standardized or
> >universally available.
> >

Nearly every ambitious project starts with huge promises and fizzles out
with a "change in focus". What's the underlying issue here? How can we get a
product to a point where it's deployed and usable? I know there's a problem
with scope creep for Wikimedia projects (due to design by committee), but
that alone can't be the reason.

I know no one wants to admit failure, but when WMF says something is in
maintenance mode they really mean they're killing the project. Can there be
a postmortem for this, so that we can at least learn something from the failure?

- Ryan


___
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] Fundraising banners (again)

2014-12-05 Thread Ryan Lane
phoebe ayers phoebe.wiki@... writes:

 
 Hello! Sorry, I didn't realize that's what you were referring to. I
 haven't looked at all the raw fundraising data, no, and I haven't
 looked at that set that Lila refers to. (The reports we get are
 summaries, which is much preferable when you've got a lot of
 information to get through about all sorts of topics).
 
 I *do* however trust our fundraising team's analysis, and I don't
 think they need my mediocre user testing skills and even more mediocre
 statistical skills to help them sort it out. I agree with you however
 that it would be great if the anonymized data/test methods can be made
 public; I think we would all learn a lot, and the group might be able
 help refine the tests.
 

Though I trust their analysis, based on the strong negative reaction that
I'm getting from people in person and from social media, I think it's
important to verify the data and especially the methodology.

 It's anecdotal in the sense that without some statistical analysis
 it's sort of a case of whatever catches your eye standing out. Your
 statement surprised me, so I just read through around 1,500 #wikipedia
 tweets from the last six hours; the vast majority are the canned
 fundraiser tweet, with a handful of others (stuff about articles) and
 three, that I saw, that are negative about the fundraising banners. Is
 that a significant number? Is it a pattern? Is it more meaningful than
 all those other people donating? Is the absence of positive feedback
 significant? (though I doubt we've ever gotten I 3 the Wikipedia
 banners as a tweet). I have some instincts around these questions,
 but I honestly don't know the answers, and I would love to see some
 proper analysis. I am, as always, a big fan of research :)
 

Do a twitter search for 'wikipedia banners' or better 'wikipedia ads'. Using
a hashtag is going to skew your data towards autogenerated tweets. Using
'wikipedia banners' is also slightly skewed, because it selects a group of
people that know what we call them. Most people think of our banners as ads,
because whether we consider them ads or not, it's the most common term for
them, and it's the word people will associate.

The tweets I selected were from a short period of time (less than 6 hours).
The vast majority (90%) of the tweets were negative about the banners. I
excluded any tweets that didn't mention the size or the message.

I'm not asking for the Foundation to stop the banners. I'm not trying to
make the fundraising team's life harder. What I want is acknowledgement that
there is indeed a problem and that it will be addressed for next fundraiser.
I do want more than a promise of that, though. I'd like to see progress on
more reasonable banners during the next year before the 100% fundraiser
starts, so that we're not having the same discussion yet again.

- Ryan


___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] Fundraising banners (again)

2014-12-05 Thread Ryan Lane
phoebe ayers phoebe.wiki@... writes:

 
 I just re-read this whole thread (!) this morning and here are the
 themes of points raised that I'm seeing ... I'll add this to the talk
 of https://meta.wikimedia.org/wiki/Fundraising_principles too.
 

This is great. Thank you!

 Anything else I missed? My editorializing is in brackets [ ].
 
 ==communication re: fundraising season==
 * develop banner approaches in the off-season [the fundraising team
 already does this, but there's desire for community discussion too]
 * if you do something new (in a geography etc.) make sure you
 communicate it to the stakeholders
 * fundraising team seen as sometimes unresponsive [though acknowledged
 that this, the en.wp fundraiser, is their biggest crunch week]

Also that when concerns arise, the response is defensive, rather than
acknowledging that there may be some problem. This would go a long way
towards making the threads friendlier.

 ==data==
 * we want all the data, because we are Wikipedians
 * especially .. user sentiment methodology  raw data
 * social media reaction: it seems very negative/more negative than
 past??/how much is there/should we worry about it?

I think it's worthwhile information that we should be tracking year to year.
If the amount of negative messaging is increasing, it's bad, if it's
decreasing, it's good, for the most part.

 * how many impressions do people see? Is it really less? [note, we've
 been trying to optimize for fewer impressions for a long while, hence
 the shorter fundraiser]
 

There was research put in by the fundraising team that showed people donated
within a certain number of banners and that the numbers quickly decreased. I
think this decreased the number of banners people saw by a very large
amount, and was really awesome work :).

Thanks again for listening, acknowledging and summarizing!

- Ryan



___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] Fundraising banners (again)

2014-12-04 Thread Ryan Lane
phoebe ayers phoebe.wiki@... writes:

 
 With Sam, I'd like to add my thanks to Lila, and to the fundraising
 team which has done an extraordinary job of testing, optimizing, and
 running our fundraising campaigns. And thanks to all of you, for being
 concerned about and invested in our projects' public image and
 financial health and future.
 

The fundraising team is amazing at their jobs. They raise money incredibly
efficiently. So indeed, thank you fundraising team for your work. It's a
high pressure job, which I can empathize with.

As one of the people concerned about the projects' public image, I read your
words of thanks, but don't feel thanked by the content of your post, since
it doesn't address the raised concerns.

Have you seen the data that suggests the public image isn't being damaged?
The board members have signed NDAs, so they are allowed access to the raw
data. I also have a signed NDA, so technically I should be allowed to see it
as well.

Can you answer some direct questions? Do you feel the size of the banners is
appropriate to the mission, given that it obscures the content significantly
(and in many cases completely)? Do you feel the messaging is accurate to the
financial situation of the Foundation?

 Some perspective from my role as a trustee:
 One section of our recent board meeting was spent discussing the
 fundraising trends that Lila refers to, and thinking about the
 longer-term future of fundraising on our projects. These trends
 include: on-site page views are dramatically down over the past two
 years in the US  Europe, where the majority of our revenue is raised.
 At the same time, there are challenges with fundraising in many of the
 places where readership is growing. Additionally, of course we want
 and need a strong financial basis for the projects over the long-term

gmane seems to be cutting off most of your message in the followup view,
which is unfortunate.

Your post mostly discusses the financial situation and the efficacy of the
banners. There's no question about the efficacy of the banners. They work
extremely well and there's shared data that proves it. There's question
about the content and the size of the banners and there's no shared data
that shows harm isn't being caused.

It's disappointing that a member of the board sees it as appropriate to
scare people as a means of generating funding. The foundation meets its
goals every year. As you've pointed out in this post, it does so faster than
ever, even while increasing the budget every year. This shows well that the
situation isn't dire.

- Ryan


___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] Fundraising banners (again)

2014-12-04 Thread Ryan Lane
phoebe ayers phoebe.wiki@... writes:

 
 
 You're asking me to prove a negative. My inability to do so has
 nothing to do with NDAs or the lack of them. There's no secret data
 that shows that well, the banners make people hate Wikipedia but they
 have a good donation rate. And if there was, why in the world would
 anyone who cares about the projects make that choice? We are all on
 the same side here regarding wanting to preserve the love that people
 have for our projects.
 
 So no, I don't have data for you about the no doubt diverse set of
 reactions that exist in the world to the banners. (Beyond anecdotal
 info that we all have access to: twitter, this mailing list, etc.)
 What I do have is information about whether the banners are compelling
 enough to donate -- that's where the a/b testing etc. comes in -- and
 that is info that Megan et al shares with everyone.
 

I'm not asking you to prove a negative. Lila wrote in a previous post that
they have data that shows the banners are not causing brand damage. I'm
asking if you've seen that data. I trust you if you say you've been given
the data and can say it does indeed prove there's no brand damage. Based on
your reaction I know the answer to my question. Can you please get access to
the data in question and give us your take on it?

I also asked for the foundation to share the methodology they used to obtain
and analyze this data. There's nothing private about this and no reason it
shouldn't be possible to share it now. It would be excellent to have this,
because we'd know if their methodology is appropriate.

Of course, I'm still eager to see the anonymized data, but based on Lila's
post it looks like we won't get a chance until after the fundraiser.

The data from social media isn't anecdotal. It's public and is
overwhelmingly negative towards the banners. It shows there's a negative
reaction to both the message and size of the banners. Something I don't
understand is why this isn't at least being acknowledged as being a problem.

 
 Personally speaking: I happen to like this year's banners, more than
 last year's. The boxes and disclaimers are clearer, the text is to the
 point. And yes, I think the messaging is accurate. This is the text
 I'm seeing in the U.S. at the moment:
 
 This week we ask our readers to help us. To protect our independence,
 we'll never run ads. We survive on donations averaging about $15. Now
 is the time we ask. If everyone reading this right now gave $3, our
 fundraiser would be done within an hour. Yep, that’s about the price
 of buying a programmer a coffee. We’re a small non-profit with costs
 of a top website: servers, staff and programs. Wikipedia is something
 special. It is like a library or a public park where we can all go to
 think and learn. If Wikipedia is useful to you, take one minute to
 keep it online and ad-free another year.Thank you.
 
 And all of that is certainly true. We do have the costs of a top
 website, we are a small nonprofit (bigger than many, but smaller than
 most brand-name NGOs), and we do survive on donations averaging $15
 (something like 85% of our revenue comes from these donations, IIRC).
 Additionally, I think we're all in agreement that we never will and
 should never run ads.
 
 I am not just saying this because I am a trustee -- I've seen every
 fundraising campaign that the WMF has ever run, and participated in
 discussions about most of them, and I genuinely do like this year's.
 Yes, the banners are in your face, and I'm OK with that, given that
 it's a quick campaign and as always one click makes them go away
 (forever, I think). Obviously, opinions on the banner aesthetics can
 and will vary. But discussions on how much money we should raise
 (which, of course, is not an either/or choice) -- that's a different
 conversation.
 

Thank you.

- Ryan


___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] Fundraising banners (again)

2014-12-03 Thread Ryan Lane
Lila Tretikov lila@... writes:

 
 This type of fundraising is -- by its very nature -- obtrusive. We are
 thinking about other options. But, as with anything, every action has
 equal and opposite reaction. Anything we do, we have to consider the
 consequences and we will find flaws.
 
 Now for the specifics:
 
 Yes -- the fundraising team works incredibly hard to optimize and adjust to
 changes in our environment and to minimize obtrusiveness (there are
 multiple ways to measure this: total impressions, % conversions, size,
 parallelizing campaigns, etc.). It is a complex multi-variable equation.
 Fundraising uses A/B tests to do much of the optimization, but they also
 use surveys, user tests, and sentiment analysis. Some of what you see is
 counter-intuitive (even to me, and I have experience with this), but they
 work. All of this year's tests showed minimal brand impact even from the
 overlay screen. That said, going forward we are considering an unbiased 3rd
 party to do some of this analysis.
 

I was unaware of these other metrics that fundraising collects. Can you
share them with us? It would be really great to get information about the
methodology used, the raw or anonymized data, and the curated
data/visualizations that's being used to show there's no brand damage.

Anecdotal evidence and social media suggests the opposite of what you're
saying, so I'm eager to see the evidence that shows nothing's wrong.

- Ryan


___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] Fundraising banners (again)

2014-12-03 Thread Ryan Lane
Lila Tretikov lila@... writes:

 
 I would like to expose this more, maybe after this crunch. Just keep in
 mind that it takes time to anonymize and process -- a time that is
 otherwise spent on optimizing or collaborating. One bucket of resources,
 many demands... and I'd like to keep us as lean as we are :)
 

You have a community that's upset because they believe the fundraising
banners are causing long-lasting harm to Wikimedia's brand. The analytics
team can probably spend a few hours handling this. They aren't allocated to
the fundraiser.

If it's so labor intensive to go through this data, then it's likely not
being actively used to make decisions. At minimum the methodology that's
being used can be shared.

 Below is a soundbite I got from many notes I get from our donors, this is
 not unusual about this banner:
 
 *...banner on wikipedia today motivated me to donate for the first time.
 I think the increased size properly conveyed the importance of the
 donations to running the site.  Previous banners were a bit too polite or
 subtle to get me thinking.*
 

Here's the results of a quick twitter search:

Every year, the Wikipedia begging banners get bigger and bigger, now it's
3/4 of the screen

Wikipedia's donation banners are so huge now that they actually startle me
when they load.

.@Wikipedia might as well use their obtrusive donation banners as ad space.
Or whenever they are running low on funds, enable ads.

every time wikipedia asks for money the banners get bigger and bigger

Holy shit, @wikipedia, just have done with it and put ads up—these donation
banners are awful.

remember when wikipedia donation banners used to take up only 5% of the page

I WOULD donate to @Wikipedia but their donation banners are just too damn
small. I can never spot the darn things!

I hate to say this but @Wikipedia's Donate ! banners are very annoying.
Especially when you've already donated  don't like to feel forced

fuck your giant ass banner ads, @wikipedia. i want my previous donations back.

@sillyredfox Those ads are overly obtrusive. Never giving to @Wikipedia
until they're toned down.

I'd rather let Wikipedia mine bitcoin on my machine than be assaulted with
their these aren't ads fundraiser ads.

@codinghorror Considering Wikipedia have 90 mil in cash in the bank, the
ads have an oddly desperate tone.

Dear Wikipedia users: To protect our independence, we'll never run
ads...except the huge one begging for cash you'll see on EVERY PAGE.

There's so, so many more and I only included results that were relevant to
the size or copy.

There's a theme of this search, too. There's not a single positive thing
being said about them. I used to see people joking about the Jimmy banners,
encouraging people to donate. The only jokes I see now are at Wikipedia's
expense.

- Ryan


___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] Fundraising banners (again)

2014-12-03 Thread Ryan Lane
svetlana svetlana@... writes:

 
 I wrote:
 
  it's usually both sides of the conversation at fault for accumulating
their rage instead of
 communicating it early
 
 I unintentionally skipped a couple words. I meant to say:
 
  it's usually both sides of the conversation at fault, *such* *as* for
accumulating their rage instead of
 communicating it early
 

I worked for Wikimedia Foundation for a little over four years. Every year I
(and many other staff members) have expressed worry about the size and
message of the banners. There's been plenty of early communication.

Every year we get promises that they'll work on making the banners better.
However, it seems when they say better, they mean more effective from the
perspective of generating revenue. The message from the fundraising staff
and Lila is more of the same.

This year I've started having people I know worry that Wikipedia is in
financial trouble. It makes me feel ashamed when I have to tell them
Wikipedia is in fact fine, but that the foundation uses this messaging to
more effectively drive donations. It makes them angry to hear it.

I'm not trying to paint this as us vs them. I'm trying to express that
planting heads firmly in the sand is not an effective approach to dealing
with the brand damage that's readily apparent on social media.

- Ryan


___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] Fundraising banners (again)

2014-12-02 Thread Ryan Lane
Megan Hernandez mhernandez@... writes:

 
 
 As Lila’s email said, we launched our end of year English fundraising
 campaign on Tuesday. I wanted to share a little more background on the
 mechanics of the English Wikipedia campaign, and where we are on our goals
 this year to-date.
 
 Starting today, banners are being shown to 100% of anonymous readers on
 English Wikipedia in the US, UK, Canada, Australia and New Zealand. Our end
 of year campaign goal is $20 million. As Lila mentioned, our goal is to
 serve more powerful reminders to be able to limit the total number of
 banners each reader sees. We are constantly experimenting with new methods
 to reach our readers and optimize the donation experience.
 

I know I used to write an email internally every year, saying our banners
are getting out of control, but that's because every year they get bigger
and more obscuring of the content. This year, as usual, is not an exception.
However, this year the banners didn't just get bigger, the copy seems to be
more fear inducing as well.

Today I had a coworker private message me, worried that Wikipedia was in
financial trouble. He asked me if the worst happened, would the content
still be available so that it could be resurrected? I assured him that
Wikimedia is healthy, has reserves, and successfully reaches the budget
every year. Basically I said there wasn't much to worry about, because there
isn't.

The messaging being used is actively scaring people. This isn't the first
person that's asked me about this. When they find out there's not a real
problem, their reaction quickly changes. They become angry. They feel
manipulated.

My coworker told me that he donates generously every year, which is rare for
him because he doesn't often donate to charities. He said this year's ads
are putting him off. He doesn't feel like he should donate.

I understand that efficient banner ads are good, because they reduce the
number of times people need to see the ad, but it's not great when people
stop posting funny banner memes and start asking Wikimedia to switch to an
advertising model (seriously, do a quick twitter search).

- Ryan Lane


___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] WaPo Wikipedia's 'complicated; relationship with net neutrality

2014-11-30 Thread Ryan Lane
Kim Bruning kim@... writes:

 
 
 Washington post article
 
http://www.washingtonpost.com/blogs/the-switch/wp/2014/11/25/wikipedias-complicated-relationship-with-net-neutrality/
 

The response to this is embarrassing and lacking. Wikipedia Zero is an
amazing program (and is one of the only excellent non-engineering things the
foundation has done). Providing free access to Wikipedia doesn't violate the
concept of net neutrality. Access to Wikimedia is being subsidized by the
mobile companies. Access to other sources of information isn't being slowed.
There's no extra charge to access other sources of information.

My biggest wonder here is: why in the world is the HR director for the
foundation speaking with the press about this on behalf of the foundation
(and the movement)? This seems like the kind of thing the communications
department, or the ED (or DD) should be doing.

- Ryan Lane


___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] WaPo Wikipedia's 'complicated; relationship with net neutrality

2014-11-30 Thread Ryan Lane
Mark delirium@... writes:

 
 I don't see a distinction here, unless you're extremely naive about 
 economics. Discriminatory pricing in any market can be done in two ways: 
 1. have a standard rate and add a surcharge to certain disfavored 
 uses; or 2. have a standard rate and give a discount to certain 
 favored uses. Most things done with #1 could be reconfigured to be done 
 with #2 or vice-versa; it ends up as mainly a rhetorical and 
 administrative difference. In either case, applied to data, it's varying 
 pricing packet pricing based on whether the source of the packets is 
 favored or disfavored by the ISP (in this case, Wikipedia is favored), 
 which is precisely what net neutrality wishes to prohibit.
 


While a fine and principled view this is, its strict nature harms those
we're most interested in reaching.

We really need to consider what we're after when talking about net
neutrality. Offering free access to services to subscribers who don't have
data plans (most likely because they can't afford them) is a much different
thing than tiered levels of access for people who are paying for data.
Assuming there's no conflict of interest from the telecoms themselves this
is not actively harmful.

Note that for your points, neither 1 nor 2 is true, since there's no
standard rate.

- Ryan


___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] WaPo Wikipedia's 'complicated; relationship with net neutrality

2014-11-30 Thread Ryan Lane
MZMcBride z at mzmcbride.com writes:

 
 Ryan Lane wrote:
 Kim Bruning kim at ... writes (roughly):
  
  
  Washington post article: http://wapo.st/1zUXNXj
  
 
 The response to this is embarrassing and lacking. Wikipedia Zero is an
 amazing program (and is one of the only excellent non-engineering things
 the foundation has done). [...]
 
 I think calling Wikipedia Zero non-engineeering is kind of bizarre,
 possibly just wrong. Wikipedia Zero spans both development and operations.
 It has a MediaWiki extension
 https://www.mediawiki.org/wiki/Extension:ZeroBanner and custom back-end
 (Web server) configuration to support it. And of course ZeroBanner is just
 the latest extension, it's had others, while parts of Wikipedia Zero's
 infrastructure have been integrated (yay!) with other extensions.
 
 To be clear, I'm not attacking Wikipedia Zero or the resources it's using,
 I kind of like the idea, but it's definitely an engineering project. In
 addition to engineering resources, Wikipedia Zero requires administrative
 overhead for partnership negotiation and management, which is probably not
 unique to the Wikipedia Zero team. Only excellent seems a bit rough.
 

It was a project created and lead by the business development folks and was
given some engineering resources to make it happen. It's been incredibly
successful and has a real and important impact. Even taking engineering
projects into consideration, this is one of Wikimedia's most impacting
projects from the point of view of the mission.

 My biggest wonder here is: why in the world is the HR director for the
 foundation speaking with the press about this on behalf of the foundation
 (and the movement)? This seems like the kind of thing the communications
 department, or the ED (or DD) should be doing.
 
 This isn't arguably wrong, just plain wrong.   Gayle's title is Chief
 Talent and Culture Officer and the Director of Human Resources is someone
 else who reports to her; cf.
 https://www.wikimedia.org/wiki/Template:Staff_and_contractors#HR. I agree
 that for a media outlet such the Washington Post, having a C-level person
 speak is best... and that's what happened here. (Now whether the Wikimedia
 Foundation should be large enough to require a Chief Talent and Culture
 Officer position is a separate question that can hopefully be addressed in
 another thread.)
 

http://siliconvalleyjobtitlegenerator.tumblr.com/

Sorry, I used director instead of chief. That doesn't change the fact that
her role is to lead HR. If you look at the staff page, you'll see this is in
the case and from a practical point of view, she does HR stuff.

Having any C level respond to the press is a bad approach, especially with a
subject this touchy. This is the entire reason for having a
communications/brand department.

- Ryan


___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] Role and size of the Wikimedia Foundation and chapters

2014-11-30 Thread Ryan Lane
MZMcBride z at mzmcbride.com writes:

 
 Gerard Meijssen wrote:
 Do not be daft. The Wikimedia Foundation centralised its fundraising. It
 said that it would do a better job. Seen from a central periphery model,
 it probably does, However seen from the Netherlands it is rather silly.,
 
 Pooh poohing this away with you can donate time as well is fine when you
 are in the centre.
 
 I see a few inter-related questions here that I think must be resolved
 during the drafting of the next Strategic Plan:
 
 * who should primarily be responsible for collecting donations?
 
 * how large, in terms of staff and budget, should the Wikimedia Foundation
   be?
 
 * how large, in terms of staff and budget, should individual chapters be?
 
 * should the Wikimedia Foundation continue to be headquartered in San
   Francisco?
 
 * how do we measure effectiveness/impact of programs by the Wikimedia
   Foundation and chapters?
 
 I personally don't think the current model of having so many staff in such
 an expensive area of the world is practical or sustainable. The cost of
 being in San Francisco, California seems to _far_ outweigh any benefit
 it's providing. It's been six years since the Wikimedia Foundation moved
 out to San Francisco and what do we have to show for it? Weekly lunches
 with Wikia? Ugh. Is $60 million a year really needed? I doubt it, we did
 just fine with a fraction of that amount. But these questions and their
 answers all need to be thoroughly explored, in my opinion.
 

Based on what the foundation is willing to pay for engineers, you're
probably right that it doesn't have a lot of benefit, since it's not a major
consideration for a lot of tech folks in the area. Wikimedia also isn't a
very active member of the tech community in San Francisco. When I attend
meetups and conferences, the thing I hear the most is Wikimedia is in San
Francisco?.

Really, though, based on the salaries paid, it doesn't matter where they're
headquartered, since that cost would likely be similar anywhere.

From a cost perspective, I'd be looking at the ratio of management and
non-management. I'd also ask how much is being spent on management and
executive training events (aka retreats).

- Ryan




___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] [Wikitech-l] Reasonator use in Wikipedias

2014-01-21 Thread Ryan Lane
On Tue, Jan 21, 2014 at 7:17 AM, Gerard Meijssen
gerard.meijs...@gmail.comwrote:

 Hoi,

 At this moment Wikipedia red links provide no information whatsoever.
 This is not cool.

 In Wikidata we often have labels for the missing (=red link) articles. We
 can and do provide information from Wikidata in a reasonable way that is
 informative in the Reasonator. We also provide additional search
 information on many Wikipedias.

 In the Reasonator we have now implemented red lines [1]. They indicate
 when a label does not exist in the primary language that is in use.

 What we are considering is creating a template {{Reasonator}} that will
 present information based on what is available in Wikidata. Such a template
 would be a stand in until an article is actually written. What we would
 provide is information that is presented in the same way as we provide it
 as this moment in time [2]

 This may open up a box of worms; Reasonator is NOT using any caching. There
 may be lots of other reasons why you might think this proposal is evil. All
 the evil that is technical has some merit but, you have to consider that
 the other side of the equation is that we are not sharing in the sum of
 all knowledge even when we have much of the missing requested information
 available to us.

 One saving (technical) grace, Reasonator loads round about as quickly as
 WIkidata does.

 As this is advance warning, I hope that you can help with the issues that
 will come about. I hope that you will consider the impact this will have on
 our traffic and measure to what extend it grows our data.

 The Reasonator pages will not show up prettily on mobile phones .. so does
 Wikidata by the way. It does not consider Wikipedia zero. There may be more
 issues that may require attention. But again, it beats not serving the
 information that we have to those that are requesting it.


I have a strong feeling you're going to bring labs to its knees.

Sending editors to labs is one thing, but you're proposing sending readers
to labs, to a service that isn't cached.

If reasonator is something we want to support for something like this,
maybe we should consider turning it into a production service?

- Ryan
___
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] Wikimedia labs-tools

2013-09-11 Thread Ryan Lane
On Wed, Sep 11, 2013 at 8:45 AM, Magnus Manske
magnusman...@googlemail.comwrote:

 There was a recent mail saying that Labs is not considered production
 stability. Mainly a disagreement about how many 9s in the 99.9% that
 represents.


Indeed. I don't want to get into the debate about this again, but tools is
considered semi-production which is a smaller set of nines. We're
reasonably staffed and have a well designed enough infrastructure to
properly support that, but it's not the case for production-level
support. The specific discussion about levels of support was for a service
that should be supported by WMF in production since it has uptime
requirements that we aren't scoped to handle.

We handle the underlying infrastructure with production-level support, but
we don't have the same level of support for projects inside of the
infrastructure.

I think so far we've done a relatively good job of keeping stability and
the level of stability has been increasing, not decreasing. If we did an
analysis of tools project outages vs toolserver, I'm positive our level of
unscheduled downtime would be far lower than toolserver's.

- Ryan
___
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] Wikimedia labs-tools

2013-09-11 Thread Ryan Lane
On Wed, Sep 11, 2013 at 7:50 AM, John phoenixoverr...@gmail.com wrote:

 tools.wmflabs.org is supposed to be the replacement for the toolserver
 which the wmf is basically forcefully shutting down. I started the
 migration several months ago but got fed up with the difficulties and
 stopped. In the last month I have moved most of my tools to labs, and I
 have discovered that there are some serious issues that need addressed.

 The toolserver was a fairly stable environment. I checked my primary host
 I connect to and it has been up for 4 months with continuous operations.


I'm not going to do an analysis on this to disprove you, but there were
periods of time where toolserver was down for over a week (more than once,
at that). You're talking about connection to bastion hosts, which doesn't
reflect the system as a whole.


 tools however is being treated like the red-headed step child. According
 to the people in charge of labs they dont care about ensuring stability and
 that if stuff breaks Oh well well get to it when we can. They say that
 tools is not a production service so we really don't give a , if it
 breaks it breaks, we will fix it when we can but since its not production
 its not a priority.


The only major instability we've had in tools is with the NFS server. We've
been working on it for months. I honestly think Labs is cursed when it
comes to storage, because our other major instability since project
inception was glusterfs.

As mentioned in another email, we do care, but we also need to be clear
about our level of support. Our advertised level of support is
semi-production. If something breaks in the middle of the night we have
people that will wake up and fix it.


 One good example of this is that a tool cannot connect to
 tools.wmflabs.org due to a host configuration issue. This is a known bug,
 we have a way of fixing it, but its still not implemented


This is due to the way the floating IP addresses work in OpenStack's nova
service. There's workarounds for this issue. For instance, you can connect
to the private DNS or IP address of the webserver, rather than using the
public hostname.

This is definitely something we'd like to fix, but haven't had a chance to
do so yet.

-Ryan
___
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] Disinformation regarding perfect forward secrecy for HTTPS

2013-08-03 Thread Ryan Lane
On Fri, Aug 2, 2013 at 7:23 PM, Anthony wikim...@inbox.org wrote:

 On Fri, Aug 2, 2013 at 10:07 PM, Anthony wikim...@inbox.org wrote:

 
  Anthony wrote:
  
   How much padding is already inherent in HTTPS?
 
  None, which is why Ryan's Google Maps fingerprinting example works.
 
 
  Citation needed.
 

 Also please address
 https://en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Padding

 It seems that the ciphers which run in CBC mode, at least, are padded.
  Wikipedia currently seems to be set to use RC4 128.  I'm not sure what, if
 any, padding is used by that cipher.  But presumably Wikipedia will switch
 to a better cipher if Wikimedia cares about security.


We're currently have RC4 and AES ciphers in our list, but have RC4 listed
first and have a server preference list to combat BEAST. TLS 1.1/1.2 are
enabled and I'll be adding the GCM ciphers to the beginning of the list
either during Wikimania or as soon as I get back.

- Ryan
___
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] NSA

2013-08-01 Thread Ryan Lane
On Thursday, August 1, 2013, Anthony wrote:

 On Thu, Aug 1, 2013 at 12:44 AM, Tim Starling 
 tstarl...@wikimedia.orgjavascript:;
 wrote:

  On 01/08/13 14:15, Anthony wrote:
   On Wed, Jul 31, 2013 at 9:27 PM, Ryan Lane 
   rl...@wikimedia.orgjavascript:;
 wrote:
  
   I would be fired and jailed before I knowingly let that occur. If this
  was
   the case I'd very surely not be working for Wikimedia Foundation.
  
  
   Key word there being knowingly.
 
  I don't know why the NSA would sneak around in our data centres
  mirroring our ethernet ports if they already have almost all of our
  access logs by capturing unencrypted traffic as it passes through
  XKeyscore nodes.
 

 Especially not when they can get someone else to do it for them.

 I think you should save the conspiracy theories until after we switch
  anons to HTTPS, that's when they will have an incentive.
 

 And I thought Ryan Lane was talking about the future, not the past.  I
 certainly was.


I'm talking about both.

- Ryan
___
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] Disinformation regarding perfect forward secrecy for HTTPS

2013-08-01 Thread Ryan Lane
On Thu, Aug 1, 2013 at 1:33 PM, James Salsman jsals...@gmail.com wrote:

 With the NSA revelations over the past months, there has been some very
 questionable information starting to circulate suggesting that trying to
 implement perfect forward secrecy for https web traffic isn't worth the
 effort. I am not sure of the provenance of these reports, and I would like
 to see a much more thorough debate on their accuracy or lack thereof. Here
 is an example:

 http://tonyarcieri.com/imperfect-forward-secrecy-the-coming-cryptocalypse

 As my IETF RFC coauthor Harald Alvestrand told me: The stuff about 'have
 to transmit the session key I the clear' is completely bogus, of course.
 That's what Diffie-Hellman is all about.

 Ryan Lane tweeted yesterday: It's possible to determine what you've been
 viewing even with PFS. And no, padding won't help. And he wrote on today's
 Foundation blog post, Enabling perfect forward secrecy is only useful if
 we also eliminate the threat of traffic analysis of HTTPS, which can be
 used to detect a user’s browsing activity, even when using HTTP, citing
 http://blog.ioactive.com/2012/02/ssl-traffic-analysis-on-google-maps.html

 It is not at all clear to me that discussion pertains to PFS or Wikimedia
 traffic in any way.

 I strongly suggest that the Foundation contract with well-known independent
 reputable cryptography experts to resolve these questions. Tracking and
 correcting misinformed advice, perhaps in cooperation with the EFF, is just
 as important.


Well, my post was reviewed by quite a number of tech staff and no one
rebutted my claim.

Assuming traffic analysis can be used to determine your browsing habits as
they are occurring (which is likely not terribly hard for Wikipedia) then
there's no point in forward secrecy because there's no point in decrypting
the traffic. It would protect passwords, but people should be changing
their passwords occasionally anyway, right?

Using traffic analysis it's also likely possible to correlate edits with
users as well, based on timings of requests and the public data available
for revisions.

I'm not saying that PFS is worthless, but I am saying that implementing PFS
without first solving the issue of timing and traffic analysis
vulnerabilities is a waste of our server's resources.

- Ryan
___
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] Disinformation regarding perfect forward secrecy for HTTPS

2013-08-01 Thread Ryan Lane
On Thursday, August 1, 2013, James Salsman wrote:

 Ryan Lane wrote:
 ...
  Assuming traffic analysis can be used to determine your browsing
  habits as they are occurring (which is likely not terribly hard for
 Wikipedia)

 The Google Maps example you linked to works by building a huge
 database of the exact byte sizes of satellite image tiles. Are you
 suggesting that we could fingerprint articles by their sizes and/or
 the sizes of the images they load?


Of course. They can easily crawl us, and we provide everything for
download. Unlike sites like facebook or google, our content is delivered
exactly the same to nearly every user.



 But if so, in your tweet you said padding wouldn't help. But padding
 would completely obliterate that size information, wouldn't it?


Only Opera has pipelining enabled, so resource requests are serial. Also,
our resources are delivered from a number of urls (upload, bits, text)
making it easier to identify resources. Even with padding you can take the
relative size of resources being delivered, and the order of those sizes
and get a pretty good idea of the article being viewed. If there's enough
data you may be able to identify multiple articles and see if the
subsequent article is a link from the previous article, making guesses more
accurate. It only takes a single accurate guess for an edit to identify an
editor and see their entire edit history.

Proper support of pipelining in browsers or multiplexing in protocols like
SPDY would help this situation. There's probably a number of things we can
do to improve the situation without pipelining or newer protocols, and
we'll likely put some effort into this front. I think this takes priority
over PFS as PFS isn't helpful if decryption isn't necessary to track
browsing habits.

Of course the highest priority is simply to enable HTTPS by default, as it
forces the use of traffic analysis or decryption, which is likely a high
enough bar to hinder tracking efforts for a while.

- Ryan
___
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] NSA

2013-07-31 Thread Ryan Lane
On Wed, Jul 31, 2013 at 1:00 PM, David Gerard dger...@gmail.com wrote:

 On 31 July 2013 21:00, David Gerard dger...@gmail.com wrote:
  On 31 July 2013 20:48, Risker risker...@gmail.com wrote:

  I believe the concern derives from one of the subpages of the article:
 
 https://image.guim.co.uk/sys-images/Guardian/Pix/audio/video/2013/7/31/1375269604628/KS8-001.jpg
  (Credit to David Gerard for digging that out; this same issue is under
  discussion on the Wikitech-L list.)

  Yes, that's the image that made me say out loud Fuck. Fuck these
 people.


 How DARE they use us as their example. HOW DARE THEY.


Why would we expect that we weren't being targeted? Knowing what people are
looking up is powerful knowledge.

- Ryan
___
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] About the concentration of resources in SF (it was: Communication plans for community engagement

2013-07-26 Thread Ryan Lane
On Wed, Jul 24, 2013 at 12:02 PM, Steven Walling
steven.wall...@gmail.comwrote:

 On Wed, Jul 24, 2013 at 11:37 AM, Federico Leva (Nemo)
 nemow...@gmail.comwrote:

  Anyway, being able to disband the SF office as regards software
  development (and perhaps more), and switch to remote work only, would
  probably be the single most effective measure for enhancing communication
  and cooperation in the movement.


 As someone who moved to SF to work here, I could not disagree more. The
 amount of time and energy I save being near many of the people I work with
 closely in the same space is enormous. Not to mention the fact that many of
 us work better together with people we are able to see socially and so on.
 I could go on, but the truth is I think no one actually responsible for
 making such a decision is crazy enough to get rid of a central office.
 (Move the office? Maybe someday if we really are forced to. We've done it
 before. But get rid of a central office? No.)


I hear texas is wide open http://www.texaswideopenforbusiness.com/ca.php.

Detroit also has lots of cheap real estate and should be a major contender.

- Ryan
___
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] Use of YouTube videos in fundraising banners

2013-07-17 Thread Ryan Lane
A few clarifications inline.

On Tue, Jul 16, 2013 at 10:09 PM, Victor Grigas vgri...@wikimedia.orgwrote:

 On the fundraising team we had used banners to host still images (.jpgs) in
 the past. We wanted to make a video we could put into banners but in July
 2012 there was no open source HTML5 video player built into mediawiki.
 .Webm was not deployed on commons and I was told that Wikimedia did not
 have the technical capabilities to host video on that scale.


TimedMediaHandler had been deployed around this time, a while before the
blog post was written. I had looked through the threads related to the
banners to confirm this.


 Nevertheless I insisted and wanted to use open source video. I thought it
 was crazy that every other site on the internet could do this and we
 couldn't. Basically I asked everyone I could find at WMF who had anything
 to do with open source video (a little bit abruptly) 'Pretty please with
 sugar on top can we make open-source video work for Wikimedia?'

 Rob Lanphier told me that (the technical elements of this were over my
 head) we were painfully close to having .webm done, and it was going to be
 a bunch of details for his team to fix.

 I got in touch with Michael Dale and told him that if Kaltura could make
 .webm a reality, the fundraiser would be his first 'customer' - when I say
 that all I meant was that the fundraiser would be the first to use the
 video format on a mass scale.


Replace webm with h264. The threads all mentioned that the video formats we
support wouldn't work for mobile, and we'd need to look at adding h264
support to TimedMediaHandler. h264 is a proprietary format and it would
have been necessary for that to go through legal and some other hoops.

The end-result is the same, though. It was impossible to provide an open
format to all users. It was likely easier to send people to youtube than to
deal with the issues around h264.


 In November 2012, the new player was deployed:


 http://blog.wikimedia.org/2012/11/08/introducing-wikipedias-new-html5-video-player/

 My thanks to everyone who made it happen - we actually had a player that
 would work on many (but not all) devices and it had the added benefit of
 open source closed captions, which I had never seen anywhere else. It was
 awesome, but the reality of it was that WMF just didn't have enough servers
 or bandwidth to support video on that scale - even if it was open source.
 Everyone in the engineering department who I spoke to agreed that it was
 impossible. I had to speak to the legal department about embedding a video
 from a third party (if that was even possible). I was told that if we were
 to have a link from a third party, on each and every video we would have to
 provide this disclaimer:


Threads indicate that we had enough bandwidth and ops was interested in
seeing the load associated with this. I thought we had some issues with
varnish or squid, but searching my email indicates that we had video issues
when moving upload.wm.o to varnish (which was much later). At the time in
question we likely would have been able to handle the load.


 This video is hosted by YouTube.com subject to its Terms of
 Usehttp://www.youtube.com/t/terms
  and Privacy Policy http://www.google.com/intl/en/policies/privacy/. If
 you prefer,view on Wikimedia
 Commonshttp://wikimediafoundation.org/wiki/Thank_You/Dumisani_Ndubane
 .

 I disliked this workaround because it was inelegant and counter to the open
 source philosophy of Wikimedia, *but it would function*. It would play the
 video on a large scale to millions of potential viewers and if users didn't
 want to use Youtube.com a link to the video on Commons would be under each
 and every video.

 When the banner went live in late December


 https://en.wikipedia.org/wiki/Main_Page?banner=B12_1227_ThankYou_5pillarsforceBannerDisplay=true

 , it was great that it worked. I thought maybe this might spark
 conversations about open source video within the Wikimedia community and
 (to be really honest Tomasz) I was expecting to see this thread start the
 moment that the banners went live, because I think it is something that the
 community should concern itself with. Video production is something that
 every smartphone owner now has in their pocket. Think about where that will
 be in ten years.

 Even if it's a site that could mine data, I disagree that just providing
 links is a bad thing. How many links at the bottom of Wikipedia articles
 provide links to all kinds of sites that mine data? Those pages don't link
 to the policies of those sites, they just show an external link. To be
 fair, Yes it's a prominent, big button that we linked to Youtube.com and
 the disclaimer link to commons is small text. I'm a visual person and I
 like to avoid text if I have a big flashy button to click instead.

 In my view, this whole argument would provide reason to:
 1.) Only use a third party video option sparingly, as-needed until there
 are better open-source video