Re: [Wikitech-l] New Gerrit privilege policy

[Tim Starling]

On 17/3/19 11:25 pm, MA wrote:
> Hello,
> 
> Would  still be
> acceptable?
> 
> Creating repos also involve self-merging stuff (.gitreview files
> mostly; also sometimes importing from GitHub).

If you're doing it already and nobody cares, it's probably fine. To
repeat, the section on self merging is merely descriptive of the
current situation. It has plenty of wiggle room to allow things that
are happening already.

I also want to emphasize that we're not going to suddenly revoke +2
access of a valued contributor for violating some narrowly interpreted
clause in the policy. I can't speak for all situations or all
committee members, but if someone complains that you shouldn't be
doing a particular variety of self merges, the obvious outcome of that
is to ask you to stop doing it.

The policy defines an escalation path for complaints which allows them
to be handled with common sense and without needless public humiliation.

-- Tim Starling


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Read access to patrolled flag in wikimedia API

[Gergo Tisza]

On Wed, Mar 13, 2019 at 10:50 PM Max Semenik  wrote:

> I don't think it's possible to filter by flagged status


Not as such. You can use the list=reviewedpages API module which will list
changes needing review (it should probably get some award for most
confusing module name), starting from most recent. It will not include new
pages which have never been reviewed, though.

On Thu, Mar 14, 2019 at 1:58 AM Сибирев Кирилл 
wrote:

> As far as i understand this flagged data contains stable revision for
> pages, which are have pending changes protection enabled and when flag is
> missing means it is disabled, is that correct?
>

Depends on the wiki, some are configured to have opt-in pending changes
protection and only manually protected pages will have a stable revision;
for some wikis flagged revisions are the default and all pages will have a
stable revision assuming someone did review the page at some point (so
recently created pages might not have a stable version yet). And many wikis
have not enabled flagged/pending changes features at all and the API will
just error out on prop=flagged.

Also is it possible to get all page revisions through this generator, so i
> can find stable content or it can only be acomplished with another page
> revisions query? When i add prop=revisions
> (prop=flagged|revisions=recentchanges) — i get only one latest
> revision.
>

I think your best bet is making a new request for the specified revisions.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Where should extension default preferences be specified?

[Gergo Tisza]

GetPreferences does not set defaults; it provides form elements for the
preferences form. The 'default' field there will be the default value in
the form; it won't actually get added to user preferences until the user
goes there and saves the form. Until then (and for anonymous users) the
value from DefaultUserOptions will be used.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Question to WMF: Backlog on bugs

[Gergő Tisza]

On Sat, Mar 16, 2019 at 5:37 PM Thomas Eugene Bishop <
thomasbis...@wenlin.com> wrote:

> A bug fix was provided years ago but never accepted or rejected. It’s the
> first and last MediaWiki bug ever assigned to me. I’ve just unassigned
> myself.
>
> https://phabricator.wikimedia.org/T149639https://phabricator.wikimedia.org/T149639
> In cases like this, remarks like “Because you did not fix these bugs” and
> “... anyone is free to pick it up and work on it ... No further response
> needed” miss the point. When a bug fix is provided, but nobody with
> authority to accept or reject it ever does so, that’s a failure on the part
> of those who have authority, not on the part of those who are able and
> willing to fix bugs. Sure, volunteers are “free” to waste their time!
>

The code review backlog is a genuine problem (I'd say it's in the top 3
problems we have, along with lack of good documentation, and
well-structured testable code). It's entirely unrelated to the task backlog
and the other topics in this thread, though.
There has been plenty of discussion on it and various attempts at
addressing (you can see some in T78768 [1], or in various Wikimedia
Developer Summit sessions such as T149639 [2]).
Unfortunately without much result so far, but the problem is definitely no
lack of awareness. (I'd argue that lack of organizational focus /
commitment *is* a problem, so making your voice heard in the various
planning processes would be helpful. wikitech-l is not a great place for
that, though.)

You need to use and share your authority more effectively, to “be bold”
> with accepting and rejecting bug fixes. Authorize more people to accept or
> reject bug fixes. Assign each proposed bug fix to one such person, starting
> with the oldest bugs. Then hold those people accountable. You don’t lack
> volunteers, you lack volunteers with authority.
>

Being able to accept bug fixes effectively means being able to deploy code
to Wikimedia production, which has security and robustness implications. So
there are some limits on how widely we can distribute that authority.
That said, we are probably more conservative than we should be, and
nominating new reviewers [3] is one of the more useful things one could do.


[1] https://phabricator.wikimedia.org/T78768
[2] https://phabricator.wikimedia.org/T149639
[3]
https://www.mediawiki.org/wiki/Gerrit/Privilege_policy#Requesting_Gerrit_privileges
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Question to WMF: Backlog on bugs

[Gergo Tisza]

On Fri, Mar 15, 2019 at 9:25 AM Strainu  wrote:

> That's an overstatement: 18% (not counting bugs closed as declined) is
> almost double to 11%. If you're going this route, we're doing much
> worse than Chromium.
>

I have a hard time imagining that anyone would be upset that 18% of our
tasks are open but would be fine with that number being 11%. A hundred
times more is significant difference. 60% more, not really.
I just wanted to point out that open bugs being about one magnitude less
than total bugs is fairly normal for an opensource project (possibly closed
projects too, it's just harder to find data there). Just to have some more
data points: Firefox has 1.4M bugs, 140K are open; Debian has 140K active
and 800K archived bugs; PHP has 77K bugs, 37K of which are closed; Apache
has 47K bugs, and 5900 open ones (including LATER).

I'm not sure how you arrived at the $2M figure (even 36 months of dev
> time - 18 teams, 2 man-months/team - only add up to ~$400K, unless
> Glasdoor is waaay off on the salaries there [2]), but presumably going
> down on the list will also surface bugs and not only features, which
> will take less time to solve. Investing an additional 1% of the
> revenue into this seems reasonable to me.
>

I used $200K per year as a rough guesstimate for the total cost of one
man-year of development (which includes salary, taxes, benefits, office
space, event participation costs, salary for administration and management
which has to scale up with the number of developers...), which I think is
on the low end (for a mostly Bay Area based organization, anyway).
Also one month of a team's time is something like 5-6 months on average.

Anyway, the point is that we are talking about fairly large amounts of
donor money here, which should be spent responsibly. Taking community
feedback into account is important, but it's not the only thing that needs
to be taken into account (one should consider how much it impacts
contributors who are for some reason less likely to speak up; how much it
impacts readers; future maintenance costs; how well it matches current
capabilities; how well it fits the roadmap; how it compares in importance
to strategic priorities; etc). The wishlist (or voting in general) is not
an ideal tool for that.

IMO one opportunity for improvement there is having a list of bugs which
are relatively easy to fix (so people can work on them in their free time
or 10% time) but relatively important to (some group of) editors. There are
plenty of developers interested in working on tasks like that. But curating
it would not be a trivial effort. (I tried something similar with the
developer wishlist two years ago (except it wasn't limited to relatively
small issues, which I think is the main reason it wasn't very successful);
that took something like six weekends if I remember correctly. Granted, it
wasn't done in a particularly efficient manner, plus, some of the
infrastructure had to be invented.)

I did not claim (or asked) that it was. What I said is that it is an
> important part of the infrastructure and that it should be maintained
> properly.
>

Are there any components for which that is not true?

At a glance none if the 2019 wishlist requests involved UploadWizard, so it
does not seem like the most pressing concern on editors' mind. And
strategically, doing structured data storage first and fancy contribution
and display features afterwards is a whole lot easier than going the other
way (something we learned at our own expense with MediaViewer).


On Sat, Mar 16, 2019 at 8:23 AM Strainu  wrote:

> A large backlog by itself is not alarming. A growing one for
> components deployed to WMF sites is. It indicates insufficient
> attention is given to ongoing maintenance of projects after they are
> no longer "actively developed", which in turn creates resentment with
> the reporters.
>

It really doesn't. The backlog is the contact surface between stuff that
exists and stuff that doesn't; all the things we don't have but which seem
realistically within reach. As functionality expands, that surface expands
too. It is a normal process.

(We do have projects which are basically unmaintained. Those are not
typically the ones producing lots of new tasks though, since most relevant
issues have been filed already. And realistically the choice is between
having poorly maintained components and having far less components. Would
undeploying UploadWizard, for example, reduce resentment? I don't think so.)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Gerrit outage

[John Bennett]

Hello,

Today we have seen Phabricator vandalism from an attacker who was also
responsible for the Gerrit outage yesterday. I’d like to clarify a comment
I made yesterday and provide as many additional details as I can while
still maintaining operational security.

While no user accounts were compromised the attacker leveraged a
vulnerability in Gerrit to comprise a single staff account. This discovery
is what lead to taking Gerrit offline so an investigation could occur, the
vulnerability could be remediated and the service restored.  However, no
further evidence of compromise was discovered and additional security
controls prevented malicious activities from being executed using the
compromised staff account. We will continue to monitor the situation and
will provide updates on this list and on the Phabricator task
https://phabricator.wikimedia.org/T218472.

Thanks

John


On Sat, Mar 16, 2019 at 2:25 PM John Bennett  wrote:

> Hello,
>
> Gerrit is available again but we are continuing to investigate the
> suspicious activity.  Our preliminary findings point to no users or
> production systems being compromised and no loss of any confidential
> information. As we continue to investigate over the next few days we will
> add any appropriate updates to the phabricator task (
> https://phabricator.wikimedia.org/T218472 ) .
>
> Thanks
>
>
> On Sat, Mar 16, 2019 at 10:26 AM John Bennett 
> wrote:
>
>> Hello,
>>
>>
>> On 16 March 2019, Wikimedia Foundation staff observed suspicious activity
>> associated with Gerrit and as a precautionary step has taken Gerrit offline
>> pending investigation.
>>
>>
>> The Wikimedia Foundation's Security, Site Reliability Engineering and
>> Release Engineering teams are investigating this incident as well as
>> potential improvements to prevent future incidents. More information will
>> be posted on Phabricator (https://phabricator.wikimedia.org/T218472 ) as
>> it becomes available and is confirmed. If you have any questions, please
>> contact the Security (secur...@wikimedia.org
>> ).
>>
>>
>> Thanks
>>
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Question to WMF: Backlog on bugs

[C. Scott Ananian]

I'll echo Andre here: the specific problem of patches from new volunteer
devs which don't get timely responses is a real issue, and one which we
have attempted to address (as Andre described) but an area we could
probably still use additional ideas, accountability, etc for.

A secondary issue is that too much wiki dev is done by WMF/WMFDE employees
(IMO); I don't think the current percentages lead to an overall healthy
open source community. But (again in my view) the first step to nurturing
and growing our non-employee contributors is to make sure their patches are
timely reviewed.
  --scott

On Sat, Mar 16, 2019, 10:54 PM Andre Klapper  wrote:

> Hi and thanks for joining the discussion!
>
> On Sat, 2019-03-16 at 20:37 -0400, Thomas Eugene Bishop wrote:
> > Here’s a specific example, created in 2015:
> >
> >   https://phabricator.wikimedia.org/T116145 <
> > https://phabricator.wikimedia.org/T116145>
> >
> >
> > A bug fix was provided years ago but never accepted or rejected. It’s
> > the first and last MediaWiki bug ever assigned to me. I’ve just
> > unassigned myself.
> >
> > In cases like this, remarks like “Because you did not fix these bugs”
> > and “... anyone is free to pick it up and work on it ... No further
> > response needed” miss the point. When a bug fix is provided, but
> > nobody with authority to accept or reject it ever does so, that’s a
> > failure on the part of those who have authority, not on the part of
> > those who are able and willing to fix bugs. Sure, volunteers are
> > “free” to waste their time!
> >
> > You need to use and share your authority more effectively, to “be
> > bold” with accepting and rejecting bug fixes. Authorize more people
> > to accept or reject bug fixes. Assign each proposed bug fix to one
> > such person, starting with the oldest bugs. Then hold those people
> > accountable. You don’t lack volunteers, you lack volunteers with
> > authority.
>
> I fully agree. I was referring to bug reports in my emails.
>
> Code review is an area in which Wikimedia is very frustrating. There
> are regular emails about patches by new contributors awaiting review
> [1] but that obviously only covers a small group of contributors.
> And while we recently started to have code stewardship reviews [2] to
> fill some gaps in the list of responsible persons and teams [3] per
> code base, we for example still lack meaningful statistics how big the
> code review problem is, in general and per team.
>
> andre
>
> [1]
> https://lists.wikimedia.org/pipermail/wikitech-l/2019-March/091632.html
> [2] https://www.mediawiki.org/wiki/Code_stewardship_reviews
> [3] https://www.mediawiki.org/wiki/Developers/Maintainers
> --
> Andre Klapper | Bugwrangler / Developer Advocate
> https://blogs.gnome.org/aklapper/
>
>
>
> ___
> 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] Unbreak now! problem in this week train Watchlist

[יגאל חיטרון]

Thanks to Aklapper for subscribing me on phab:T218511. I believe this
thread is closed. Thank you all.
Igal


‫בתאריך יום א׳, 17 במרץ 2019 ב-15:15 מאת יגאל חיטרון <‪
khit...@post.bgu.ac.il‬‏>:‬

> As I already explained, it happens every couple of hours, so you can't do
> something right now to reproduce it.
> Igal
>
>
> ‫בתאריך יום א׳, 17 במרץ 2019 ב-15:14 מאת ‪Andre Klapper‬‏ <‪
> aklap...@wikimedia.org‬‏>:‬
>
>> On Sun, 2019-03-17 at 14:53 +0200, יגאל חיטרון wrote:
>> > Great. As explained before, I did not do this, because the problem
>> > cannot be reproduced.
>>
>> You yourself wrote "it's too frequent to ignore it". That means you can
>> reproduce it? Hopefully someone else can reproduce it to, so it's not
>> just a problem with your preferences. In order to check that, see
>> https://www.mediawiki.org/wiki/Help:Locating_broken_scripts linked from
>> https://www.mediawiki.org/wiki/How_to_report_a_bug .
>>
>> > But if you say so, I'll do this, of course.
>>
>> It generally makes more sense to track issues in tasks than to send "it
>> happened again" messages to a list with hundreds of subscribers...
>>
>> Cheers,
>> andre
>> --
>> Andre Klapper | Bugwrangler / Developer Advocate
>> https://blogs.gnome.org/aklapper/
>>
>>
>>
>> ___
>> 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] Unbreak now! problem in this week train Watchlist

[יגאל חיטרון]

As I already explained, it happens every couple of hours, so you can't do
something right now to reproduce it.
Igal


‫בתאריך יום א׳, 17 במרץ 2019 ב-15:14 מאת ‪Andre Klapper‬‏ <‪
aklap...@wikimedia.org‬‏>:‬

> On Sun, 2019-03-17 at 14:53 +0200, יגאל חיטרון wrote:
> > Great. As explained before, I did not do this, because the problem
> > cannot be reproduced.
>
> You yourself wrote "it's too frequent to ignore it". That means you can
> reproduce it? Hopefully someone else can reproduce it to, so it's not
> just a problem with your preferences. In order to check that, see
> https://www.mediawiki.org/wiki/Help:Locating_broken_scripts linked from
> https://www.mediawiki.org/wiki/How_to_report_a_bug .
>
> > But if you say so, I'll do this, of course.
>
> It generally makes more sense to track issues in tasks than to send "it
> happened again" messages to a list with hundreds of subscribers...
>
> Cheers,
> andre
> --
> Andre Klapper | Bugwrangler / Developer Advocate
> https://blogs.gnome.org/aklapper/
>
>
>
> ___
> 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] Unbreak now! problem in this week train Watchlist

[Andre Klapper]

On Sun, 2019-03-17 at 14:53 +0200, יגאל חיטרון wrote:
> Great. As explained before, I did not do this, because the problem
> cannot be reproduced.

You yourself wrote "it's too frequent to ignore it". That means you can
reproduce it? Hopefully someone else can reproduce it to, so it's not
just a problem with your preferences. In order to check that, see
https://www.mediawiki.org/wiki/Help:Locating_broken_scripts linked from
https://www.mediawiki.org/wiki/How_to_report_a_bug .

> But if you say so, I'll do this, of course.

It generally makes more sense to track issues in tasks than to send "it
happened again" messages to a list with hundreds of subscribers...

Cheers,
andre
-- 
Andre Klapper | Bugwrangler / Developer Advocate
https://blogs.gnome.org/aklapper/



___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Unbreak now! problem in this week train Watchlist

[יגאל חיטרון]

Great. As explained before, I did not do this, because the problem cannot
be reproduced. But if you say so, I'll do this, of course. Thanks a lot.
Igal


‫בתאריך יום א׳, 17 במרץ 2019 ב-14:52 מאת ‪Andre Klapper‬‏ <‪
aklap...@wikimedia.org‬‏>:‬

> On Sun, 2019-03-17 at 14:43 +0200, יגאל חיטרון wrote:
> > And again. Seems that it is too frequent to just ignore it.
>
> Feel free to file a bug report with exact steps to reproduce:
> https://www.mediawiki.org/wiki/How_to_report_a_bug
>
> Thanks,
> andre
> --
> Andre Klapper | Bugwrangler / Developer Advocate
> https://blogs.gnome.org/aklapper/
>
>
>
> ___
> 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] Unbreak now! problem in this week train Watchlist

[Andre Klapper]

On Sun, 2019-03-17 at 14:43 +0200, יגאל חיטרון wrote:
> And again. Seems that it is too frequent to just ignore it.

Feel free to file a bug report with exact steps to reproduce:
https://www.mediawiki.org/wiki/How_to_report_a_bug

Thanks,
andre
-- 
Andre Klapper | Bugwrangler / Developer Advocate
https://blogs.gnome.org/aklapper/



___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Unbreak now! problem in this week train Watchlist

[יגאל חיטרון]

And again. Seems that it is too frequent to just ignore it. Thank you.
Igal


‫בתאריך יום א׳, 17 במרץ 2019 ב-0:42 מאת יגאל חיטרון <‪khit...@gmail.com‬‏>:‬

> It happens again now.
> Igal
>
>
> בתאריך יום ו׳, 15 במרץ 2019, 15:45, מאת Željko Filipin ‏<
> zfili...@wikimedia.org>:
>
>> Hi everybody,
>>
>> I'm in charge of train this week. Should this be added as a blocker?
>>
>> https://phabricator.wikimedia.org/T206675
>>
>> Thank you,
>>
>> Željko
>>
>> On Thu, Mar 14, 2019 at 6:37 PM Roan Kattouw 
>> wrote:
>>
>> > This sounds like it could have been caused by
>> > https://gerrit.wikimedia.org/r/c/mediawiki/core/+/416198
>> >
>> > ‪On Thu, Mar 14, 2019 at 10:29 AM ‫יגאל חיטרון‬‎ <
>> khit...@post.bgu.ac.il>
>> > wrote:‬
>> >
>> > > Hello. There is a regression problem, that started on this week
>> > deployment.
>> > > I can see it in group 1 from yesterday evening. I do not file a
>> > phabricator
>> > > ticket, because there is no algorithm to reproduce the problem.
>> > >
>> > > From time to time the API post query "mark this revision as read" does
>> > not
>> > > work. In these times, there is a reproducing algorithm:
>> > > 1) Open Special:Watchlist.
>> > > 2) Pick an unread revision.
>> > > 3) Open the diff to last version, or the view mode of the page.
>> > > 4) Expected: the revision, and the whole page, should be automatically
>> > > marked as read.
>> > > 5) Refresh the Special:Watchlist.
>> > > 6) Got: the revision remains bold.
>> > > 7) Open API query for unread revisions, the relevant one is still
>> there.
>> > > 8) Try partagraphs 5-7 every 5 seconds.
>> > > 9) In about twenty minutes the data is updated correctly.
>> > > I saw this yesterday at about 19:45 UTC, and it happens again just
>> now.
>> > > Thank you.
>> > > Igal (User:IKhitron)
>> > > ___
>> > > 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
>> ___
>> 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] New Gerrit privilege policy

[MA]

Hello,

Would  still be
acceptable?

Creating repos also involve self-merging stuff (.gitreview files
mostly; also sometimes importing from GitHub).

Best regards, M.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] New Gerrit privilege policy

[Tim Starling]

On 17/3/19 7:43 am, Amir Sarabadani wrote:
> I just want to point out that this wasn't "handed down by a CTO", it was a
> RFC [1] that and was open for discussion to everyone and was discussed
> extensively (and the RFC changed because of these discussions, look at the
> history of the page), then had an IRC meeting that was also open to
> everyone, then had a "last call" period for raising any objections which
> was open to everyone too. That passed with no objection being raised and
> then it also got approved by the CTO.
> 
> I might be wrong, but if I understand the structure of TechCom correctly
> (correct me if I'm wrong), it's open and transparent, the CTO can veto
> changes (which hasn't happened so far), but it's not like a CTO would just
> implement a new policy without discussion. This process is more open and
> transparent than most companies and non-profits.

Yes, that's correct. Daniel raised in TechCom the fact that the Gerrit
privilege policy needed a review. I volunteered to lead the project.
We didn't think it was strictly within the purview of TechCom to make
a binding decision on this, which is why we structured it as a
TechCom-facilitated discussion leading to a recommendation presented
for CTO approval.

-- Tim Starling



___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l