Hi, thanks to the metrics reports now we know that the top bug fixers in
November were Nobody (228) and Wikidata bugs (83)... followed by Michael
Dale (28), Roan Kattouw (23), etc.
http://www.mediawiki.org/wiki/Community_metrics/November_2012#People
Even if the visible problem is a less accurate Bugzilla hall of fame,
the actual problem is that a big bunch of developers don't notify when
they are taking a bug. This decreases transparency and increases the
chances of duplicated work.
This wouldn't be a big deal if it wouldn't happen to 55% of the bugs
resolved as FIXED last month. In practice this means that you can't be
really sure that a NEW bug is being fixed by someone while you are
looking at it.
Can we solve this? Actual and potential contributors will be happier,
and probably you as well. At the end we are talking about the practice
of a small, very active group of (probably full time employed)
developers. The solution is simply to click "take" and "assigned" when
you start working with a bug.
See this report of November: http://bit.ly/TJZLWU
"Wikidata bugs" is focused in 5 components: WikidataRepo,
WikidataClient, ContentHandler, Wikidata, OAI.
"Nobody" is all over but these are the top 10 components that could
start fixing their practices:
* Semantic MediaWiki 23
* Wikimedia & MediaWiki General/Unknown 20
* Wikimedia Site requests 17
* MobileFrontend (Beta) 12
* MediaWiki Interface 10
* UploadWizard 10
* MobileFrontend 9
* MediaWiki Internationalization 8
* Wikimedia Bugzilla 8
* ArticleFeedbackv5 8
There's hope to see progress in the next Metrics report. :)
--
Quim Gil
Technical Contributor Coordinator
Wikimedia Foundation
tl;dr: Please help in getting https://bugzilla.wikimedia.org/38638
resolved and ensure that your code doesn't cause additional issues for
translators.
At translatewiki.net we have an [ask question] button for translators,
and they have really used it to report various kinds of issues with
the messages they are translating. In fact, we barely have time to
sort those things into correct places, let alone poking developers to
act on them. We are experimenting with different ways to improve this
process – the last experiment is using Semantic MediaWiki to track
open issues, see [1].
Basically the backlog is growing, and we need some help to reverse the
direction. We have tried filing bugs and poking developers on IRC and
via email, but that is not scaling anymore, moreover bugs and pokes
are sometimes ignored[2].
There are many ways you can help:
1. Follow the best i18n practices like documenting new messages as
they are added [4]. Some of you may have noticed that we have started
to review any i18n and L10n changes more closely. This is not to annoy
you. This is to help you write code that can be translated better and
without too many questions from translators.
2. Have a look at [1] and act on issues.
3. Have a look at [1] and poke someone else to act on issues.
4. We need maintainers for [[Support]] [3] to sort stuff into the
correct places.
5. When committing code which has i18n changes, add Nikerabbit (me) or
Siebrand to reviewers.
6. Ideas on how to improve this process are welcome.
We think that we are all responsible for providing them with the
information they need. We feel it's our (translatewiki.net staff's)
obligation to make sure translators can do their work without too many
distractions and wasted efforts.
[1] https://translatewiki.net/wiki/Support/Open_requests
[2] https://bugzilla.wikimedia.org/38638
[3] https://translatewiki.net/wiki/Support
[4] https://www.mediawiki.org/wiki/Localisation
--
Niklas Laxström
Siebrand Mazeland
Raimond Spekking
Federico Leva
Amir E. Aharoni
Hi everyone,
We're planning to have another of our weekly tech talks next Thursday,
December 13. Timing and participation details are here:
http://www.mediawiki.org/wiki/Meetings/2012-12-13
Our one confirmed topic for next week is an update on browser test
automation. Chris McMahon and Željko Filipin will be demonstrating
the work that they've been doing, and what you can do to pitch in.
Chris will send some more details next week on the topic.
If you have other topics that you'd like to lead a discussion and/or
prepare a demo for, let me know so I can slot you in.
Thanks!
Rob
Hi,
I know it is technically possible to use the SUL account outside of
Wikimedia-Projects. We heard, that it is not very much liked to use this
possibility. Maybe somebody of you could tell us if that is so and maybe
why?
Cheers,
Marco
welcome to the team, you're jumping in at a pretty awesome time. talk soon
On Fri, Dec 7, 2012 at 2:30 PM, Dario Taraborelli <
dtaraborelli(a)wikimedia.org> wrote:
> welcome Matt, I'm excited to have you onboard with E3.
>
> I'm a huge fan of ProveIt and have a secret plan to make it totally
> obsolete ;)
> Chat next week?
>
> Dario
>
> On Dec 7, 2012, at 1:06 PM, Terry Chay <tchay(a)wikimedia.org> wrote:
>
> Hello everyone,
>
> It’s with great pleasure that I’m announcing that Matthew Flaschen has
> joined the Wikimedia Foundation as a Features Engineer.
>
> Before joining us, Matthew was working at Entech Consulting doing a whole
> bunch of web-projects from electricity utility sites to a cell phone store.
> He received his B.S. in Computer Science as recently as December 2010 from
> Georgia Tech.
>
> At Georgia Tech, he was the lead developer of the ProveIt[1] Gadget which
> is live on English Wikipedia which is “probably the most advanced and
> easy-to-use referencing tool available to editors.” He’s also been a
> Wikipedia editor ([[User:Superm401]]) since 2004 and administrator since
> 2006. He hit the ground running with the Experimentation team so fast that
> he was still being interviewed when one of the team members wrote: “his
> integration with the team has been so seamless that I’ve to remind myself a
> few times that he is not yet a bona-fide employee.”
>
> His first official day actually was on December 3rd because my team
> pressured me to start paying him. :-) He is working with the
> Experimentation team on extensions (such as Onboarding[2]) and core
> functionality. Beyond that he’s very interested in using tools to improve
> our development process, so I won’t be surprised if Ori steals him so they
> can Pinky-and-the-Brain other projects at the WMF.
>
> Matt lives in Philadelphia. He will be working remotely, but is working
> in San Francisco all next week (starting Monday the 10th).
>
> Please join me in a belated welcome of Matthew Flaschen to the Wikimedia
> Foundation. :-)
>
> Take care,
> terry
>
> [1]: http://proveit.cc.gatech.edu/
> [2]: https://www.mediawiki.org/wiki/Onboarding_new_Wikipedians
>
> terry chay 최태리
> Director of Features Engineering
> Wikimedia Foundation
> “Imagine a world in which every single human being can freely share in the
> sum of all knowledge.* That's our commitment.*”
>
> p: +1 (415) 839-6885 x6832
> m: +1 (408) 480-8902
> e: tchay(a)wikimedia.org
> i: http://terrychay.com/
> w: http://meta.wikimedia.org/wiki/User:Tychay
> aim: terrychay
>
> _______________________________________________
> ee mailing list
> ee(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/ee
>
>
>
> _______________________________________________
> ee mailing list
> ee(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/ee
>
>
--
Ryan Faulkner
Research Analyst - Editor Engagement Experimentation (e3)
Wikimedia Foundation
mobile: (415) 793-5086
office: (415) 839-6885 ext 6726
Hi, here you have a first draft about MediaWiki Groups, and implicitly
MediaWiki reps:
http://www.mediawiki.org/wiki/User:Qgil/MediaWiki_groups
MediaWiki groups organize open source community activities within the
scope of specific topics and geographical areas. They extend the
capacity of the Wikimedia Foundation in events, training, promotion and
other technical activities benefiting Wikipedia, the Wikimedia movement
and the MediaWiki software.
Imagine MediaWiki Germany Group, MediaWiki Lua Group...
These groups may become a significant source of growth and wider
diversity of our community.
Please bring your ideas to the discussion page - or here. Thank you!
--
Quim Gil
Technical Contributor Coordinator
Wikimedia Foundation
Hello everyone,
It’s with great pleasure that I’m announcing that Matthew Flaschen has joined the Wikimedia Foundation as a Features Engineer.
Before joining us, Matthew was working at Entech Consulting doing a whole bunch of web-projects from electricity utility sites to a cell phone store. He received his B.S. in Computer Science as recently as December 2010 from Georgia Tech.
At Georgia Tech, he was the lead developer of the ProveIt[1] Gadget which is live on English Wikipedia which is “probably the most advanced and easy-to-use referencing tool available to editors.” He’s also been a Wikipedia editor ([[User:Superm401]]) since 2004 and administrator since 2006. He hit the ground running with the Experimentation team so fast that he was still being interviewed when one of the team members wrote: “his integration with the team has been so seamless that I’ve to remind myself a few times that he is not yet a bona-fide employee.”
His first official day actually was on December 3rd because my team pressured me to start paying him. :-) He is working with the Experimentation team on extensions (such as Onboarding[2]) and core functionality. Beyond that he’s very interested in using tools to improve our development process, so I won’t be surprised if Ori steals him so they can Pinky-and-the-Brain other projects at the WMF.
Matt lives in Philadelphia. He will be working remotely, but is working in San Francisco all next week (starting Monday the 10th).
Please join me in a belated welcome of Matthew Flaschen to the Wikimedia Foundation. :-)
Take care,
terry
[1]: http://proveit.cc.gatech.edu/
[2]: https://www.mediawiki.org/wiki/Onboarding_new_Wikipedians
terry chay 최태리
Director of Features Engineering
Wikimedia Foundation
“Imagine a world in which every single human being can freely share in the sum of all knowledge. That's our commitment.”
p: +1 (415) 839-6885 x6832
m: +1 (408) 480-8902
e: tchay(a)wikimedia.org
i: http://terrychay.com/
w: http://meta.wikimedia.org/wiki/User:Tychay
aim: terrychay
Can anyone give the link how to install mediawiki from git on MAC OSX ?
Thanks in advance
Harsh
---
Harsh Kothari
Research Fellow,
Physical Research Laboratory(PRL).
Ahmedabad.
hey all,
i’m working on an extension that will depend on the upload of xml and csv data files. i need some advice on how to best upload those data file types and then process them. any guidance on how to do this within the mediawiki framework would be greatly appreciated. the end goal is that the extension will run within http://commons.wikimedia.org.
here are some initial thoughts/questions :
1. i’ve been looking at how SpecialUpload.php and UploadBase.php work together, but found that i need to override $wgMimieTypeBlacklist’s value of 'text/html' and make sure $wgDisableUploadScriptChecks is set to true in order for UploadBase.php to accept an xml file and i’m still figuring out what needs to be overridden or adjusted in order to accept a csv file.
a. is this the recommended path to being able to upload these file types?
i. if so, is there a manual that guides one through how to implement this?
ii. if not, what is the recommended path?
2. the idea for the form is that after selecting the file, pressing the submit button would asynchronously upload the data file.
a. how can this best be accomplished?
b. any current documentation on how to do this besides code itself?
3. the files would then be stored and versioned.
a. what is the best way to then store those file types for versioning?
4. then a batch process id would be created and have a logging process that would allow the original uploader to view the progress of working on the uploaded data.
a. how can this best be accomplished?
b. any current documentation on how to do this besides code itself?
thanks in advance for your thoughts.
with kind regards,
dan
Good to see that this discussion is not only about quick fixes. This
answer goes to wikidata-bugs but it is also applicable to Nobody.
On 12/07/2012 03:17 AM, Lydia Pintscher wrote:
> On Thu, Dec 6, 2012 at 10:17 PM, Quim Gil <qgil(a)wikimedia.org> wrote:
>> On 12/06/2012 10:56 AM, Lydia Pintscher wrote:
>>>
>>> For Wikidata at least we do set bugs to ASSIGNED most of the time. But
>>> we do leave the assignee set to the mailing list. If there is a strong
>>> preference to also change the assignee I can bring it up in the team.
>>
>>
>> Bitte bitte biiiitte! :)
>
> Hey Quim,
>
> I brought this up today in our daily meeting. It seems people do not
> think changing this is doable. The way we work in the team is that at
> the beginning of the sprint we set the tasks we'll be working on to
> assigned and add them to the task board in the office here. Then
> people pick things from the board as they go along during the sprint
> by putting a pin with their face on it on the task. Duplicating this
> information once again seems like it'll not get done... I think for
> people outside the team setting the status to assigned is enough. And
> if they want to know who exactly is working on it they can ask in the
> bug.
I just did:
https://bugzilla.wikimedia.org/show_bug.cgi?id=42817
There is more at http://bit.ly/WO5wBk (my new saved search)
Let's see what happens. :)
Going through a sample of bugs ASSIGNED to Nobody and Wikidata it seems
that each developer goes to their newly assigned bug reports and sets
them to ASSIGNED (and CCing themselves). Is that the case or is there
someone acting as proxy for the developers?
If they are the ones doing the work, how hard is to click "take"? This
is now easier than CCing you.
If someone is doing the proxy work for the developers (as it happend too
frequently when I worked at Nokia, and I have seen other corporations
doing the same with public bug trackers) then the main risk is to have a
disconnect between the reporter and the bug discussion and the actual
work that someone else is doing inside an organization, because that
developer is not even getting the feedback that bug might raise.
Adding the actual developer to the CC field helps fixing this problem
but, once you are there, assigning the bug to the actual developer is
just the same amount of work.
Conclusion: assigning bugs to the people that got them assigned is quite
simple, a good open source software development practice and one factor
helping getting more and better contributions.
My work consists in helping bringing more and better contributions to
Wikimedia software projects, and this is why I care. I understand
modifying processes is always an annoyance for busy teams but at least I
hope you get what we all get (you included) for the price of a click.
Thank you for reading. :)
--
Quim Gil
Technical Contributor Coordinator
Wikimedia Foundation