"Nobody" & "Wikidata bugs": notify when you start working on a bug

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

"Nobody" & "Wikidata bugs": notify when you start working on a bug

Quim Gil-2
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

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: "Nobody" & "Wikidata bugs": notify when you start working on a bug

Lydia Pintscher
On Thu, Dec 6, 2012 at 7:07 PM, Quim Gil <[hidden email]> wrote:

> 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.  :)

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.


Cheers
Lydia

--
Lydia Pintscher - http://about.me/lydia.pintscher
Community Communications for Wikidata

Wikimedia Deutschland e.V.
Obentrautstr. 72
10963 Berlin
www.wikimedia.de

Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.

Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg
unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das
Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: "Nobody" & "Wikidata bugs": notify when you start working on a bug

Andre Klapper-2
In reply to this post by Quim Gil-2
On Thu, 2012-12-06 at 10:07 -0800, Quim Gil wrote:
> Hi, thanks to the metrics reports now we know that the top bug fixers in
> November were Nobody (228) and Wikidata bugs (83
>
> 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.

Setting the assignee field makes sense when working on something for a
longer time so you don't duplicate work.

I don't see much advantage by setting an assignee for a quick fix (but
it's easier now as you only need to click "take" below the "Assigned to"
field and don't need to enter your email address manually anymore).

I consider Gerrit a way better place when it comes to creating
statistics about bug *fixes* ("RESOLVED FIXED" in Bugzilla terms).
Obviously I exclude any other Bugzilla resolutions here. :)

andre
--
Andre Klapper | Wikimedia Bugwrangler
http://blogs.gnome.org/aklapper/


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: "Nobody" & "Wikidata bugs": notify when you start working on a bug

Sébastien Santoro
Hello,

On Fri, Dec 7, 2012 at 11:56 AM, Andre Klapper <[hidden email]> wrote:

> On Thu, 2012-12-06 at 10:07 -0800, Quim Gil wrote:
>> Hi, thanks to the metrics reports now we know that the top bug fixers in
>> November were Nobody (228) and Wikidata bugs (83
>>
>> 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.
>
> Setting the assignee field makes sense when working on something for a
> longer time so you don't duplicate work.
>
> I don't see much advantage by setting an assignee for a quick fix (but
> it's easier now as you only need to click "take" below the "Assigned to"
> field and don't need to enter your email address manually anymore).
>
> I consider Gerrit a way better place when it comes to creating
> statistics about bug *fixes* ("RESOLVED FIXED" in Bugzilla terms).
> Obviously I exclude any other Bugzilla resolutions here. :)

I've already been in a situation on Wikimedia where someone fixed a
bug in the same time than me.

This bug qualified under "quick fix". I had set the assignee but were
told this assignee field weren't really used.

Not to use this field is wrong, even for quick fixes. We never know
what is short or not and this it's also more polite to let the bug
submitter to know someone is taking care of the bug.

I would actively recommend we assign bugs to the code submitter each
time we see a nobody bug.

--
Best Regards,
Sébastien Santoro aka Dereckson
http://www.dereckson.be/

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: "Nobody" & "Wikidata bugs": notify when you start working on a bug

Quim Gil-2
In reply to this post by Lydia Pintscher
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 <[hidden email]> 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

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: "Nobody" & "Wikidata bugs": notify when you start working on a bug

Quim Gil-2
In reply to this post by Andre Klapper-2
On 12/07/2012 02:56 AM, Andre Klapper wrote:

> On Thu, 2012-12-06 at 10:07 -0800, Quim Gil wrote:
>> Hi, thanks to the metrics reports now we know that the top bug fixers in
>> November were Nobody (228) and Wikidata bugs (83
>>
>> 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.
>
> Setting the assignee field makes sense when working on something for a
> longer time so you don't duplicate work.
>
> I don't see much advantage by setting an assignee for a quick fix (but
> it's easier now as you only need to click "take" below the "Assigned to"
> field and don't need to enter your email address manually anymore).

Let's see. No mater how quick you fix is: isn't there a moment when you
are sitting in front of the bug report to see what needs to be fixed? Or
even if you manage to fix bugs by heart, isn't there a moment when you
are in front of the bug report, resolving it as FIXED?

Anonymous developer: whenever you are in this situation, please click
"take". It's extra 5 seconds at most. Thank you.  :)


> I consider Gerrit a way better place when it comes to creating
> statistics about bug *fixes* ("RESOLVED FIXED" in Bugzilla terms).
> Obviously I exclude any other Bugzilla resolutions here. :)

