Re: [Wikitech-l] Code review tasks for new contributors

[Tim Landscheidt]

Quim Gil  wrote:

> [...]

>> This is also completely the wrong way to go about open-source development.
>> The work priorities of volunteers are the thing that you, as manager of
>> paid staff, *can't* control, as opposed to the work priorities of paid
>> staff, which you very much can.

> Agreed, and one of the reasons for producing these metrics is to help paid
> developers prioritize their work taking into account the task of reviewing
> the contributions they receive. However...

> [...]

This sounds like a guide to procrastination.  "There was so
much work to choose from, boss, so I did none."

I'm still (a bit) interested in the effect of all this man-
agement on improving the process
(cf. 
http://permalink.gmane.org/gmane.science.linguistics.wikipedia.technical/54497),
but if the issue at hand is to review the ~ 2500 "code re-
views waiting for reviewer", if every one of the ~ 100 WMF
employees reviews one (additional) changeset per workday,
the task will be done by the end of this month.

There is already https://gerrit.wikimedia.org, "git review
-l" and Jon's (brilliant) tool
(cf. https://raw.github.com/jdlrobson/GerritCommandLine/master/gerrit.py)
to pick a change to review; and the nice thing about
reviewing all of them in a foreseeable time period is that
you don't have to prioritize!  Just pick any!

Just in case it got lost in transmission: Pick any!

Tim


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

[Wikitech-l] Pending changes to Extension:MultiUpload

[Lee Worden]

The MultiUpload extension has been unmaintained for a while.  I believe 
its author has moved on to another job.  I've written a completely 
independent piece of extension code (as a byproduct of work I did for 
the WorkingWiki extension) that provides a multiple-upload interface. 
After consulting with Petrb, who is listed as the current maintainer of 
MultiUpload on mediawiki.org, I'm thinking of checking in my 
multiple-upload code as a new version of MultiUpload, completely 
replacing the current implementation.


I'm posting here in case anyone objects or cares to raise concerns.

Here's a bare-bones demo video: https://www.youtube.com/watch?v=4d90Tt5EGAc

And here's my extension, in a temporary location: 
https://github.com/worden-lee/MultiUpload


Lee Worden

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

Re: [Wikitech-l] Top Level Design, LLC greedy registrar!

[phoebe ayers]

> On 4 April 2014 09:37, VP Singh  wrote:
>
> > I want to ask wikimedia , about the .wiki tld. I am AN IT expert and I
> > was going to register science.wiiki (example) in epa ( early phase
> > access) which will be in may for my firm.
> >
> > I was surprised to find that it was already registered by Top Level
> Design.
> > Visit: http://whois.domaintools.com/science.wiki.
>


It is true that wiki is a generic term but it is slightly more complex than
that. Top Level Design are the ones who initially applied to ICANN for
.wiki to be created.
see http://icannwiki.com/index.php/Top_Level_Design
and
http://dotwiki.org/

I don't know exactly how it will work, but it seems that .wiki is not yet
available for individual application  -- that starts in May:
http://nic.wiki/sunrise-opens-corporate-wiki-strategies/

Incidentally, Top Level Design is run by Ray King, who has been a long-time
part of the wiki scene in Portland. In addition to running domain-related
businesses, he genuinely loves wikis :) He is, however, totally
unaffiliated with Wikimedia.

-- Phoebe


-- 
* I use this address for lists; send personal messages to phoebe.ayers 
gmail.com *
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Top Level Design, LLC greedy registrar!

[Federico Leva (Nemo)]

"wiki" is a generic term, not a trademarked one.


You sure? Please share your certainties!


Nemo

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

Re: [Wikitech-l] Bug 24620 - Log entries are difficult to localize; rewrite logs system

[Federico Leva (Nemo)]

See 
Nobody has been working on this for years and nobody plans to work on 
it. Adopting the new log system is not hard in itself, but it requires a 
deep knowledge of the log type being converted and/or a lot of research. 
So, extremely boring + left to volunteers + high risk of breakage = 
almost never going to happen.
Every now and then someone, while refactoring things, also converts a 
log from old to new format.


Nemo

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

[Wikitech-l] Roadmap and deployment highlights - Week of April 7th

[Greg Grossmeier]

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_April_7th

Notable items...


== Tuesday ==

* The backend to the new search system (ElasticSearch) will be upgraded
* to 1.1.0
** This should not affect users in any negative way.


* MediaWiki deploy
** group1 to 1.23wmf21: All non-Wikipedia sites (Wiktionary, Wikisource,
   Wikinews, Wikibooks, Wikiquote, Wikiversity, and a few other sites)
** 

* Wikiquote will get language links via Wikidata
** 


== Thursday ==

* MediaWiki deploy
** group2 to 1.23wmf21 (all Wikipedias)
** group0 to 1.23wmf22 (test/test2/testwikidata/mediawiki)

* Media Viewer - First limited pilot release: Enable by default on
* MediaWiki.org
** 


As always, questions welcome!

Greg

-- 
| Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @gregA18D 1138 8E47 FAC8 1C7D |


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

[Wikitech-l] GSoC & FOSS OPW selection process

[Quim Gil]

GSoC / OPW weekly update.

The selection process continues. Mentors' discretion is increasing, and so
does candidates' curiosity. Even if we have made most of our choices, we
don't know how many slots we will get, and we are bound to a requirement of
confidentiality before candidates are selected on April 21. More than two
weeks to go. Take it easy.

On Monday 7 we will request a number of slots to Google, and by Wednesday 9
we will know how many they have allocated to us.

At the same time, we will decide how many OPW candidates are we aiming to
select. We will commit to a number of internships that Wikimedia will fund,
and probably we will request the GNOME Foundation (organizers of the
program) an additional number of internships to be funded by their
sponsors, a request that they might or might not be able to fulfill.

Candidates can relax a bit. You are encouraged to finish the tasks you
started, and of course we won't stop you from starting new tasks. However,
you don't have to. Most candidates have delivered everything we needed to
evaluate them. Don't be surprised if your mentors are quiet these days;
Google, GNOME and Wikimedia are asking them not to hint or leak any
speculation or resolution. If your mentors need anything from you, they
will ask.

The next update is expected by Wednesday, once we know about the number of
slots available. Thank you candidates, mentors, and rest of the community
for all your work.

On Friday, March 28, 2014, Quim Gil  wrote:

>
> https://www.mediawiki.org/wiki/Google_Summer_of_Code_2014
>
> https://www.mediawiki.org/wiki/FOSS_Outreach_Program_for_Women/Round_8
>
>>

-- 
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Next steps down the TitleValue road

[Gabriel Wicke]

On 04/03/2014 05:48 PM, Nikolas Everett wrote:
> Now that TitleValue has been merged - what's next?  I'll admit I'm an odd
> choice to be sending out this email [1], but someone's got to do it.  So,
> I'm thinking, maybe:

> 2.  Start writing code in the same fashion for an upcoming project.  I
> believe the upcoming revision storage work might lend itself well to this.

Things might be a bit simpler here as we could just use the REST interface
[1] that Aaron is working on. The question then mostly becomes whether we'd
like to wrap the raw revision data into a RevisionValue object for further
processing.

Gabriel

[1]:
https://www.mediawiki.org/wiki/Requests_for_comment/PHP_Virtual_REST_Service

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

Re: [Wikitech-l] [Wikimedia-l] Quarterly reviews of high priority WMF initiatives

[Tilman Bayer]

Minutes and slides from Monday's quarterly review meeting of the
Foundation's Analytics team are now available at
https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings/Quarterly_reviews/Analytics/March_2014
.

On Wed, Dec 19, 2012 at 6:49 PM, Erik Moeller  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_reviews
>
> 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
> wikimedi...@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l



-- 
Tilman Bayer
Senior Operations Analyst (Movement Communications)
Wikimedia Foundation
IRC (Freenode): HaeB

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

[Wikitech-l] Public Debian repository plans

[Gabriel Wicke]

Hi,

we had a short meeting this morning to discuss our Debian packaging and
repository plans for WMF-developed software. The meeting notes are now
posted at

  https://www.mediawiki.org/wiki/Talk:Packaging#Meeting_notes_2014-04-04

We agreed to set up a public repository at releases.wikimedia.org fairly
soon. The goal with this public repository is to make it easy for engineers
to release Debian packages to the general public without the thorough code
review and manual upload needed for internal packages on apt.wikimedia.org.
Automatic package builds and uploads will likely be triggered by adding a
release tag in gerrit. The longer-term hope is to provide everything needed
to make 'apt-get install mediawiki-full' install & configure a
fully-featured MediaWiki environment including caching, Parsoid, PDF
renderer and the kitchen sink.

For now the repository will only have a catch-all 'unstable' section that
can be used for tested, but frequently released packages like Parsoid (in
sync with deploys, typically twice per week). We have not made a decision on
how to structure stable releases for unattended upgrades and security yet.

Generally there was a lot of support for keeping our Debian packaging
pragmatic, without enforcing strict Debian guidelines to the letter in the
first iteration of every new package. We'd like to work with Debian and have
most of our packages eventually become official packages, but we also won't
shy away from creating something like a mediawiki-full configuration
meta-package that might not be acceptable in Debian itself.

Gabriel

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

Re: [Wikitech-l] how to get better at doing code review

[Tomasz Finc]

nice write up. thanks

On Fri, Apr 4, 2014 at 11:45 AM, Sumana Harihareswara
 wrote:
> http://notwaldorf.github.io/posts/code-reviews/
>
> One perspective. (was: Subject: Code review tasks for new contributors)
> --
> Sumana Harihareswara
> Senior Technical Writer
> Wikimedia Foundation
>
> ___
> 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] how to get better at doing code review

