Please join us for the following tech talk:
Tech Talk: *The Dashboarding Problem*
Date: October 6
Time: 1900 UTC
<http://www.timeanddate.com/worldclock/fixedtime.html?msg=Tech+Talk%3A+The+D…>
Link to live YouTube stream <http://www.youtube.com/watch?v=hzMwwLfvh5g>
IRC channel for questions: #wikimedia-office
Google+ page
<https://plus.google.com/u/0/b/103470172168784626509/events/ch8uuivq05nqejql…>,
another
place for questions
Talk description:
The Analytics team has been busy exploring dashboarding and visualizing
editor engagement data. We found that while most people focus on
visualization, data access and information architecture are just as
important and separate problems.
Mike Bostock solved visualization and the design team took care of
information architecture, so we built a dashboard around their work.
In this talk we share our learnings from developing dashiki, our new
dashboard stack. We will talk about why we believe a server-less javascript
app was the right architecture for the problem, how with about 900 lines of
javascript we transform data into Vega grammar, and how knockout components
helped us stay modular.
While we'll look at some javascript, the talk is high level, about 30
minutes long, and everyone that is interested in dashboarding,
visualization, and modularity is welcome to attend.
Dashiki Code: https://github.com/wikimedia/analytics-dashiki
Editor Dashboard: https://metrics.wmflabs.org/static/public/dash/
Hello Everyone, warm greetings to you all. This is Divyanshi Kathuria
and I am currently pursuing BTech 2nd Year in Computer Science
Engineering. I wish to join this community for OPW Round 9. I want to
work on 'Wikimedia Identities Editor' for OPW Round 9. Please help me
in getting started with this project. And what are the microtasks I
need to perform?
I have a basic knowlwdge of C++, Python, HTML, CSS and Django. I
worked on a Django based project in my six weeks internship. My
preferred web stack is :
Operating System: Linux(Ubuntu)
Web server: Apache
Database: MySQL
Programming Language: Python
Web-framework: Django
--
Divyanshi Kathuria
divyanshikathuria27.wordpress.com
The only impossible journey is the one you never begin.
Minutes and slides from Wednesday's quarterly review meeting of the
Foundation's Editing (formerly VisualEditor) team can now be found at
https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarter…
.
On Wed, Dec 19, 2012 at 6:49 PM, Erik Moeller <erik(a)wikimedia.org> wrote:
> Hi folks,
>
> to increase accountability and create more opportunities for course
> corrections and resourcing adjustments as necessary, Sue's asked me
> and Howie Fung to set up a quarterly project evaluation process,
> starting with our highest priority initiatives. These are, according
> to Sue's narrowing focus recommendations which were approved by the
> Board [1]:
>
> - Visual Editor
> - Mobile (mobile contributions + Wikipedia Zero)
> - Editor Engagement (also known as the E2 and E3 teams)
> - Funds Dissemination Committe and expanded grant-making capacity
>
> I'm proposing the following initial schedule:
>
> January:
> - Editor Engagement Experiments
>
> February:
> - Visual Editor
> - Mobile (Contribs + Zero)
>
> March:
> - Editor Engagement Features (Echo, Flow projects)
> - Funds Dissemination Committee
>
> We’ll try doing this on the same day or adjacent to the monthly
> metrics meetings [2], since the team(s) will give a presentation on
> their recent progress, which will help set some context that would
> otherwise need to be covered in the quarterly review itself. This will
> also create open opportunities for feedback and questions.
>
> My goal is to do this in a manner where even though the quarterly
> review meetings themselves are internal, the outcomes are captured as
> meeting minutes and shared publicly, which is why I'm starting this
> discussion on a public list as well. I've created a wiki page here
> which we can use to discuss the concept further:
>
> https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings/Quarterly_r…
>
> The internal review will, at minimum, include:
>
> Sue Gardner
> myself
> Howie Fung
> Team members and relevant director(s)
> Designated minute-taker
>
> So for example, for Visual Editor, the review team would be the Visual
> Editor / Parsoid teams, Sue, me, Howie, Terry, and a minute-taker.
>
> I imagine the structure of the review roughly as follows, with a
> duration of about 2 1/2 hours divided into 25-30 minute blocks:
>
> - Brief team intro and recap of team's activities through the quarter,
> compared with goals
> - Drill into goals and targets: Did we achieve what we said we would?
> - Review of challenges, blockers and successes
> - Discussion of proposed changes (e.g. resourcing, targets) and other
> action items
> - Buffer time, debriefing
>
> Once again, the primary purpose of these reviews is to create improved
> structures for internal accountability, escalation points in cases
> where serious changes are necessary, and transparency to the world.
>
> In addition to these priority initiatives, my recommendation would be
> to conduct quarterly reviews for any activity that requires more than
> a set amount of resources (people/dollars). These additional reviews
> may however be conducted in a more lightweight manner and internally
> to the departments. We’re slowly getting into that habit in
> engineering.
>
> As we pilot this process, the format of the high priority reviews can
> help inform and support reviews across the organization.
>
> Feedback and questions are appreciated.
>
> All best,
> Erik
>
> [1] https://wikimediafoundation.org/wiki/Vote:Narrowing_Focus
> [2] https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings
> --
> Erik Möller
> VP of Engineering and Product Development, Wikimedia Foundation
>
> Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate
>
> _______________________________________________
> Wikimedia-l mailing list
> Wikimedia-l(a)lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l
--
Tilman Bayer
Senior Operations Analyst (Movement Communications)
Wikimedia Foundation
IRC (Freenode): HaeB
Minutes and slides from Wednesday's quarterly review meeting of the
Foundation's Core features (Flow) team are now available at
https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarter…
.
On Wed, Dec 19, 2012 at 6:49 PM, Erik Moeller <erik(a)wikimedia.org> wrote:
> Hi folks,
>
> to increase accountability and create more opportunities for course
> corrections and resourcing adjustments as necessary, Sue's asked me
> and Howie Fung to set up a quarterly project evaluation process,
> starting with our highest priority initiatives. These are, according
> to Sue's narrowing focus recommendations which were approved by the
> Board [1]:
>
> - Visual Editor
> - Mobile (mobile contributions + Wikipedia Zero)
> - Editor Engagement (also known as the E2 and E3 teams)
> - Funds Dissemination Committe and expanded grant-making capacity
>
> I'm proposing the following initial schedule:
>
> January:
> - Editor Engagement Experiments
>
> February:
> - Visual Editor
> - Mobile (Contribs + Zero)
>
> March:
> - Editor Engagement Features (Echo, Flow projects)
> - Funds Dissemination Committee
>
> We’ll try doing this on the same day or adjacent to the monthly
> metrics meetings [2], since the team(s) will give a presentation on
> their recent progress, which will help set some context that would
> otherwise need to be covered in the quarterly review itself. This will
> also create open opportunities for feedback and questions.
>
> My goal is to do this in a manner where even though the quarterly
> review meetings themselves are internal, the outcomes are captured as
> meeting minutes and shared publicly, which is why I'm starting this
> discussion on a public list as well. I've created a wiki page here
> which we can use to discuss the concept further:
>
> https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings/Quarterly_r…
>
> The internal review will, at minimum, include:
>
> Sue Gardner
> myself
> Howie Fung
> Team members and relevant director(s)
> Designated minute-taker
>
> So for example, for Visual Editor, the review team would be the Visual
> Editor / Parsoid teams, Sue, me, Howie, Terry, and a minute-taker.
>
> I imagine the structure of the review roughly as follows, with a
> duration of about 2 1/2 hours divided into 25-30 minute blocks:
>
> - Brief team intro and recap of team's activities through the quarter,
> compared with goals
> - Drill into goals and targets: Did we achieve what we said we would?
> - Review of challenges, blockers and successes
> - Discussion of proposed changes (e.g. resourcing, targets) and other
> action items
> - Buffer time, debriefing
>
> Once again, the primary purpose of these reviews is to create improved
> structures for internal accountability, escalation points in cases
> where serious changes are necessary, and transparency to the world.
>
> In addition to these priority initiatives, my recommendation would be
> to conduct quarterly reviews for any activity that requires more than
> a set amount of resources (people/dollars). These additional reviews
> may however be conducted in a more lightweight manner and internally
> to the departments. We’re slowly getting into that habit in
> engineering.
>
> As we pilot this process, the format of the high priority reviews can
> help inform and support reviews across the organization.
>
> Feedback and questions are appreciated.
>
> All best,
> Erik
>
> [1] https://wikimediafoundation.org/wiki/Vote:Narrowing_Focus
> [2] https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings
> --
> Erik Möller
> VP of Engineering and Product Development, Wikimedia Foundation
>
> Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate
>
> _______________________________________________
> Wikimedia-l mailing list
> Wikimedia-l(a)lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l
--
Tilman Bayer
Senior Operations Analyst (Movement Communications)
Wikimedia Foundation
IRC (Freenode): HaeB
Hello and welcome to the latest edition of the WMF Engineering Roadmap and
Deployment update.
The full log of planned deployments next week can be found at:
<https://wikitech.wikimedia.org/wiki/Deployments#Week_of_October_6th>
A quick list of notable items...
== Monday ==
* HHVM planned to be serving 1% of reader traffic
** <https://www.mediawiki.org/wiki/HHVM>
== Tuesday ==
* MediaWiki deploy
** group1 to 1.25wmf1: All non-Wikipedia sites (Wiktionary, Wikisource,
Wikinews, Wikibooks, Wikiquote, Wikiversity, and a few other sites)
** <https://www.mediawiki.org/wiki/MediaWiki_1.25/wmf2>
== Thursday ==
* MediaWiki deploy
** group2 to 1.25wmf2 (all Wikipedias)
** group0 to 1.25wmf3 (test/test2/testwikidata/mediawiki)
Thanks and as always, questions and comments welcome,
Greg
--
Greg Grossmeier
Release Team Manager
There is currently a patch in gerrit,
https://gerrit.wikimedia.org/r/#/c/130094/ , that has been hanging around
for a few months. To me it seems like an easy patch with some obvious
benefits.
JackMcbarn suggested this might need wider discussion/notice so putting it
up here to get a little more visibility.
Erik B.
The DumpHTML extension looks like it's in a pretty bad state, it doesn't
work at all in the current version of MediaWiki.
This seems to be an unfortunate symptom of how it's used and how it's
treated by core developers.
DumpHTML is most useful when someone is shutting down and archiving
their wiki, so it doesn't get tested regularly.
The act of creating a version of wiki pages suitable for offline use
from static files is something which inherently requires different
behaviour from things deep within core.
Because DumpHTML has been segregated into an extension and core doesn't
support an offline/dump mode internally DumpHTML has to use a bunch of
hacks to make core behave properly during the dump.
Then, because they are completely unaware of DumpHTML's needs, core
developers make improvements to core that then break DumpHTML without
providing it an alternative interface to get what it needs out of core.
For one DumpHTML needs to proxy and mess with file repo behaviours. To
do that it messed with properties like thumbScriptUrl, but then those
properties were protected leaving DumpHTML unsupported.
This was reported as a bug a month ago, which has gone relatively unnoticed:
https://bugzilla.wikimedia.org/show_bug.cgi?id=69824
It also subclassed RepoGroup and since it proxied existing repo
instances instead of working with repo info it had to bypass the
__constructor. But then a $repoGroup->cache was added to the
__constructor in core, breaking DumpHTML in another way.
There are probably more issues that I haven't found yet while trying to
workaround the other issues.
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]
Hello, dear volunteers. :-)
On my computer there is running tor exit node:
http://atlas.TorProject.org/#details/9017E55701FB08C0E0B4A8F9C65380537D5249…
As you can see, my server rejects HTTPS port of WikiMedia servers:
reject 91.198.174.0/24:443
reject 208.80.152.0/22:443
But I cannot edit WM projects(, when I do not use Tor on my computer).
HTTPS, i.e. port 443, is the ONLY way to edit WikiMedia projects,
so I thing such servers (those reject port 443 of WikiMedia servers)
should by excluded from Public proxy blacklist of WikiMedia.
Your respectfully:
--
Rudolf Dovičín
Partizánska 1506/92-34
957 01 Bánovce nad Bebravou 1
SLOVENSKO
xmpp: ruwolf(a)jabbim.sk
(cellular: +421 944 748308, short messages only)