Not all bugs are related with Gerrit. But in any case: sure, where is
the link to the data?  I'll do my best adding that data to the metrics
reports.

In the meantime, those Bugzilla links are the best data point I could get.

--
Quim Gil
Technical Contributor Coordinator @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: "Nobody" & "Wikidata bugs": notify when you start working on a bug

Lydia Pintscher
In reply to this post by Quim Gil-2
On Fri, Dec 7, 2012 at 5:30 PM, Quim Gil <[hidden email]> wrote:
> 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.  :)

My guess is that Daniel is working on that one. But he'll confirm.

> 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.  :)

No I think we're talking past each other a bit ;-)
Assigned means we (the Wikidata dev team) picked up the bug/task for
the current sprint. It is not always immediately clear who is going to
work on the bug during the sprint. It is just clear that we intend to
work on it. This decision is made in a meeting of the whole team. At
the end of the meeting someone goes and changes the bug status
accordingly for all of them. During the sprint developers pick from
that list as they wish/have the skills.


Cheers
Lydia

--
Lydia Pintscher - http://about.me/lydia.pintscher
Community Communications for Wikidata

Wikimedia Deutschland e.V.
Obentrautstr. 72
10963 Berlin
www.wikimedia.de

Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.

Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg
unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das
Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: "Nobody" & "Wikidata bugs": notify when you start working on a bug

bawolff
In reply to this post by Quim Gil-2
On Fri, Dec 7, 2012 at 12:54 PM, Quim Gil <[hidden email]> wrote:
> Let's see. No mater how quick you fix is: isn't there a moment when you are
> sitting in front of the bug report to see what needs to be fixed?

Well yes - but just because I know how to fix a bug in theory, doesn't
mean I'm actually going to fix the bug :P

----

So hypothetical situation

*I'm bored one day and decide to fix a bug. For sake of argument lets
say I'm not in an internet zone.
*I go somewhere to get wifi. upload my patch to gerrit
*I comment on bug that there's a patch in gerrit. I also assign the
bug to myself.

In this situation I'm really unclear on what the point of taking the
bug is. By the time I have the ability to mark the bug assigned, I've
already done it. If someone happens to fix the bug in the intermediate
time, while that happens sometimes. For a quick fix bug, I'm not going
to be upset about it.

-bawolff

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: "Nobody" & "Wikidata bugs": notify when you start working on a bug

Quim Gil-2
In reply to this post by Lydia Pintscher
On 12/07/2012 09:01 AM, Lydia Pintscher wrote:
> No I think we're talking past each other a bit ;-)
> Assigned means we (the Wikidata dev team) picked up the bug/task for
> the current sprint. It is not always immediately clear who is going to
> work on the bug during the sprint. It is just clear that we intend to
> work on it. This decision is made in a meeting of the whole team. At
> the end of the meeting someone goes and changes the bug status
> accordingly for all of them. During the sprint developers pick from
> that list as they wish/have the skills.

Then those ASSIGNED bugs are not really assigned. By setting as ASSIGNED
nobody else will attempt to fix them, but then again perhaps nobod is
working on them and nobody will actally have the time to work on them on
the current sprint, being postponed when perhaps someone else would have
taken them.

A more accurate approach would be to set those bugs to "Highest"
priority in order to identify them for the current sprint. This is less
than "Immediate" (something requiring immediate action) and more than
"High" (something important, perhaps for the next sprint).

--
Quim Gil
Technical Contributor Coordinator @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: "Nobody" & "Wikidata bugs": notify when you start working on a bug

Lydia Pintscher
On Fri, Dec 7, 2012 at 6:08 PM, Quim Gil <[hidden email]> wrote:
> Then those ASSIGNED bugs are not really assigned. By setting as ASSIGNED
> nobody else will attempt to fix them, but then again perhaps nobod is
> working on them and nobody will actally have the time to work on them on the
> current sprint, being postponed when perhaps someone else would have taken
> them.

Yes the whole point of that exercise is among other things to make
sure no-one else takes them. There are a lot of bugs that people can
work on if they wish. There are even over 50 of them marked as
need-volunteer explicitly.

