Re: [Wikimedia-l] [Wmfall] New Developers Quarterly Report's first edition

2017-10-18 Thread Brian Wolff
Fae wrote:
>Does the minus symbol in "-60.0%" mean anything? Being a retention
>percentage, I do not understand how it can be negative unless
>potential volunteers are getting rejected at the door before they can
>sign-up. Could that be corrected?

My understanding is that this means that the rentention percentage was
60% (or is it percentage points?) less than it was this time last

So its now 5%, but this time last year it was 12%.


Wikimedia-l mailing list, guidelines at: and
New messages to:

Re: [Wikimedia-l] [Wmfall] New Developers Quarterly Report's first edition

2017-10-18 Thread Brian Wolff
On Tue, Oct 17, 2017 at 7:03 PM, Srishti Sethi  wrote:
> Hello everyone,
> I would like to share the first edition of the New Developers Quarterly
> Report that the Developer Relations team has produced. This report covers
> metrics, survey analysis and lessons learned from new developers focused
> activities in the previous quarter (July-September 2017).
> If you have questions and feedback that you would like to share with us,
> please add them on the discussion page.
> To receive a notification when a new report is published, subscribe here.
> We plan to release a report every quarter and take action items identified
> from the key findings for improving our existing methods and processes. The
> next release will be in January 2018.
> If you have any questions, comments, and concerns, we will be more than
> happy to hear them!
> Thanks,
> Srishti

From the report:

>Percentage of volunteers active one year (± 3 months) after their first 
>contribution, out of all new volunteers attracted one year ago (between 
>April–June >2016). (Source: Calculation on data)
>QoQ: -26.5%. YoY: -60.0%

That's kind of scary


Wikimedia-l mailing list, guidelines at: and
New messages to:

Re: [Wikimedia-l] [Wikitech-l] IRC office hours: Shared hosting

2015-12-20 Thread Brian Wolff
On 12/20/15, James Salsman  wrote:
> Were there any objections to my request below?

Yes. As MaxSem said earlier[1], its basically being ignored as being
totally irrelevant to the topic at hand. (To be clear: Third-party
does not mean people who are doing work on Wikimedia sites that aren't
WMF. Third party = Wikis that have nothing to do with Wikimedia wikis
(e.g. wikia, wikihow, uncyclopedia etc))

If you want to get Dispenser his hard disk space, you should take it
up with the labs people, or at the very least some thread where it
would be on-topic.

> Can we also please hire additional database, system, and if necessary
> network administration support to make sure that the third party spam
> prevention bot infrastructure is supported more robustly in the future?

Then by definition it wouldn't be a third-party spam framework if WMF
was running it.


