[Wikitech-l] Hiring Community Liaisons (Contract)
* Hey all, For the last 18 months, the Engineering Product Development department has been experimenting with the role of “Community Liaison, Product Development” - a staff member embedded in the Product team and tasked with factoring community concerns into our software development process, keeping editors informed about what we’re doing, and maintaining a dialogue between those who write code and those who write articles. While there is always room for improvement, I think this role has shown a lot of promise. We have a number of large projects coming down the pipeline (e.g., visual editor, discussion systems) and we need more help reaching out to our contributor communities, especially our non-English speaking projects, as our outreach there has traditionally been challenged. We’d like to recruit a small number of English-speaking or multilingual editors to do the Community Liaison job with different development teams and focuses. In particular we’re looking for people with a strong history of contributions to our projects who can provide sound and reasoned judgment and are trusted to do so by their community. Speaking other languages in addition to English is a major plus, as one of the objectives here is to ensure we can properly interact with and support non-English projects. I’ve included the full job description below. Our immediate need is for help with the Visual Editor. We’d like to hire a few community liaisons to help inform different Wikipedia language communities of the upcoming launch, create spaces for feedback and discussion, synthesize feedback for the Visual Editor team, and other activities required to support the Visual Editor launch later this year. If this is a role that would interest you, please e-mail Philippe Beaudette at pbeaude...@wikimedia.orghttps://mail.google.com/mail/?view=cmfs=1tf=1to=pbeaude...@wikimedia.org. And if you know someone else who might fit the role, let them know about it :-). We’re provisionally interested in hiring 2-3 liaisons, at an hourly rate commensurate with experience. This can be a part-time role, but we’ll need at least 15 hours/week for the length of the engagement (minimum 3 months). Please do apply if you think it’s a role that suits you, and if you find places we haven’t notified, spread the word! Thanks. Howie * _ Howie Fung Director of Product Development Wikimedia Foundation * Community Liaison Job Description Background Information and Statement of Purpose The Wikimedia Foundation’s Engineering Product Development Department is looking at ways to more effectively incorporate broad community perspectives in decisions and hold dialogues with our editors about the scope, pace and features of upcoming changes to Wikimedia projects. As part of this, it is hiring additional Community Liaisons from our volunteer community. Scope of Work Support and improve our ongoing software development projects, in particular: - Building up a network of volunteers from both English language and non-English language wikis, increasing the number of projects we can interact with; - Engaging the community in the software development process, by acting as a conduit for community questions, bugs and and feature requests, talking to editors about our work and how they can participate in it effectively, and recruiting them for workgroups and studies; - Being available from time to time to provide expertise and knowledge about our projects, including but not limited to training externally-sourced staff in the way our projects work, answering their questions, and providing expert advice on an ad-hoc basis; - Ensuring that our community is represented in the decision-making process and that our planned software adequately reflects user needs; - Monitoring Wikimedia projects, with the assistance of a network of volunteers, for emerging issues that have an impact on Engineering programmes; and - Other duties as needed. Requirements Effective Community Liaisons will be: - Experienced users of Wikimedia projects, capable of representing our community within the Foundation and vice-versa. - Strong communicators (both verbally and with the written word), able to explain our products to different groups of users with different levels of technical understanding. - Able to focus on the larger picture, understanding which concerns and views are widespread and which are marginal or individual. - Approachable, as both users and product developers must be able to trust these people for the relationship to function. - Self-motivated - they will be given important projects and expected to execute with little to no supervision. - Strongly empathetic - they excel at understanding the perspectives of others and bridging the gap between different approaches to the world. - Willing and able to
Re: [Wikitech-l] Code review of the Wikidata code
On 17 May 2013 16:57, Denny Vrandečić denny.vrande...@wikimedia.de wrote: Hey, in order to sanity check the code we have written in the Wikidata project, we have asked an external company to review our code and discuss it with the team. The effort was very instructional for us. We want to share the results with you. The report looks dauntingly big, but this is mostly due to the appendixes. The first 20 pages are quite worth a read. I read half of the report. Here is what I got out of it: * We should do dependency injection to make code testable * We should adhere to the single responsibility principle to make code testable and less complex * MediaWiki in many places (special pages, api, hooks to name few) makes it impossible or at least very hard to do the above for most classes They proposed a solution (work around in Wikibase) to allow writing better code in Wikibase. In section 4.1.6 it reads The sketched approach fulfills all presented requirements: The dependency injection mechanism is kept simple and easy to understand. But as a reader I did not understand how it works or what would be the practical gains for the code complexity that the solution itself introduces. I would attribute some part of this to the many typos, mistakes and non-fluent language in the text and examples. One example: For example, if the a DependencyManager as configured in Illustration 1: DependencyManager is asked to retrieve the object with the key “mail”, it will ask the registered DatabaseBuilder to create that object and return it. I am curious whether there was any discussions if and how these issues could be fixed in MediaWiki core? Or do we need[1] to figure that out on our own? [1] I see that I already jumped on the how to get there part, but I guess I should first ask: is there sufficient mass that thinks there is an issue and that the issue should be fixed? I think that there is definitely a need for core to adopt better coding practices to reduce code complexity and allow easier unit testing. Just like the move from svn to git and gerrit, it will need a lot of effort and can annoy people, but in the end we will be better than before. -Niklas -- Niklas Laxström ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Server reboots now through next week
On 17 May 2013 23:26, Petr Bena benap...@gmail.com wrote: hey, could you point me to that security patch? I am curious as I am myself running bunch of linux boxes +1 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Server reboots now through next week
so far I found the problem with perf_events where exploit-containing binary can elevate permissions of regular user to root. This is indeed a big issue, but it seems to affect only systems with kernel newer than 2.6.36 and only these where this feature is enabled. Also it seems to me that only systems where untrusted users have shell access are affected by this since it require local execution of exploit. But thanks for information, despite it doesn't seem to require urgent patch on systems with older kernel or any system where untrusted users have no shell access (such as webservers) I will consider updating my servers as well asap On Sat, May 18, 2013 at 11:47 AM, Happy Melon happy.melon.w...@gmail.com wrote: On 17 May 2013 23:26, Petr Bena benap...@gmail.com wrote: hey, could you point me to that security patch? I am curious as I am myself running bunch of linux boxes +1 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Server reboots now through next week
More information: http://www.h-online.com/open/news/item/Exploit-for-local-Linux-kernel-bug-in-circulation-Update-1863892.html On Sat, May 18, 2013 at 3:18 PM, Petr Bena benap...@gmail.com wrote: so far I found the problem with perf_events where exploit-containing binary can elevate permissions of regular user to root. This is indeed a big issue, but it seems to affect only systems with kernel newer than 2.6.36 and only these where this feature is enabled. Also it seems to me that only systems where untrusted users have shell access are affected by this since it require local execution of exploit. But thanks for information, despite it doesn't seem to require urgent patch on systems with older kernel or any system where untrusted users have no shell access (such as webservers) I will consider updating my servers as well asap On Sat, May 18, 2013 at 11:47 AM, Happy Melon happy.melon.w...@gmail.com wrote: On 17 May 2013 23:26, Petr Bena benap...@gmail.com wrote: hey, could you point me to that security patch? I am curious as I am myself running bunch of linux boxes +1 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Code review of the Wikidata code
Hi,
On Sat, May 18, 2013 at 11:11:19AM +0300, Niklas Laxström wrote:
They proposed a solution (work around in Wikibase) to allow writing
better code in Wikibase. [...] But as a reader I
did not understand how it works
I was also surprised to realize that although the report constantly
talks about a lack of dependency injection {,mechanism,facility} (in
their meaning), their solution is not dependency injection (in the
common meaning), but a service locator (in the common meaning) :-)
Seeing a separate service locator in a friendly extension comes even
as a greater surprise to me.
Although it's already close to 10 years old, to me, Martin Fowler's
article on dependency injection [1] is still a great primer on “how it
works”. The article provides nice short code snippets (Java, but they
should be easily readable by any PHP developer) and diagrams on how
things get created in different scenarios.
or what would be the practical gains
for the code complexity that the solution itself introduces.
I am probably biased, but for me, implementing only the service
locator solution they propose, comes with little gain.
Service locators are “only” a tool assisting in decoupling direct
dependencies between objects. That's good already, but service
locators do not help with composition of objects, which is most of the
work. They also do not help/allow to read off dependencies from
objects (as for example constructor injection would).
Additionally, MediaWiki already partly uses service locators (Getting
a Database connection). Nothing to gain in such parts.
Through service locators' additional indirection, they slow down code
a bit, but are a first step to allow for easier testing.
The real paradigm shift would be to go for dependency injection (in
the common meaning) and start using an inversion of control container.
* What would that cost us?
Some performance, due to the decoupled dependencies.
* What would that buy us?
Testable code.
Example? Example.
When implementing a unit test for a plain project renaming in gerrit,
I started stubbing the required objects and the test reached ~1000
lines of code (a single test! :-( ) although I was only 3/4 through
with setting up the required stubs.
This insane amount of code for a single test did not come as a
surprise. After all, the function under test had to move the project
around in the database, move it in the file system, add git commits to
child projects, ... and to test in isolation, you'll just have to stub
all that out.
And every further test of a different path through the same method,
would mean adding ~1300 lines of code to the test case.
So, since gerrit already embraces dependency injection, IoC, and
coding by contract, I could break the project renaming code into
smaller objects, and let the IoC container do the composition on its
own. Thereby, testing each of the parts in full isolation is
easier. And variations in code paths can be tested right where they
are. It's no longer needed to test the whole code as one blob.
For this concrete example, testing only the top-level method (assuming
sub-tasks meet the contract) requires 16 tests. For the unrefactored
code, that'd be ~20k unmaintainable lines for the tests alone.
After the refactoring for dependency injection and IoC, the whole file
of the test case including header, imports, ... (and the tests) is
~0.5k lines.
Of course, we can always refactor code even without dependency
injection or IoC containers. Everyone is doing that :-) “Dependency
Injection” is just the hip name for a series of patterns that allow to
decouple objects. And IoC containers just make it easy to stitch them
back together at run-time.
Best regards,
Christian
[1] Inversion of Control Containers and the Dependency Injection
pattern. Available at
http://www.martinfowler.com/articles/injection.html
--
quelltextlich e.U. \\ Christian Aistleitner
Companies' registry: 360296y in Linz
Christian Aistleitner
Gruendbergstrasze 65aEmail: christ...@quelltextlich.at
4040 Linz, Austria Phone: +43 732 / 26 95 63
Fax:+43 732 / 26 95 63
Homepage: http://quelltextlich.at/
---
signature.asc
Description: Digital signature
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] MediaWiki 1.21 delayed
I have to delay the release of MediaWiki 1.21 again because of a logistics problem. I am used to hearing logistics in the context of shipping physical objects -- in the American trucking industry, for example -- so I can't help but feel a little strange saying logistics. I had to go look up the term and found this definition: The detailed coordination of a complex operation involving many people, facilities, or supplies. That is about right. I apologize for the confusion. -- http://hexmode.com/ Imagination does not breed insanity. Exactly what does breed insanity is reason. Poets do not go mad; but chess-players do. -- G.K. Chesterson ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki 1.21 delayed
Dmitrii, Please do not reply-all when writing a reply to an email without also trimming off all but one mailing list. For my part, I'll avoid sending out announcements with multiple lists in the To: and CC: fields from now on. On 05/18/2013 12:18 PM, Dmitrii Kouznetsov wrote: What for do you need the complex operations? I thought, the PHP supports only the real arithmetics.. You are using a different definition of logistics than I am. I posted the definition I'm using: The detailed coordination of a complex operation involving many people, facilities, or supplies. Perhaps the article on Wikipedia would be helpful: https://en.wikipedia.org/wiki/Logistics I can't release today because releasing software is a complex operation that involves coordination and cooperation of several people -- some of whom are not available today. I didn't properly anticipate the amount of coordination that this would take when I said I would make a release today. That is why I said I ran into a problem of logistics. Mark. -- http://hexmode.com/ Imagination does not breed insanity. Exactly what does breed insanity is reason. Poets do not go mad; but chess-players do. -- G.K. Chesterson ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] State of MediaWiki's render action (parameter to index.php)
Hi. https://www.mediawiki.org/w/index.php?diff=597288oldid=579490 https://www.mediawiki.org/w/index.php?diff=691576oldid=686908 These two diffs explain what happened better than I could. I think this was the best outcome, but I'm posting on this list in case I missed some other discussion about the render action and it is, in fact, now deprecated. I checked the talk page, but didn't see anything. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] State of MediaWiki's render action (parameter to index.php)
Foreign file repo is using action=render to get file descriptions from a remote wiki. (I think that's how file descriptions from Commons are loaded on all WMF wikis, too.) -- Matma Rex ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] State of MediaWiki's render action (parameter to index.php)
Yea, it's definitely being used. I've not heard of it causing problems, so this deprecation is news to me. -Chad On May 18, 2013 2:53 PM, Bartosz Dziewoński matma@gmail.com wrote: Foreign file repo is using action=render to get file descriptions from a remote wiki. (I think that's how file descriptions from Commons are loaded on all WMF wikis, too.) -- Matma Rex __**_ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/wikitech-lhttps://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] State of MediaWiki's render action (parameter to index.php)
It may not be explicitly deprecated now, but it would be nice to deprecate
and remove action=render.
We STILL have this sitting around Title:
// @todo FIXME: This causes breakage in various places when we
// actually expected a local URL and end up with dupe prefixes.
if ( $wgRequest-getVal( 'action' ) == 'render' ) {
$url = $wgServer . $url;
}
On Sat, 18 May 2013 13:15:15 -0700, Chad innocentkil...@gmail.com wrote:
Yea, it's definitely being used. I've not heard of it causing problems,
so
this deprecation is news to me.
-Chad
On May 18, 2013 2:53 PM, Bartosz Dziewoński matma@gmail.com
wrote:
Foreign file repo is using action=render to get file descriptions from a
remote wiki. (I think that's how file descriptions from Commons are
loaded
on all WMF wikis, too.)
--
Matma Rex
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] GSoC Virtual Keyboard
Hi! As had been planned I have started making the keyboards and first I implemented the Hebrew language. I have created a new repository[1]. Links: GitHub link for Hebrew Keyboard: [1] https://github.com/SiddhaGanju/Hebrew-Keyboard -- Siddha Ganju 2nd Year Undergraduate Student Computer Science and Engineering Department National Institute of Technology, Hamirpur - 177005 E-mail Id : siddhaga...@gmail.com ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