[Sumana Harihareswara]

http://notwaldorf.github.io/posts/code-reviews/

One perspective. (was: Subject: Code review tasks for new contributors)
-- 
Sumana Harihareswara
Senior Technical Writer
Wikimedia Foundation

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

Re: [Wikitech-l] Code review tasks for new contributors (was Re: Data to improve our code review queue)

[Brian Wolff]

>
> No, I'm not sure. Now those changesets are buried somewhere. The
hypothesis
> is that channeling some attention to them cannot make things worse.
Perhaps
> the nitpicking helps to bring back the attention of the maintainers?

Ways it could make things worse:
*incorrect advice given (if the newbies knew what to look for in a patch,
by definition i wouldnt call them a newbie). This is a real risk if we
start directing inexperianced people to do code review. Patch contributors
are often new people too, leading them astray has a big cost
*giving people false hope that their patch will get metged and in the end
making them more fet up with the entire process.

If a newbie tests a patch and then says something like - this fixes the
problem for me, that is mildly helpful. I worry if we start encouraging
newbies to do CR from the how to become a mw hacker page, we will end up
with silly comments like "-1: missing trailing ?>".

>
> Maybe we can dig  deeper in the metrics, and find changesets with last
> versions of patches waiting for a first review, a different case from,
say,
> open changesets with many versions, many comments and some +1 (a place
> where a newcomer would not add much).

Most patches are like the former. Its relatively rare to have a patch with
many versions and a couple +1's unless its actively in the process of being
reviewed or pending some external event.

>

> Many tasks that are considered uninteresting/unexciting/unfulfilling by
> experienced contributors are interesting/exciting/fulfilling for new
> contributors. Again, the EASY bugs are a good example. Ideas to define
good
> tasks for newcomers in our review queues are welcome.

Sure, but its kind of an oxymoron to say, hey people who are new and
unfamilar with our social and technical conventions, please asses wether
this patch meets those social and technical conventions.

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

[Wikitech-l] Bug 24620 - Log entries are difficult to localize; rewrite logs system

[Derric Atzrott]

Hello,

 

https://bugzilla.wikimedia.org/show_bug.cgi?id=24620

 

What is the status on this bug exactly.  I ran across it, but don't really know
enough about the i18n system to figure out if the problem was fixed.
Alternatively it could be that I simply don't know what I am doing in Bugzilla
in general (something I hope to fix).

 

Would anyone be willing to let me know where this bug stands, or close it if it
should be closed?

 

Thank you,

Derric Atzrott

Computer Specialist

Alizee Pathology

 

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

[Wikitech-l] Perl implementation of preprocessToXml

[Nikolay Shaplov]

Hi! 

I am a perl programmer, and I am trying to make perl implementation of 
mediawiki format parser in order to use it in my projects.

I want this parser to work exactly in the same way as original php code, and 
since php and perl have a lot of common in syntax,  I decided to take original 
php code and change only the thing that should be changed.

So I've taken the body of preprocessToXml, implemented all set of the stack 
classes (in a way it sould be done in perl), and reimplemented some php 
functions that are used in the code (string operations and othes)

Things that can't be fixed by defining some function I've fixed right in the 
body 
of the code.

This seems to work (I've although skipped processing of html tags for now), 
it's in quite experimental state, it is not even packaged as a module yet, 
just ./test.pl with submodules. You can check it here if you want:
 https://github.com/dhyannataraj/perl-mediawiki-parser


Why do I write here?

1. Just let you know what I am doing. May be somebody is interested in the 
same thing

2. Ask you do you have some test cases for preparser only that checks all 
special cases like "", "{{{text}}" or "{{unfinished", so I can 
automatically test that my preparset and original one gives the same result 
(I've looked in test/ in source code, these tests are much too complex than a 
preparser only tests) May be there is something that I've missed

3. I would have to keep the code up to date, so it mean that I will have to 
reimport it each major release. It is possible to make some regexps that will 
do most of the work, but in some cases code can be modified so it would be more 
perl-friendly. I.e. change comments from '//' into '#' change ===false into 
empty() (if it is equivalents). If you are willing to cooperate in this area, 
let me know. Then with the next reimport I would offer you a patch. 


So, what do you think about it all?

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

[Wikitech-l] Code review tasks for new contributors (was Re: Data to improve our code review queue)

[Quim Gil]

On Friday, April 4, 2014, Happy Melon  wrote:

> On 4 April 2014 00:38, Brian Wolff >
> wrote:
>
> >
> > > what about directing new volunteers there, asking them to submit their
> > code
> > > revisions. For a patch that has been waiting in silence for over a
> year,
> > > any feedback will be better than no feedback.
> >
> > You sure about that? I would imagine that having no one look at your code
> > for months, then having someone who doesn't have the authority to approve
> > it
> > nit pick it a little, followed by another couple months of waiting, to be
> > more frustrating then no feedback at all.
>

No, I'm not sure. Now those changesets are buried somewhere. The hypothesis
is that channeling some attention to them cannot make things worse. Perhaps
the nitpicking helps to bring back the attention of the maintainers?

Maybe we can dig  deeper in the metrics, and find changesets with last
versions of patches waiting for a first review, a different case from, say,
open changesets with many versions, many comments and some +1 (a place
where a newcomer would not add much).


> This is also completely the wrong way to go about open-source development.
> The work priorities of volunteers are the thing that you, as manager of
> paid staff, *can't* control, as opposed to the work priorities of paid
> staff, which you very much can.


Agreed, and one of the reasons for producing these metrics is to help paid
developers prioritize their work taking into account the task of reviewing
the contributions they receive. However...



>  If reviewing these old patches was in any
> way interesting/exciting/fulfilling, volunteers would probably already have
> *made* some contributions.


This would be true if such potential contributions could be easily found by
new contributors. Currently they are well hidden, you really need to know
where to go in order to find a Gerrit changeset welcoming feedback.

Can we define URLs to Gerrit queries to be advertized at
https://www.mediawiki.org/wiki/Annoying_little_bugs ? For instance, we
offer links to EASY bugs, and looking at the paths chosen by e.g. potential
GSoC candidates I would say that the system kind of works.


>  Being occasionally tasked with
> uninteresting/unexciting/unfulfilling tasks that Just Need Doing is one of
> the things that paid developers *get *paid *for*.


Many tasks that are considered uninteresting/unexciting/unfulfilling by
experienced contributors are interesting/exciting/fulfilling for new
contributors. Again, the EASY bugs are a good example. Ideas to define good
tasks for newcomers in our review queues are welcome.


-- 
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Data to improve our code review queue

[Quim Gil]

On Friday, April 4, 2014, Brian Wolff  wrote:

>
> Best practise is for author to abandon them if they are not interested any
> more. However very few people actually do that. If you want to exclude
> them, -1 is a good criteria (-1 patchsets are not waiting on review, so
> even if there is still interest, its not in queue).
>

Makes sense. Let's start excluding open changesets with a last update older
than 30 days and -1.

https://bugzilla.wikimedia.org/show_bug.cgi?id=63533


Some [wip] patches are probably also outliers in the data set and should be
> excluded.
>

Can you give examples of this type of changesets? Are there many of these?

For what is worth, in Bugzilla metrics we are able to ignore reports using
the "tracking" keyword.


If you want to know median time to review, i would suggest only counting
> merged patches, since open patches have an unknown time to review (not sure
> if this is what you are already doing).
>

So far the focus has been put into highlighting the areas that need
attention, as opposed of the performance measured by the work completed.

For what is worth, there is a "review time in days" graph at
http://korma.wmflabs.org/browser/scr.html, but I haven't looked at it, and
I'm not sure what is being counted. Perhaps average time instead of median,
and therefore getting distorted by patches that get reviewed between team
members in a few hours?

In any case, the disparity of age between resolved and unresolved
changesets might show that there is a clear stream of fast work, while
there is also a pocket of open changes languishing. Let's look at the
numbers again when the rulo of ignoring old -1s is applied.


-- 
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Shifting from PHP mailer to Swift Mailer

[Tony Thomas]

Hi,
  While working on implementing VERP for Mediawiki[1], Nemo pointed
to me, Tyler' recommendation[2] on shifting from PHP mailer to Swift
Mailer[3]. Quoting Tyler's words :
"PHPMailer has everything packed into a few classes, whereas Swift_Mailer
actually has a separation of concerns, with classes for attachments,
transport types, etc. A result of this is that PHPMailer has two different
functions for embedding multimedia: addEmbeddedImage() for files and
addStringEmbeddedImage() for strings. Another example is that PHPMailer
supports only two bodies for multipart messages, whereas Swift_Mailer will
add in as many bodies as you tell it to since a body is wrapped in its own
object. In addition, PHPMailer only really supports SMTP, whereas
Swift_Mailer has an extensible transport architecture, and multiple
transport providers. (And there's also plugins, and monolog integration,
etc".

  My mentors too think about it to be a nice idea, and Nemo
recommended adding it to my GSoC project deliverable here (
https://www.mediawiki.org/wiki/VERP#Deliverables ). But, we need more
community-consensus on the same as this needs to be done first, and VERP as
a plugin to it, if Swift mailer needs to be done. I have opened a BZ ticket
for the same ( https://bugzilla.wikimedia.org/show_bug.cgi?id=63483 ).
Please comment to this thread or in the BZ regarding the shift as it needs
to be done for a start. The discussions we had on this till date is here:
https://www.mediawiki.org/wiki/Talk:VERP#Swift_Mailer_and_VERP__40928.

[1]: https://www.mediawiki.org/wiki/VERP
[2]:
https://www.mediawiki.org/wiki/Talk:Requests_for_comment/Third-party_components
[3]: http://swiftmailer.org/


Thanks,
Tony Thomas 
FOSS@Amrita 

*"where there is a wifi,there is a way"*
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Top Level Design, LLC greedy registrar!

[Oliver Keyes]

"wiki" is a generic term, not a trademarked one.


On 4 April 2014 09:37, VP Singh  wrote:

> I want to ask wikimedia , about the .wiki tld. I am AN IT expert and I
> was going to register science.wiiki (example) in epa ( early phase
> access) which will be in may for my firm.
>
> I was surprised to find that it was already registered by Top Level Design.
> Visit: http://whois.domaintools.com/science.wiki.
>
> Your all domains like media.wiki , books.wiki etc are registered.
> http://whois.domaintools.com/books.wiki
>
> I want to know that "wiki" means collaborative web  you have the
> trademark on the tld or not.
>
> TOP LEVEL DESIGN, LLC is a  miscellaneous company. Why a registrar
> will register all premium domains.
>
> I have requested my client to ignore .wiki tld.
> What will be your action?
>
>
> Best Regards,
> V.P. Singh
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Oliver Keyes
Research Analyst
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Data to improve our code review queue

[Alex Monk]

On 4 April 2014 17:52, Quim Gil  wrote:

> On Friday, April 4, 2014, Jeroen De Dauw  wrote:>
> > http://korma.wmflabs.org/browser/scr.html
> >
> > So here I noticed my name in the list on the right and clicked it.
> > http://korma.wmflabs.org/browser/people.html?id=127&name=jeroendedauw
> >
> > These graphs seem very wrong. It is only showing commits starting in
> 2012,
> > rather than 2009. At the same time it lists emails from 2006, while I
> only
> > joined the list in 2009. It also has "jeroen_dedauw" at the top, which
> has
> > never been my commit name. So what's going on there?
> >
>
> About commits, maybe you were using a different email address before 2012,
> currently not assigned to your identity in our metrics?
>

All the old pre-Git commits (Git migration was 2012-03-21 IIRC) will have
different email addresses (svnusern...@users.mediawiki.org).
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Data to improve our code review queue

[Quim Gil]

On Friday, April 4, 2014, Jeroen De Dauw  wrote:

> Hey,
>
> > http://korma.wmflabs.org/browser/gerrit_review_queue.html
>
> Is this just for core, or for all repos?
>

This is for key Wikimedia software projects.

https://wikitech.wikimedia.org/wiki/Key_Wikimedia_software_projects


For Wikia, it sort of seems like they just created one commit that did not
> get merged. The graph seems quite skewed. At least for WMDE contributors I

would find it strange that our typical commit takes over two weeks to get
> merged if our most contributed to repos where held into account.
>

Good points; bug report created.

Bug 63530 - Identifying open changesets submitted by each organization
https://bugzilla.wikimedia.org/show_bug.cgi?id=63530



> > http://korma.wmflabs.org/browser/scr.html
>
> So here I noticed my name in the list on the right and clicked it.
> http://korma.wmflabs.org/browser/people.html?id=127&name=jeroendedauw
>
> These graphs seem very wrong. It is only showing commits starting in 2012,
> rather than 2009. At the same time it lists emails from 2006, while I only
> joined the list in 2009. It also has "jeroen_dedauw" at the top, which has
> never been my commit name. So what's going on there?
>

About commits, maybe you were using a different email address before 2012,
currently not assigned to your identity in our metrics?

About mailing lists, thank you for confirming
https://bugzilla.wikimedia.org/show_bug.cgi?id=60076

I will leave to Alvaro the explanation about the "jeroen_dedauw" part.

The underlying problem is that we need a system to allow users take care of
their own identity. There is a GSoC project idea to implement this feature,
and several students have presented proposals. The selection process is
ongoing, we will know more about this on April 21. In the meantime,

https://bugzilla.wikimedia.org/show_bug.cgi?id=58585


-- 
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Top Level Design, LLC greedy registrar!

[VP Singh]

I want to ask wikimedia , about the .wiki tld. I am AN IT expert and I
was going to register science.wiiki (example) in epa ( early phase
access) which will be in may for my firm.

I was surprised to find that it was already registered by Top Level Design.
Visit: http://whois.domaintools.com/science.wiki.

Your all domains like media.wiki , books.wiki etc are registered.
http://whois.domaintools.com/books.wiki

I want to know that "wiki" means collaborative web  you have the
trademark on the tld or not.

TOP LEVEL DESIGN, LLC is a  miscellaneous company. Why a registrar
will register all premium domains.

I have requested my client to ignore .wiki tld.
What will be your action?


Best Regards,
V.P. Singh

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

Re: [Wikitech-l] Data to improve our code review queue

[Jon Robson]

In MobileFrontend I abandon patchsets which have had no activity in a month
for this very reason. People can always reopen them.
On 4 Apr 2014 08:54, "Brad Jorsch (Anomie)"  wrote:

> On Fri, Apr 4, 2014 at 11:48 AM, Quim Gil  wrote:
>
> > On Friday, April 4, 2014, Brad Jorsch (Anomie) 
> > wrote:
> >
> > > On Thu, Apr 3, 2014 at 7:10 PM, Quim Gil  > >
> > > wrote:
> > >
> > > > The queue of open chagesets keeps growing.
> > >
> > >
> > > Does "open" include changesets that were submitted, got feedback, and
> > then
> > > the submitter never bothered to follow up?
> > >
> >
> > Yes, shouldn't we?
> >
>
> It seems a little premature to me to worry about "our number of open
> changesets keeps growing!" and "we have changesets that have been open for
> a really long time!" when we don't know how many are due to this factor
> that we have no control over (beyond marking them abandoned as stale,
> counting on the submitter to unabandon if they ever come back).
>
> Maybe abandoning old changesets with -1 reviews as stale with an
> appropriate message is something that should be done. I don't know.
>
>
> --
> Brad Jorsch (Anomie)
> Software Engineer
> Wikimedia Foundation
> ___
> 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] Data to improve our code review queue

[Marc A. Pelletier]

On 04/04/2014 11:48 AM, Quim Gil wrote:
> Open is open. What would be the best practice with these changesets? Just
> leave them open like now, abandon them, mark them with some tag...?

I can think of two broad categories we'd be interested in: "waiting for
review" and "waiting for submitter action".  While crude, the simple
metric "has gotten comments since last submit" will give a good idea of
how many in which.

-- Marc


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

Re: [Wikitech-l] Data to improve our code review queue

[Brian Wolff]

On Apr 4, 2014 12:48 PM, "Quim Gil"  wrote:
>
> On Friday, April 4, 2014, Brad Jorsch (Anomie) 
> wrote:
>
> > On Thu, Apr 3, 2014 at 7:10 PM, Quim Gil >
> > wrote:
> >
> > > The queue of open chagesets keeps growing.
> >
> >
> > Does "open" include changesets that were submitted, got feedback, and
then
> > the submitter never bothered to follow up?
> >
>
> Yes, shouldn't we?
>
> Open is open. What would be the best practice with these changesets? Just
> leave them open like now, abandon them, mark them with some tag...?
>

Best practise is for author to abandon them if they are not interested any
more. However very few people actually do that. If you want to exclude
them, -1 is a good criteria (-1 patchsets are not waiting on review, so
even if there is still interest, its not in queue).

Some [wip] patches are probably also outliers in the data set and should be
excluded.

If you want to know median time to review, i would suggest only counting
merged patches, since open patches have an unknown time to review (not sure
if this is what you are already doing).

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

Re: [Wikitech-l] Data to improve our code review queue

[Brad Jorsch (Anomie)]

On Fri, Apr 4, 2014 at 11:48 AM, Quim Gil  wrote:

> On Friday, April 4, 2014, Brad Jorsch (Anomie) 
> wrote:
>
> > On Thu, Apr 3, 2014 at 7:10 PM, Quim Gil  >
> > wrote:
> >
> > > The queue of open chagesets keeps growing.
> >
> >
> > Does "open" include changesets that were submitted, got feedback, and
> then
> > the submitter never bothered to follow up?
> >
>
> Yes, shouldn't we?
>

It seems a little premature to me to worry about "our number of open
changesets keeps growing!" and "we have changesets that have been open for
a really long time!" when we don't know how many are due to this factor
that we have no control over (beyond marking them abandoned as stale,
counting on the submitter to unabandon if they ever come back).

Maybe abandoning old changesets with -1 reviews as stale with an
appropriate message is something that should be done. I don't know.


-- 
Brad Jorsch (Anomie)
Software Engineer
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Data to improve our code review queue

[Quim Gil]

On Friday, April 4, 2014, Brad Jorsch (Anomie) 
wrote:

> On Thu, Apr 3, 2014 at 7:10 PM, Quim Gil >
> wrote:
>
> > The queue of open chagesets keeps growing.
>
>
> Does "open" include changesets that were submitted, got feedback, and then
> the submitter never bothered to follow up?
>

Yes, shouldn't we?

Open is open. What would be the best practice with these changesets? Just
leave them open like now, abandon them, mark them with some tag...?


-- 
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Language Engineering IRC Office Hour on April 09, 2014 (Wednesday) at 1700 UTC

[Runa Bhattacharjee]

[x-posted]

Hello,

The Language Engineering team will be hosting the next monthly IRC office
hour on Wednesday, April 9 2014 at 1700 UTC at #wikimedia-office.

We will be discussing about our recent work and provide updates related to
changes in the translation file format (PHP to JSON) for MediaWiki core and
extensions. As always, we will be taking questions during the session.

Please see below for event details and local time. See you at the office
hour.

Thanks
Runa

Monthly IRC Office Hour:
==
# Date: April 9, 2014

# Time: 1700 UTC/1000PDT (Check local time:
http://www.timeanddate.com/worldclock/fixedtime.html?iso=20140409T1700)

# IRC channel: #wikimedia-office

# Agenda:
1. Translation file format changes
2. Other project updates
3. Q & A (Questions can be sent to me ahead of the event)

-- 
Language Engineering - Outreach and QA Coordinator
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Data to improve our code review queue

[Happy Melon]

On 4 April 2014 00:38, Brian Wolff  wrote:

>
> > what about directing new volunteers there, asking them to submit their
> code
> > revisions. For a patch that has been waiting in silence for over a year,
> > any feedback will be better than no feedback.
>
> You sure about that? I would imagine that having no one look at your code
> for months, then having someone who doesn't have the authority to approve
> it
> nit pick it a little, followed by another couple months of waiting, to be
> more frustrating then no feedback at all.
>

This is also completely the wrong way to go about open-source development.
The work priorities of volunteers are the thing that you, as manager of
paid staff, *can't* control, as opposed to the work priorities of paid
staff, which you very much can.  If reviewing these old patches was in any
way interesting/exciting/fulfilling, volunteers would probably already have
*made* some contributions.  Being occasionally tasked with
uninteresting/unexciting/unfulfilling tasks that Just Need Doing is one of
the things that paid developers *get *paid *for*.

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

Re: [Wikitech-l] Data to improve our code review queue

[Jeroen De Dauw]

Hey,

> http://korma.wmflabs.org/browser/gerrit_review_queue.html

Is this just for core, or for all repos?

For Wikia, it sort of seems like they just created one commit that did not
get merged. The graph seems quite skewed. At least for WMDE contributors I
would find it strange that our typical commit takes over two weeks to get
merged if our most contributed to repos where held into account.

> http://korma.wmflabs.org/browser/scr.html

So here I noticed my name in the list on the right and clicked it.
http://korma.wmflabs.org/browser/people.html?id=127&name=jeroendedauw

These graphs seem very wrong. It is only showing commits starting in 2012,
rather than 2009. At the same time it lists emails from 2006, while I only
joined the list in 2009. It also has "jeroen_dedauw" at the top, which has
never been my commit name. So what's going on there?

Cheers

--
Jeroen De Dauw - http://www.bn2vs.com
Software craftsmanship advocate
Evil software architect at Wikimedia Germany
~=[,,_,,]:3
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Data to improve our code review queue

[Brad Jorsch (Anomie)]

On Thu, Apr 3, 2014 at 7:10 PM, Quim Gil  wrote:

> The queue of open chagesets keeps growing.


Does "open" include changesets that were submitted, got feedback, and then
the submitter never bothered to follow up?


-- 
Brad Jorsch (Anomie)
Software Engineer
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] What sessions do you want to see at Wikimania?

[Sumana Harihareswara]

Reminder: if you're going to Wikimania in London this year, you can 
for the sessions you want to attend. That helps the reviewers "decide
which sessions are of high interest". Tech-related stuff is mostly in:

https://wikimania2014.wikimedia.org/wiki/Category:Technology_%26_Infrastructure_submissions


https://wikimania2014.wikimedia.org/wiki/Category:Open_Data_submissions

Stuff that caught my eye includes presentations on "Mesh Sayada, a free
community network for open data and free culture", Kannada digitisation,
TogetherJS, Wikisource infrastructure, an Athena Project update,
structured Wikiquote, site performance, "How the LCA team uses
technology to scale", ridiculous browser bugs, and technical & social
aspects of anonymous editing.

-- 
Sumana Harihareswara
Senior Technical Writer
Wikimedia Foundation

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