[Linking because this thread is super-cross posted, and some people
are going to be confused as to what I'm referring to]

Wikimedia-l mailing list, guidelines at:
New messages to:

[Wikimedia-l] Changes in Engineering leadership

2015-07-03 Thread Brian Wolff
Another thought: perhaps more investment could be made in providing career
development support for our volunteers of all kinds. It's relatively common
in the United States for organizations with lots of volunteers to put some
investment explicitly into helping the volunteers develop skills snd
experience that are useful for both their voluntary and paid work CVs. If
more of that kind of investment was made by WMF, volunteering would be more
attractive *and* WMF would benefit by having more ability to fill paid
positions from the ranks of volunteers.


I'm curious, concretely speaking, what do you have in mind?

FWIW, I'm very thankful to say that Wikimedia has given me many
opportunities to develop skills etc. When I made my first edit I
didn't know how to program, now that's what I do for living. Much of
that is thanks to help and guidance of many Wikimedians. Obviously
that's a different type of mentoring than you're suggesting, but
nonetheless much of what I know can be directly attributed to
mentoring by various people associated with the movement.


Wikimedia-l mailing list, guidelines at:

[Wikimedia-l] Unsolicieted email from wikimedia research

2015-06-27 Thread Brian Wolff
So as part of
, it appears that unsolicited emails have been sent out encouraging
people to translated articles into needed languages.

I am all for improving article coverage, etc, but I'm concerned about
the use of user account emails to send unsolicited mail that the user
has not opted into. I think use of user email addresses for purposes
other than the user has agreed to, is not ok.


Wikimedia-l mailing list, guidelines at:

[Wikimedia-l] [Wikimedia Announcements] Securing access to Wikimedia sites with HTTPS

2015-06-14 Thread Brian Wolff
I should also mention that while we try to be as transparent as possible in
all our work (including holding community consultations around all major
legal policies and providing frequent updates on our work), there are very
limited situations where public discussions could actually hurt free access
to Wikipedia. If you have thoughts about the evolving censorship landscape,
feel free to email me directly, if possible via encrypted email.

I find the secrecy surrounding the HTTPS rollout to be odd (To put it mildly).

What are we worried about. A censor who follows wikimedia-l, but not
the press release the WMF issued?

All the technical details are public (The git repo is public. Not to
mention the whole fact we're using https is going to be painfully
obvious when you visit the site, and its in https). We aren't doing
anything surprising, we are in the process of simply following what
many people consider best practices. We've publicly stated our
intention to do this for years now. And its pretty obvious what the
next steps of the deployment are going to be. The only thing really
being kept secret is the timetable, and which specific projects are up


Wikimedia-l mailing list, guidelines at:

[Wikimedia-l] [Wikimedia Announcements] Securing access to Wikimedia sites with HTTPS

2015-06-12 Thread Brian Wolff
To be truly free, access to knowledge must be secure and uncensored. At the
Wikimedia Foundation, we believe that you should be able to use Wikipedia
and the Wikimedia sites without sacrificing privacy or safety.

Today, we’re happy to announce that we are in the process of implementing
HTTPS to encrypt all Wikimedia
traffic. We will also use HTTP Strict Transport Security (HSTS) to
protect against efforts to ‘break’ HTTPS and intercept traffic. With this
change, the nearly half a billion people who rely on Wikipedia and its
sister projects every month will be able to share in the world’s knowledge
more securely.

Well this is a great move, and I applaud it (About time :), until such
a time as IPSec is fully deployed, isn't that a little misleading as
to the actual security afforded by this change? There is quite a lot
of evidence that the NSA is slurping up data from unsecured inter data
centre links of other people [1], seems unlikely that they are
ignoring us.

I also think we should have a more balanced position on how much
privacy TLS actually provides in the context of Wikipedia, so that
users can be properly informed. Sure, TLS is a step in the right
direction, probably stops most less well funded adversaries, but its
not a panacea. In the case of Wikipedia, the content of every page is
not static, but it is totally public, so Wikipedia is probably the
ideal target of traffic analysis type attacks against SSL. That sort
of thing is almost certainly more expensive than just grepping
packets, but surely seems to be within the budget of the NSA to do,
even in a bulk manner (Assuming that non-targeted surveillance by a
state level adversary is the unspoken threat model we're trying to
defend against).



Wikimedia-l mailing list, guidelines at:

Re: [Wikimedia-l] [Wikimedia Announcements] Fwd: A new structure for WMF Engineering.

2015-04-21 Thread Brian Wolff

 In particular, I wanted to share more about the plans for the Community
 Tech team. The creation of this team is a direct response to community
 requests for more technical support. Their mission is to understand and
 support the technical needs of core contributors, including improved
 support for expert-­focused curation and moderation tools, bots, and other
 features. Their mandate is to work closely with you, and the Community
 Engagement department, to define their roadmap and deliverables. We are
 hiring for a leader for this team, as well as additional engineers. We will
 be looking within our communities to help. Until then, it will be incubated
 under Toby Negrin, with support from Community Engagement.

I look forward to seeing how this works out. I sometimes worry that it
seems like over the years that developers have become more and more
separate from the community. Our community is our heart; It is why
we are all here. Having teams dedicated to working closely with our
communities sounds like an excellent idea.


Wikimedia-l mailing list, guidelines at:

Re: [Wikimedia-l] [Wikitech-l] Types of allowed projects for grant funding (renamed)

2015-02-21 Thread Brian Wolff
On 2/21/15, Pine W wrote:
 (Now continuing this discussion on Wikimedia-l also, since we are
 discussing grant policies.)

 For what it's worth, I repeatedly advocated for allowing IEG to support a
 broader range of tech projects when I was on IEGCom. I had the impression
 that there was a lot of concern about limited code review staff time, but
 it serms to me that WMF has more than enough funds to to pay for staffing
 for code review if that is the bottleneck for tech-focused IEGs (as well as
 other code changes).

 I also think that the grant scope policies in general seem too conservative
 with regard to small grants (roughly $30k and under). WMF has millions of
 dollars in reserves, there is plenty of mission-aligned work to be done,
 and WMF itself  frequently hires contractors to perform technical,
 administrative, communications, legal and organizing work. It seems to me
 that the scope of allowed funding for grants should be similar to the scope
 of allowed work for contractors, and it would serve the purposes that
 donors have in mind when they donate to WMF if the scope of allowed
 purposes for grants is expanded, particularly given WMF's and the
 community's increasing skills with designing and measuring projects for

That's actually debatable. There's grumbling about WMF code review
practices not being sufficient for WMFs own code (or as sufficient as
some people would like), and code review is definitely a severe
bottleneck currently for existing volunteer contributions.

However that's not a reason to have no IEG grants for tech projects
ever, its just a reason for code review to be specifically addressed
in the grant proposal, and for the grantee to have a plan. Maybe that
plan involves having a (volunteer) friend who has +2 do most of the
code review. Maybe that plan involves a staff member getting his
manager to allow him/her to have 1 day a week to review code from this
grant (Assuming that the project aligns with whatever priorities that
staff member's team has, such an arrangement does not seem
unreasonable). Maybe the grant includes funds for hiring code review
resources (ie non-wmf people with +2. We exist!). Maybe there is some
other sort of arrangement that can be made that's specific to the
project in question. Every project is different, and has different

I do not think expecting WMF engineering to devote significant
resources to IEG grants is viable, as I simply doubt its something
that WMF engineering is willing to do (And honestly I don't blame
them. They have their own projects to concentrate on.). IEG's are
independent projects, and must be able to stand mostly on their own
with minimal help. I do think getting WMF to perform the final once
over for security/performance of a project prior to deployment, at the
end, is reasonable (provided the code follows MW standards, is clean,
and has been mostly already reviewed for issues by someone in our
community). At most, I think bringing back 20% time, with that time
devoted to doing code review of IEGs, would be the most that we could
reasonably expect WMF to devote (but even if they didn't want to do
that, I don't think that's a reason not to do IEG tech grants).

Code review is an inherent risk to project success, much like user
acceptability. It should be planned around, and considered. We should
not give up just because there is risk. There is always risk. Instead
we must manage risk as best we can.


Wikimedia-l mailing list, guidelines at: