@Leigh - there are always other sources of funding available, but I
don't think it's appropriate to use them on something that should
absolutely be resourced from WMF (and when WMF is sitting on $70
million USD.) There are some projects that can't be appropriately
financed by WMF, and we should focus the limited funds available from
outside sources on those projects, not on a security audit of a
WMF-built extension deployed on our largest projects. I could
probably raise enough outside funding to do a rewrite and security
audit of a tool like this if one didn't already exist that had been
written and initially supported by WMF - especially when WMF,
economically, is a lot better off than many funding sources. As it
is, there's no way I could even try to raise outside funding for this
with a straight face.
Revi is absolutely right that anything done by an Outreachy or GSoC
intern will fall in to disrepair unless it's supported by the WMF
afterwards. The education extension needs to be supported by the WMF
- both because the WMF has spent millions of dollars over the course
of the education program's lifespan convincing people to buy in to it
and is finally starting to see buy-in across many communities, and
because it frankly scares me that there's a currently enabled
extension on ENWP that James feels comfortable describing as a
'significant attack vector.' I was aware of a couple of issues with
it, but they all required elevated privileges so I wasn't incredibly
worried about it - but if we're still finding significant security
issues on a widely deployed plugin, it needs a full security audit and
full set of fixes, not temp fixes for the biggest bugs now and hopes
that any remaining bugs aren't big enough to be an issue.
Additionally, even if an Outreachy or GSoC intern manages to
internationalize the WikiEdu dashboard in time for the next
instructional season (which isn't a guarantee,) that's another tool
we'll have to train instructors and the communities of various
Wikipedias on - and one of the frequent complaints of ENWP in the past
has been that too many education related tools have required them to
leave ENWP for a third party site to use a tool that is poorly
documented and maintained - which is likely what will happen if we
rely on a GSoC or similar intern.
Even if a temp fix addresses the most pressing security issues, the
suggestion here seems to be that there will continue to be security
issues with the plugin, just ones that aren't quite as pressing. With
$70 million banked, it's hard to justify leaving security holes that
are more than absolutely trivial in a plugin that is installed on one
of the largest websites on the world. I'm not trying to rag on the
amount we have banked - it's an appropriate level of reserves for an
organization with WMF's budget - but there are reasons we have
reserves to begin with, and this is one of them. The extension needs
to either have a thorough security audit with all non-trivial security
holes fixed, be replaced with a comparable extension written from the
ground up with security in mind if the holes are too big to fix, and
this needs to happen in a way that doesn't interfere drastically with
any one set of classes - and keep in mind, school schedules are
different around the world (any thing we do that kills an entire class
or set of classes or makes it impossible for their instructors to
track them easily will get us negative publicity in that area, and
will set local education programs back significantly.)
If this needs more resources than the departments involved currently
have (and I totally believe that it does,) then this needs to be
raised to a level of WMF where more resources can be assigned to it.
Even if the temp fixes that are coming fix the largest bugs we know
about, the fact that it remained in place on one of the largest sites
on the internet this long before the bugs found were enough to
constitute a 'significant attack vector' makes me strongly suspect
there are further security bugs in the plugin that we have yet to
discover, and calls for at a minimum a security audit and fixes
applied to anythingthat isn't absolutely trivial.
On Wed, Sep 30, 2015 at 6:28 AM, Leigh Thelmadatter
My 2 cents....
I dont understand why we have to have an extension for every single project.
It would make sense if we assume that ed programs only work in one language
and this tool had some effect on the content of the project. We have worked
in multiple languages, mostly Spanish followed by English but in our past
event last week, we tried translating articles about Mexico into Danish,
Swedish and French, taking "advantage" of our foreign students. We also work
a bit with Commons, not only uploading files, but providing subtitles (boy,
could we use a better way to do that... something like the tool on YouTube
as students are wasting a lot of time on figuring out times rather than
focusing on language) and improving/translating file descriptions (a good
exercise for lower level language classes). Right now, I cannot really track
a lot of this without personal reporting from students/teachers... many of
whom do not understand the need to document so precisely what we do.
A single education extension on Meta that could track user names across all
projects, now that we have global usernames, is much better going forward. I
talked to a couple of engineers during Wikimania 2015 who basically told me,
in so many words, that the extension as it is right now is not fixable, and
needs to be replaced. Such a tool is feasible as there are already tools
that do similar things (e.g.https://tools.wmflabs.org/guc/index.php
If we cannot get this done via the normal channels, we should look into
alternatives, such as partnering with one or more unis and maybe even find
other sources of funding.
Date: Wed, 30 Sep 2015 05:43:38 -0700
CC: qgil(a)wikimedia.org; jalexander(a)wikimedia.org
Subject: Re: [Wikimedia Education] Education extension blocked?
The librarian in me couldn't resist providing a citation for Pine's and
Kevin's and Revi's points.
This page may not be quite current. Until yesterday, the education program
extension was still marked as supported. The listed maintainer (and original
developer of our dear extension), Jeroen De Dauw, has not worked on it since
2012, afaict.  Nevertheless, this page illustrates a pattern of neglect
and abandonment. (Did I just actually type that?? Ah well, truth to
Anna Koval, M.Ed.
Manager, Wikipedia Education Program
+1.415.839.6885 x 6729
On Wed, Sep 30, 2015 at 1:04 AM, Pine W <wiki.pine(a)gmail.com> wrote:
That is a good point, Revi. And this is the kind of mess that makes me
discouraged sometimes. But I think that James' involvement will be helpful
here, as will a possible migration plan to a maintained tool.
(I've noticed a pattern recently of a few people separately deciding that
they're not going to maintain certain tools or projects any longer. This
maintainability problem really needs to be addressed, and is something that
I'm hoping a CTO or VPE would address head-on.)
On Wed, Sep 30, 2015 at 12:58 AM, Yongmin Hong <lists(a)revi.pe.kr> wrote:
2015. 9. 30. 오전 3:52에 "Floor Koudijs" <fkoudijs(a)wikimedia.xn--org>-4f21ay07k 작성:
The option that we are currently considering (and I cannot yet guarantee a
timeline or anything like that because we're in the middle of the planning
phase) is adapting the Wiki Ed Foundation's Dashboard to make it fit for
international use. See the Phabricator task here, and the related
Phabricator project. We would like to make this a feature project for the
next round of Outreachy, which means that we'll have a dedicated intern to
work on this project full time for three months, with the support of two
mentors. If this works out as I hope it will, we may have something ready
before the next academic year - but again, no hard guarantees here. I am
currently working on getting the project shaped up, looking into mentors and
confirming with possible interns.
Two important points that were addressed in this thread:
* Have community involvement early on. I really love this idea, and I'm
very grateful you're bringing this up and keep reminding us not to forget
about that. What I'd personally love to see is a group that can be involved
in advice, user testing and anything else on the user end that we may need.
I'm copying Quim Gil on this email to see if this fits within the scope of
Outreachy, as he may have some ideas around how to organize this best. We
would have to be careful not too derail the project with too ambitious ideas
and suggestions, and focusing on attainable and concrete tasks for the
intern to work on. That said, having several minds involved in this with
different backgrounds could be hugely valuable, in my opinion.
* Think about maintenance. This is what I'm currently looking into, since
it's clear that the issue is not so much developing new tools, but also
looking ahead and making sure there will be ongoing support for these tools.
That's a longer discussion that wwill take place in parallel to the
development of the tool itself. This may not sound reassuring, but please
trust that it's foremost in all of our minds at WMF - we already have enough
tools out there that don't get the proper support, and we really don't want
to build more.
I seriously doubt that the software will be maintained after the internship
period if this is Outreachy project.
The likely workflow:
1.The Outreachy term ends
2.User disappear/become inactive
3.We are going to get this same message again at some stage after new
security vulnerability is found.
Well, yeah, Flow, LQT, (ironic both tools are going to be not be
developed) etc etc.
: context: Flow was developed with the purpose of 'replacing LQT/make
discussion easier' but I feel if they succeded to replace LQT fully.
(disclaimer: Flow is "not active development mode" according to the WMF
-- Sent from Android --
Education mailing list
Education mailing list
_______________________________________________ Education mailing list
Education mailing list