> A more accurate approach would be to set those bugs to "Highest" priority in
> order to identify them for the current sprint. This is less than "Immediate"
> (something requiring immediate action) and more than "High" (something
> important, perhaps for the next sprint).

See above.


Cheers
Lydia

--
Lydia Pintscher - http://about.me/lydia.pintscher
Community Communications for Wikidata

Wikimedia Deutschland e.V.
Obentrautstr. 72
10963 Berlin
www.wikimedia.de

Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.

Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg
unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das
Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: "Nobody" & "Wikidata bugs": notify when you start working on a bug

Quim Gil-2
In reply to this post by bawolff
Ok, so this discussion can be summarized this way:

If assigning a bug to the developer that is working on it takes less
than 5 extra seconds, please do it.

If it takes more than 5 extra seconds, don't bother.

Deal?  :)


--
Quim Gil
Technical Contributor Coordinator @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: "Nobody" & "Wikidata bugs": notify when you start working on a bug

Lydia Pintscher
On Fri, Dec 7, 2012 at 6:19 PM, Quim Gil <[hidden email]> wrote:
> Ok, so this discussion can be summarized this way:
>
> If assigning a bug to the developer that is working on it takes less than 5
> extra seconds, please do it.
>
> If it takes more than 5 extra seconds, don't bother.
>
> Deal?  :)

Deal ;-)

--
Lydia Pintscher - http://about.me/lydia.pintscher
Community Communications for Wikidata

Wikimedia Deutschland e.V.
Obentrautstr. 72
10963 Berlin
www.wikimedia.de

Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.

Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg
unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das
Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: "Nobody" & "Wikidata bugs": notify when you start working on a bug

Roan Kattouw-2
In reply to this post by Quim Gil-2
On Thu, Dec 6, 2012 at 10:07 AM, Quim Gil <[hidden email]> wrote:
> 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
>
Those statistics don't actually measure who fixes bugs, they measure
who the fixed bugs were assigned to. Those aren't necessarily the same
person (although I imagine this is rare), but the larger issue is
that, as you say, most bugs have no human assignee. Another statistic
that is used in the BZ reports sent to this list is who closed the bug
(i.e. changed its status to RESOLVED FIXED), but this is also
suboptimal. For instance, in the VisualEditor team, James somewhat
frequently cleans up after developers who fix a bug but forget to
close it, or even mention the bug in the commit summary, so he's
probably the top bug "fixer" in VE by that metric, even though most of
that is just him taking paperwork off our hands. Another problem is
that bugs can bounce between REOPENED and FIXED multiple times, and
can be set to FIXED by different people each time.

So both metrics are noisy, although I imagine the latter would not
have a 50% signal-to-noise ratio like the former. Getting more
accuracy would be complicated: you'd probably have to look for Gerrit
links on the bug and identify their authors, or something like that.

Not saying the metric you used is wrong (it has advantages and
disadvantages), but I do think it's a bit misleadingly labeled.

Roan

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: "Nobody" & "Wikidata bugs": notify when you start working on a bug

Quim Gil-2
On 12/08/2012 08:25 PM, Roan Kattouw wrote:

> On Thu, Dec 6, 2012 at 10:07 AM, Quim Gil <[hidden email]> wrote:
>> 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
>>
> Those statistics don't actually measure who fixes bugs, they measure
> who the fixed bugs were assigned to. Those aren't necessarily the same
> person (although I imagine this is rare), but the larger issue is
> that, as you say, most bugs have no human assignee.

Yes, it's not perfect. However, I'm curious to see what happens after
paying attention to this detail during this month. Maybe the next report
will make more sense, maybe not. Maybe it will help improving a bit our
processes or maybe not.

If the whole thing is pointless and more noisy than anything then I will
just put it to rest. Like I did with the identification of "new
contributors" based on who Ohloh thought that was new. Still, the
exercise was useful for a few developers that claim their multiple
identities in Ohloh. At least Jon Robson seemed to be very happy
discovering the huge amount of Javascript lines of code he had
contributed to several projects over time.  :)

I'll keep doing my best this month assigning bugs to whoever seems to
fix them, checking the gerrit commits when available. Thank you for your
patience and collaboration.  :)

--
Quim Gil
Technical Contributor Coordinator @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l