[Wikitech-l] Question about 2-phase dump

[vitalif]

Hello!

While working on my improvements to MediaWiki Import&Export, I've 
discovered a feature that is totally new for me: 2-phase backup dump. 
I.e. the first pass dumper creates XML file without page texts, and the 
second pass dumper adds page texts.


I have several questions about it - what it is intended for? Is it a 
sort of optimisation for large databases and why such method of 
optimisation was chosen?


Also, does anyone use it? (does Wikimedia use it?)


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

Re: [Wikitech-l] Help needed to complete and expand the Wikimedia glossary

[Seb35]

I support this effort to create a common glossary/vocabulary.

And I add, since I tried to translate some of these words/expressions into
French some time ago, and since it’s quite hard to obtain great and
intuitive translations for many of these expressions, it would be great if
new expressions could be thought with an internationalisation spirit as
far as possible.

As an example, in the Wikimedia Highlights of September, it’s hard to
translate "Curation Toolbar" since "curation" don’t have a direct
equivalent in French for this exact meaning (of "tacking care" of
articles, "curation" is usually translated by "conservation" but quite
different of this meaning). This is just an example but it illustrates a
common difficulty for translators, probably for many languages.

Thanks,
Seb35

Le Tue, 20 Nov 2012 19:55:04 +0100, Guillaume Paumier
 a écrit:

Hi,

The use of jargon, acronyms and other abbreviations throughout the
Wikimedia movement is a major source of communication issues, and
barriers to comprehension and involvement.

The recent thread on this list about "What is Product?" is an example
of this, as are initialisms that have long been known to be a barrier
for Wikipedia newcomers.

A way to bridge people and communities with different vocabularies is
to write and maintain a glossary that explains jargon in plain English
terms. We've been lacking a good and up-to-date glossary for Wikimedia
"stuff" (Foundation, chapter, movement, technology, etc.).

Therefore, I've started to clean up and expand the outdated Glossary
on meta, but it's a lot of work, and I don't have all the answers
myself either. I'll continue to work on it, but I'd love to get some
help on this and to make it a collaborative effort.

If you have a few minutes to spare, please consider helping your
(current and future) fellow Wikimedians by writing a few definitions
if there are terms that you can explain in plain English. Additions of
new terms are much welcome as well:

https://meta.wikimedia.org/wiki/Glossary

Some caveats:
* As part of my work, I'm mostly interested in a glossary from a
technical perspective, so the list currently has a technical bias. I'm
hoping that by sending this message to a wider audience, people from
the whole movement will contribute to the glossary and balance it out.
* Also, I've started to clean up the glossary, but it still contains
dated terms and definitions from a few years ago (like the FundCom),
so boldly edit/remove obsolete content.

Thank you,


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

Re: [Wikitech-l] Proposed new WMF browser support framework for MediaWiki

[Quim Gil]

On 11/20/2012 05:19 PM, James Forrester wrote:

* Desktop: Current and immediately-previous versions of Chrome, Firefox,
MSIE and Safari
* Tablet: Current versions of iOS/Safari; Current and immediately-previous
ones of Android
* Mobile: Current versions of iOS/Safari; Current and the five previous
ones of Android[*]

Anything not in this list may "happen to work" but WMF Engineering will not
spend resources (read, developer time) on it.


What types of problems are giving you a hard time keeping the support? 
Newest versions of browsers can be as painful to support as legacy ones, 
but the types of problems are probably very different.


Are we talking about bugs in the browsers? Sui generis interpretations 
of HTML/CSS/JS specs? Performance problems? Limitations in the devices 
using those browsers? Use of browser X specific features / workarounds 
in our software?


Or is it simply a matter of us being unable to test through >15 browsers 
and therefore trying to find criteria to limit the number to a more 
feasible <10?


Someting to take into account is that developer teams of browsers not in 
Wikimedia's "Tier 1" might be interested in driving the tests 
themselves, as part of their productization work. Think of Opera, 
Windows Phone, Blackberry, Series 40... Wikipedia is a top global site 
and probably they are already testing their latest version against it.


We could guide them better on what to test and how to find / file / 
comment on bugs and contribute patches. Having a regular contact in each 
of those teams would be really useful.


Would this be helpful, and fitting in your browser support plans?

--
Quim

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

Re: [Wikitech-l] Proposed new WMF browser support framework for MediaWiki

[James Forrester]

On 20 November 2012 19:53, Faidon Liambotis  wrote:
>
> On Tue, Nov 20, 2012 at 05:19:51PM -0800, James Forrester wrote:
> > In WMF Engineering, we've been struggling with what we mean by 'supporting'
> > browsers, and how we can match limited developer time to our natural desire
> > to make everyone happy.
> > 
> > So, to turn this mass of text into an 'ask', I would love the thoughts of
> > this list about this. Do you think this might work? Is "making sure all the
> > different parts of MediaWiki keep working with " something
> > you'd see yourself volunteering to do?
>
> So, I think you're intermixing two different things: MediaWiki support
> and "WMF Engineering" or "cluster" browser support.

I disagree. I switched from talking about WMF Engineering to asking
whether third parties, enthusiasts and volunteers would want to take
on wider MediaWiki support because an effect of our suggested policy
is that WMF's involvement in MediaWiki support for browsers not on
"our list" will reduce. This does not mean I think the two things are
the same; I would love MediaWiki to work perfectly with a wider range
of user agents than WMF has the resources to support.

[Snip]

> For example, browsers make a huge difference in the SSL features they
> support. So, we currently don't do SNI, as it's unsupported on certain
> browser/platforms¹ (mainly: Windows XP and Android < 3). Other SSL
> features (e.g. RFC 5077) are in a similar state, and I guess we can
> think of other such features not exclusive to MediaWiki.
>
> Should this policy be expanded to cover such cases too? I think so. We
> should definitely put more effort though and expand your use cases to
> ops use cases too.

Yes, this policy would cover all of WMF Engineering; sorry for not
picking an area in Ops as one of my two examples. :-)

In this particular case, it might well be that you (or someone else in
Ops) at some point makes the call that using SNI is more important
than supporting users with Windows XP (though probably not whilst
they're 21%(!) of our users). I'd expect you to highlight this change
in support to the wider community rather than just breaking it by
switching over, but that is what the framework is for - making a
decision and justifying it. :-)

J.
--
James D. Forrester
Product Manager, VisualEditor
Wikimedia Foundation, Inc.

jforres...@wikimedia.org | @jdforrester

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

Re: [Wikitech-l] Proposed new WMF browser support framework for MediaWiki

[James Forrester]

On 20 November 2012 20:00, Faidon Liambotis  wrote:
> On Tue, Nov 20, 2012 at 05:46:22PM -0800, Brion Vibber wrote:
>> "Current and immediately-previous" releases are also really hard to match
>> up between projects on fast release cycles (like Chrome and Firefox which
>> are pushing out new "major versions" every couple months) and those where
>> "major versions" only change a few times per decade, like IE.
>>
>> Supporting Chrome 22 (23 - 1) and supporting IE 9 (10 - 1) are totally
>> different animals with different usage profiles. Really nobody should be
>> running Chrome 22 -- it probably means your computer's broken and not
>> installing updates -- but IE 9's all over the place -- as is 8.
>
> Agreed. IE 9 is only supported from Vista onwards and Windows XP is
> 21.29% of our user base according to the latest stats¹. I'm not sure
> it's realistic to say that 20% of our user base may just "happen to
> work" by luck.

Those numbers are people using Windows XP, not people using Windows XP
with IE. I believe the numbers for (XP && IE) are going to be
substantially lower - probably half - but still far to high to
discount. However, you are right that Windows XP is likely to become
the next barrier to proper Web development after IE6, and perhaps we
should instead make an exception for IE compared to the other big four
browsers and suggest supporting current, and two immediately-previous
versions.

Given that I suggested "I'd be happy to talk through the individual
browser-level decisions but it might be easier to agree that we want
to focus browser support before we decide the exact focus of this."
I'm assuming this means you're happy with the overall policy and we're
just bike-shedding over which versions of which browsers? ;-)

J.
--
James D. Forrester
Product Manager, VisualEditor
Wikimedia Foundation, Inc.

jforres...@wikimedia.org | @jdforrester

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

Re: [Wikitech-l] Proposed new WMF browser support framework for MediaWiki

[James Forrester]

On 20 November 2012 22:12, Leslie Carr  wrote:
> I hate to make our job more difficult, but I think Faidon had a good point --
>
> 
> Agreed. IE 9 is only supported from Vista onwards and Windows XP is
> 21.29% of our user base according to the latest stats¹. I'm not sure
> it's realistic to say that 20% of our user base may just "happen to
> work" by luck.
> 
>
> Perhaps a percentage of use threshold system would be a bit better?  I
> don't see a breakdown of a % of requests per client type
> (desktop/phone/tablet) here -
> http://stats.wikimedia.org/wikimedia/squids/SquidReportClients.htm ,
> but it should be creatable and hopefully bring a balance between
> trying to come up with crazy workarounds for old clients and keeping
> functionality for the vast majority of users.

Do you mean a breakdown by combination of OS, OS version, browser, and
browser version? Yes, this would be very useful. The closest data on
this I can find online[*] (Flash, eww) sadly doesn't give the
breakdown by browser version (and the numbers are a little different
to ours; they're probably polling from a different demographic).

[*] - 
http://www.statowl.com/operating_system_market_share_by_os_version.php?timeframe=last_6&interval=month&chart_id=4&limit%5B%5D=windows&limit%5B%5D=mac&limit%5B%5D=linux&fltr_br=Internet+Explorer&fltr_se=&fltr_cn=

J.
--
James D. Forrester
Product Manager, VisualEditor
Wikimedia Foundation, Inc.

jforres...@wikimedia.org | @jdforrester

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

Re: [Wikitech-l] [Wmfall] Welcome Juliusz Gonera as Software Developer to the Mobile Team!

[Akshay Agarwal]

Congratulations and Welcome Juliusz! All the best.

On 11/21/12, Juliusz Gonera  wrote:
> Thank you all for a very warm welcome. Hope to meet everyone in person
> soon!
>
>
> On Mon, Nov 19, 2012 at 1:59 PM, Tomasz Finc  wrote:
>
>> I am pleased to announce that Juliusz Gonera joins WMF this week as a
>> Software Developer (Mobile team) today.
>>
>> Juliusz has worked at the University of Virginia, developing software
>> for a laboratory that studies the macromolecular structure of
>> proteins. Before that he created a system for sending bulk SMS
>> messages for a Polish company. Juliusz is a proponent of open source
>> and agile methodologies and apart from a few projects of his own [1]
>> he contributes to open source software he uses. He has just moved to
>> San Francisco and earlier lived in Virginia, Spain and Poland.
>>
>> The team would like to welcome him and wish him success.
>>
>> [1] - https://github.com/jgonera
>>
>> --tomasz
>>
>> ___
>> Wmfall mailing list
>> wmf...@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wmfall
>>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>


-- 
-Akshay Agarwal

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

Re: [Wikitech-l] Proposed new WMF browser support framework for MediaWiki

[Isarra Yos]

On 21/11/2012 08:41, Quim Gil wrote:

On 11/20/2012 05:19 PM, James Forrester wrote:

* Desktop: Current and immediately-previous versions of Chrome, Firefox,
MSIE and Safari
* Tablet: Current versions of iOS/Safari; Current and 
immediately-previous

ones of Android
* Mobile: Current versions of iOS/Safari; Current and the five previous
ones of Android[*]

Anything not in this list may "happen to work" but WMF Engineering 
will not

spend resources (read, developer time) on it.


Someting to take into account is that developer teams of browsers not 
in Wikimedia's "Tier 1" might be interested in driving the tests 
themselves, as part of their productization work. Think of Opera, 
Windows Phone, Blackberry, Series 40... Wikipedia is a top global site 
and probably they are already testing their latest version against it.


We could guide them better on what to test and how to find / file / 
comment on bugs and contribute patches. Having a regular contact in 
each of those teams would be really useful.


Would this be helpful, and fitting in your browser support plans?


Frankly, the rather limited proposed support was a little surprising to 
me - I would have expected at least some effort toward supporting 
anything in the billions of hits per month. I know Wikimedia is big, and 
all that, but that means the support would need to be big as well... and 
it also means that what Quim Gil puts forward here may well be plausible.


I dunno, perhaps I'm just biased because none of the browsers I use even 
made the list, but different browsers can support different hardware 
very differently...


--
-— Isarra


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

Re: [Wikitech-l] Proposed new WMF browser support framework for MediaWiki

[James Forrester]

On 20 November 2012 23:54, Martijn Hoekstra  wrote:
> I think a best of both worlds would be preferable. I haven't seen the
> stats, but I'd assume market share of IE 10 will be quite low. Still it
> would be silly to not strive to support it.

Well, until this month IE 10 wasn't released (just a developer
version; I wasn't counting these). Thus the "current and
immediately-previous versions" for IE would have been 9 and 8.
Supporting browsers before they're released is a nice-to-have and, as
you say, sensible to get ahead of the work, but it's not as crucial as
fixing "live" versions for millions of people.

> How about any browser released
> in the last n months whose browser family has more then x % market share
> plus any individual browser version with more then m % market share for
> some sensible figures n, x and m?

Interesting idea. Perhaps x = 5, m = 1 and n = 12; with these numbers
we'd get pretty much what I suggested, plus IE 7 and Opera 12. The
cost of supporting these (especially IE 7) would be heroic in some
areas, however - but that's what the "local policies" for different
features are for, after all.

J.
--
James D. Forrester
Product Manager, VisualEditor
Wikimedia Foundation, Inc.

jforres...@wikimedia.org | @jdforrester

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

Re: [Wikitech-l] Proposed new WMF browser support framework for MediaWiki

[James Forrester]

On 21 November 2012 07:41, Quim Gil  wrote:
> What types of problems are giving you a hard time keeping the support?
> Newest versions of browsers can be as painful to support as legacy ones, but
> the types of problems are probably very different.
>
> Are we talking about bugs in the browsers? Sui generis interpretations of
> HTML/CSS/JS specs? Performance problems? Limitations in the devices using
> those browsers? Use of browser X specific features / workarounds in our
> software?

All of these, but especially the "Specification? What specification?
We do things differently here!" problem.

> Or is it simply a matter of us being unable to test through >15 browsers and
> therefore trying to find criteria to limit the number to a more feasible
> <10?

No; testing infrastructure is something we need to do however many
browsers we're supporting (and is trivial compared to the work in
supporting the CSS issues of IE7, for example).

> Someting to take into account is that developer teams of browsers not in
> Wikimedia's "Tier 1" might be interested in driving the tests themselves, as
> part of their productization work. Think of Opera, Windows Phone,
> Blackberry, Series 40... Wikipedia is a top global site and probably they
> are already testing their latest version against it.
>
> We could guide them better on what to test and how to find / file / comment
> on bugs and contribute patches. Having a regular contact in each of those
> teams would be really useful.
>
> Would this be helpful, and fitting in your browser support plans?

Yes, definitely; if someone from Opera wanted to put in the work to
make Opera and MediaWiki compatible, and that that would make more
sense as patches for MW rather than for Opera, of course we'd love to
see that. This is what I meant by "[i]f a volunteer is willing to work
like hell to make, say, the VisualEditor work in Opera we would try to
support them by reviewing/accepting patches".

Having better (any?) relationships with the browser manufacturers
would be excellent, of course.

J.
--
James D. Forrester
Product Manager, VisualEditor
Wikimedia Foundation, Inc.

jforres...@wikimedia.org | @jdforrester

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

Re: [Wikitech-l] Proposed new WMF browser support framework for MediaWiki

[James Forrester]

On 21 November 2012 09:32, Isarra Yos  wrote:
> Frankly, the rather limited proposed support was a little surprising to me -
> I would have expected at least some effort toward supporting anything in the
> billions of hits per month.

Our 20 bn page hits a month overall means "over a billion" is a
threshold around 2%. My proposal would cut out two of those (IE 7 and
Opera 12), and was just a suggestion, not an announcement of a
decision already taken. :-)

> I dunno, perhaps I'm just biased because none of the browsers I use even
> made the list, but different browsers can support different hardware very
> differently...

Indeed. Which browsers would you like to see added?

J.
--
James D. Forrester
Product Manager, VisualEditor
Wikimedia Foundation, Inc.

jforres...@wikimedia.org | @jdforrester

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

Re: [Wikitech-l] Jenkins now lints javascript!

[Krinkle]

We're not planning on creating a job specifically for some extensions that just 
lint javascript.

However, what we are doing is this: The javascript lint check is currently the 
first component in the new Grunt build tasks system.

Once we've migrated all crucial tasks from Ant build.xml to Gruntjs and have 
migrated to Zuul (instead of Gerrit Trigger), we can easily create a catch-all 
job for any repositories that don't have a dedicated job which would simply 
execute "grunt lint" (aka the "Universal Linter") that will run phplint, 
jshint, csslint, puppetlint etc.

-- Krinkle


On Nov 21, 2012, at 7:17 AM, Santhosh Thottingal 
 wrote:

> Is there a plan to enabled this for MediaWiki extensions? For some of
> our extensions, we do jshnt check manually in local machines. It would
> be great if they also can be configured with Jenkins to run jshint.
> 
> 
> Thanks
> Santhosh
> 
> ___
> 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] Apply for the FOSS Outreach Program for Women internships

[Quim Gil]

Hi,

The deadline for applications to the Women Outreach Program is
December 3rd. Potential candidates and mentors: make sure that your
entries are listed at

https://www.mediawiki.org/wiki/Outreach_Program_for_Women#Candidates

In fact you are encouraged to list yourselves and link to the relevant
pages as soon as possible. We like transparency and we are used to
work-in-progress.  :)

Everybody else: note also that we are encouraging candidates to add a
section in their user Talk page for support and endorsements. If you
think a specific candidate/project should be selected explain your
reasons there.This way you will help us making the right decisions.

Thank you!

On Thu, Nov 15, 2012 at 12:28 PM, Quim Gil  wrote:
> Hi, the FOSS Outreach Program for Women internships has started!
>
> The blog post:
> http://blog.wikimedia.org/2012/11/15/apply-for-the-foss-outreach-program-for-women-internships/
>
> The program:
> https://live.gnome.org/OutreachProgramForWomen
>
> The Wikimedia specific information:
> https://www.mediawiki.org/wiki/Outreach_Program_for_Women
>
> If you are following Wikimedia in Identica, Twitter, G+ or Facebook,
> you likes and shares are welcome. Please help out reaching out to
> women in tech out there!
>
> --
> Quim



-- 
Quim Gil
Technical Contributor Coordinator
Wikimedia Foundation

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

Re: [Wikitech-l] Jenkins now lints javascript!

[S Page]

I have vim set up so pressing
  :J
runs jshint within vim, and I can step through the error lines.  It's a
huge time saver.

The relevant lines from my ~/.vimrc:

" Use pathogen in order to use vim-jshint
" per https://github.com/tpope/vim-pathogen :
call pathogen#infect()
" The above means my `git clone https://github.com/walm/jshint.vim.git`
" in ~/.vim/bundle is loaded.

Timo, should we be using .jshintrc per directory or lines like
/*jshint multistr:true */
at the top of files?  Or both?

grunt.js build, love it

-- 
=S Page  software engineer on E3
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Proposed new WMF browser support framework for MediaWiki

[Gabriel Wicke]

On 11/20/2012 05:19 PM, James Forrester wrote:
> There would be a "top level" outline policy - a small number
> of browsers are supported (i.e., WMF will keep spending money until they
> work):

> Anything not in this list may "happen to work" but WMF Engineering will not
> spend resources (read, developer time) on it.

I don't think that a binary 'is supported' list is that helpful for the
optimization of average user experience with limited resources.

Progressive enhancement [1] (aka 'responsive design') has in the past
been very successful at making most of our users happy. If it is
technically possible to provide a sane (but not necessarily as flashy)
user experience for users of older browsers with little extra work, then
that is an easy optimization win that should not be ignored.

This does complicate matters a bit for product, as decisions in this
area are very dependent on technical detail and differ from case to
case. It would however be sad to see more manpower in product to result
in less attention being given to this detail in the name of easily
presentable support charts. Users receiving an unreasonable 'your
platform is not supported at all' message do not care about browser
support charts- all that matters to them is that they are shut out of
whatever they were trying to do.

What exactly most users are trying to do might actually vary a bit
between browser generations, which can also be exploited in the
optimization process. I would guess that experienced editors are more
likely to run recent software than anonymous users. Features geared
towards anonymous users should thus probably emphasize compatibility
over flashiness, while features aimed at power users can make more use
of recent browser technology.

Gabriel

[1]: http://en.wikipedia.org/wiki/Progressive_enhancement
-- 
Gabriel Wicke
Senior Software Developer
Wikimedia Foundation

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

Re: [Wikitech-l] Question about 2-phase dump

[Delirium]

On 11/21/12 1:54 PM, vita...@yourcmc.ru wrote:
While working on my improvements to MediaWiki Import&Export, I've 
discovered a feature that is totally new for me: 2-phase backup dump. 
I.e. the first pass dumper creates XML file without page texts, and 
the second pass dumper adds page texts.


I have several questions about it - what it is intended for? Is it a 
sort of optimisation for large databases and why such method of 
optimisation was chosen?


Also, does anyone use it? (does Wikimedia use it?)


I'm not sure if this is the reason it was created, but one useful 
outcome is that Wikimedia can make the output of both passes available 
at dumps.wikimedia.org. This can be useful for researchers (myself 
included), because the metadata-only (pass 1) dump is sufficient for 
doing some kinds of analyses, while being *much* smaller than the full dump.


-Mark


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

[Wikitech-l] outreach program for women

[Navdeep Bagga]

Hello
I am new in wikimedia.
I want to participate in opw
Please assign me some project so that I can send application before 3 dec.

Thanking you

-- 
Navdeep Bagga
Happy Bird
[W] http://navdeepbagga.com
[T]  http://www.navdeepbagga.com/category/daily-diary-3/

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

Re: [Wikitech-l] What other FLOSS projects does the WMF contribute to/collaborate with?

[Quim Gil]

On 11/20/2012 03:03 PM, MZMcBride wrote:

Arthur Richards wrote:

On Tue, Nov 20, 2012 at 3:38 PM, Mark Holmquist
wrote:

Is this a question about on-the-clock contributions, or are we looking for
volunteer stuff, too?


I'm specifically looking for projects which we can say the WMF as an org
contributes to/collaborates with. Interpret as you will :)


Have you checked out ?


A wiki page listing open source projects where we have contributed code 
would be useful. A good complement to FLOSS-Exchange, which seems to 
focus on usage (thank you, I didn't know about this page).


--
Quim

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

Re: [Wikitech-l] outreach program for women

[Quim Gil]

Hi Navdeep!

On 11/21/2012 10:51 AM, Navdeep Bagga wrote:

I am new in wikimedia.
I want to participate in opw
Please assign me some project so that I can send application before 3 dec.


Difficult to say without knowing much about you.

From your blog one can see that you have gone through the list of 
proposals. Why not choosing one or two that fit your skills and 
interests? Then you can contact the related mentors for further advice.


And what about a microtask? Have you check the links offered at 
https://www.mediawiki.org/wiki/Outreach_Program_for_Women#Microtasks ?


Or at least you can explain yourself with more details in this list, and 
we will do our best helping you finding an appropriate microtask & project.


--
Quim Gil
Technical Contributor Coordinator
Wikimedia Foundation

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

Re: [Wikitech-l] Proposed new WMF browser support framework for MediaWiki

[Thomas Dalton]

> So, the new proposal:
>
> There would be a "top level" outline policy - a small number
> of browsers are supported (i.e., WMF will keep spending money until they
> work):
>
> * Desktop: Current and immediately-previous versions of Chrome, Firefox,
> MSIE and Safari
> * Tablet: Current versions of iOS/Safari; Current and immediately-previous
> ones of Android
> * Mobile: Current versions of iOS/Safari; Current and the five previous
> ones of Android[*]
>
> Anything not in this list may "happen to work" but WMF Engineering will not
> spend resources (read, developer time) on it. If a volunteer is willing to
> work like hell to make, say, the VisualEditor work in Opera we would try to
> support them by reviewing/accepting patches, but nothing more than that. It
> doesn't mean we would go out of our way to break previous browsers as they
> leave support, but we would not hold ourselves back from useful development
> solely because it might break browsers that we've actively decided not
> to support.

"Support" is a very vague term. I think we need to recognise that, in
reality, we will support different browsers to different degrees.
There is a big difference between "everything works exactly as
intended" and "you can read articles with no noticeable problems, but
some advanced features fail gracefully". Your list may be appropriate
for the former, but we should support significantly more browsers (the
0.1% threshold, perhaps) at the latter level (which probably won't
involve too much work, as long as you're happy to just blacklist
things if they're not easy to fix).

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

Re: [Wikitech-l] Question about 2-phase dump

[Brion Vibber]

On Wed, Nov 21, 2012 at 4:54 AM,  wrote:

> Hello!
>
> While working on my improvements to MediaWiki Import&Export, I've
> discovered a feature that is totally new for me: 2-phase backup dump. I.e.
> the first pass dumper creates XML file without page texts, and the second
> pass dumper adds page texts.
>
> I have several questions about it - what it is intended for? Is it a sort
> of optimisation for large databases and why such method of optimisation was
> chosen?
>

While generating a full dump, we're holding the database connection
open for a long, long time. Hours, days, or weeks in the case of
English Wikipedia.

There's two issues with this:
* the DB server needs to maintain a consistent snapshot of data since when
we started the connection, so it's doing extra work to keep old data around
* the DB connection needs to actually remain open; if the DB goes down or
the dump process crashes, whoops! you just lost all your work.

So, grabbing just the page and revision metadata lets us generate a file
with a consistent snapshot as quickly as possible. We get to let the
databases go, and the second pass can die and restart as many times as it
needs while fetching actual text, which is immutable (thus no worries about
consistency in the second pass).

We definitely use this system for Wikimedia's data dumps!

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

Re: [Wikitech-l] outreach program for women

[Navdeep Bagga]

On Thu, Nov 22, 2012 at 12:31 AM, Quim Gil  wrote:

> Difficult to say without knowing much about you.
>
> From your blog one can see that you have gone through the list of proposals.
> Why not choosing one or two that fit your skills and interests? Then you can
> contact the related mentors for further advice.
>
> And what about a microtask? Have you check the links offered at
> https://www.mediawiki.org/wiki/Outreach_Program_for_Women#Microtasks ?
>

I found this page
http://socialcoding4good.org/organizations/wikimedia

and I select task given in last of volunteer opportunities list.
i.e
Improve our math support using TeX and OCaml.  Make it easier for
people to write and read mathematical formulae in Wikipedia.

Is this project valid to show in OPW.
if not then suggest me.

> Or at least you can explain yourself with more details in this list, and we
> will do our best helping you finding an appropriate microtask & project.

I have done work on ldap, kannel, api, odtphp, latex, limesurvey

Languages : html, css, javascript, php and mysql

Live projects
http://vigilancebureaupunjab.org/
http://gndec.ac.in/~igs/ldh/

I am good in database management
I have Studied and experimented with database of LimeSurvey
(http://limesurvey.com/)
git repo (https://github.com/NavdeepBagga/Applicant-Form-For-Faculty-Member)

Thanking You
-- 
Navdeep Bagga
Happy Bird
[W] http://navdeepbagga.com
[T]  http://www.navdeepbagga.com/category/daily-diary-3/

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

Re: [Wikitech-l] Proposed new WMF browser support framework for MediaWiki

[Steven Walling]

On Wed, Nov 21, 2012 at 10:25 AM, Gabriel Wicke wrote:

> This does complicate matters a bit for product, as decisions in this
> area are very dependent on technical detail and differ from case to
> case. It would however be sad to see more manpower in product to result
> in less attention being given to this detail in the name of easily
> presentable support charts.
>

That was a bit mean-spirited I think. The work to make the site degrade
gracefully is not just on the product management side, it is also effort
for designers and features engineers which may already feel overworked
maintaining one version of what they build -- or rather, one version for
many skins and languages.

I was going to go on a long rant here in response to your assertion that we
shouldn't have a flashy interface, but I'll spare everyone and just say
that I strongly disagree.

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

Re: [Wikitech-l] Proposed new WMF browser support framework for MediaWiki

[Faidon Liambotis]

GOn Wed, Nov 21, 2012 at 09:17:24AM -0800, James Forrester wrote:
> Those numbers are people using Windows XP, not people using Windows XP
> with IE. I believe the numbers for (XP && IE) are going to be
> substantially lower - probably half - but still far to high to
> discount. 

Doh, my bad.

> However, you are right that Windows XP is likely to become the next
> barrier to proper Web development after IE6, and perhaps we should
> instead make an exception for IE compared to the other big four
> browsers and suggest supporting current, and two immediately-previous
> versions.

Well, I think with this exception you're trying to adjust the "latest
browser" rule to cover special cases, instead of acknowledging these
special cases for what they are.

e.g. if IE 11 comes out in 6 months while IE 8/Windows XP remains
prevalent, are we going to adjust the rule to say "three
immediately-previous versions"? What if Microsoft suddenly decides to
use the Chrome/Firefox versioning scheme?

The real reason is that you want Windows XP support, so you might just
as well put that in the rules, instead of extrapolating from the
browser's platform support.  Also, do note another thing from the other
sub-thread: SNI works on IE 8 on Vista or later, but not on IE 8 on
Windows XP, so the browser version rule won't work well in this case.

I think there is a more general flaw here, as also evident with the
Android exception. The problem is that you just can't drop support for
browsers that have a large market share, no matter when they were
released. I think that market share needs to be factored in in the
policy, or else we'll end up adding exceptions to the rules every time
our policy dictates that we're going to drop support for an older but
popular platform.

> Given that I suggested "I'd be happy to talk through the individual
> browser-level decisions but it might be easier to agree that we want
> to focus browser support before we decide the exact focus of this."
> I'm assuming this means you're happy with the overall policy and we're
> just bike-shedding over which versions of which browsers? ;-)

Well, it completely makes sense to me to have a supported browsers
policy, if that's what you're asking. On the other hand, I'm no
MediaWiki or web developer, so my view should be considered as such :)

Regards,
Faidon

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

Re: [Wikitech-l] Proposed new WMF browser support framework for MediaWiki

[Bartosz Dziewoński]

2012/11/21 James Forrester :
>> I dunno, perhaps I'm just biased because none of the browsers I use even
>> made the list, but different browsers can support different hardware very
>> differently...
>
> Indeed. Which browsers would you like to see added?

I'm going to assume Isarra was talking about Opera, since it's the
only good and at least slightly popular one that was left out. (It's
also probably the least resource-intensive one for old computers.)

I'm a Opera user myself and I love it. I can't really offer fixing
*all* the bugs on the MediaWiki–Opera border due to my limited time,
but I'd like to ask to be CC'd on them :) In my experience, most of
"Opera bugs" has been sloppy JS coding that just happened to work in
other browsers, although it does have its own share of troubles.
Still, I see no reason for making it a second-class citizen – if there
is actually one, I'd greatly appreciate links to any writeups on the
topic :)

(An example of the sloppy coding: removing all options in a 
box on focus and repopulating it. Works on Firefox and Chrome, doesn't
work on Opera, as the emptied  loses the focus, rendering the
items unselectable. This is present in the wikEd gadget, I didn't have
time nor incentive to report and fix it yet, especially since it
blocks Opera entirely by default...)

-- Matma Rex

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

Re: [Wikitech-l] Proposed new WMF browser support framework for MediaWiki

[James Forrester]

On 21 November 2012 11:54, Faidon Liambotis  wrote:
> The real reason is that you want Windows XP support, so you might just
> as well put that in the rules, instead of extrapolating from the
> browser's platform support.  Also, do note another thing from the other
> sub-thread: SNI works on IE 8 on Vista or later, but not on IE 8 on
> Windows XP, so the browser version rule won't work well in this case.

I know; forgive my terseness.

It's a defendable line to say "if you want to keep using Windows XP,
you can't use IE to do more than basic use (e.g., HTTPS will not
work); if you want more, use a different browser or different OS". I
don't think it's appropriate now if it's 10% of all users, but in a
year? Maybe. But this isn't my call to make alone, and is more
appropriate for Platform and Ops. :-)

> I think there is a more general flaw here, as also evident with the
> Android exception. The problem is that you just can't drop support for
> browsers that have a large market share, no matter when they were
> released. I think that market share needs to be factored in in the
> policy, or else we'll end up adding exceptions to the rules every time
> our policy dictates that we're going to drop support for an older but
> popular platform.

The "policy" is to have a list of browsers that we target. If we
decide the list is longer than I originally proposed, that's fine. The
idea is to have an agreed point where we say "sorry, but we can't
justify spending donor funds on fixing the problems with your
browser", instead of the current problem of trying to make do with
ad-hoc decisions.

J.
--
James D. Forrester
Product Manager, VisualEditor
Wikimedia Foundation, Inc.

jforres...@wikimedia.org | @jdforrester

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

Re: [Wikitech-l] Proposed new WMF browser support framework for MediaWiki

[Gabriel Wicke]

On 11/21/2012 11:33 AM, Steven Walling wrote:
> I was going to go on a long rant here in response to your assertion that we
> shouldn't have a flashy interface, but I'll spare everyone and just say
> that I strongly disagree.

I am not opposed to having a flashy interface at all and did not assert
anything like that.

However, having flashy interfaces does not automatically mean that the
user experience for users with older soft / hardware has to be bad. In
many cases, it is actually pretty easy from a technical perspective to
provide a reasonable experience for older browsers while still having
flashy things where supported.

I fear that a binary browser policy would discourage people from keeping
this in mind, and think that we can do better than that.

-- 
Gabriel Wicke
Senior Software Developer
Wikimedia Foundation

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

Re: [Wikitech-l] Proposed new WMF browser support framework for MediaWiki

[Derric Atzrott]

Throwing in my 10 cents on the matter.

>> I was going to go on a long rant here in response to your assertion that we
>> shouldn't have a flashy interface, but I'll spare everyone and just say
>> that I strongly disagree.
>
>I am not opposed to having a flashy interface at all and did not assert
>anything like that.
>
>However, having flashy interfaces does not automatically mean that the
>user experience for users with older soft / hardware has to be bad. In
>many cases, it is actually pretty easy from a technical perspective to
>provide a reasonable experience for older browsers while still having
>flashy things where supported.
>

I agree with this.  And I think that gracefully degrading should be the policy
wherever possible.  If I want to do things on Wikipedia from Lynx [0] I should
be able to do as much as Lynx supports, not less because my useragent doesn't
match something that we support.

>I fear that a binary browser policy would discourage people from keeping
>this in mind, and think that we can do better than that.

/\ This.  I also agree with this 100%.

It could be fairly easily solved though by simply mentioning that the intention
of the policy is not to discourage people from making gracefully degrading
interfaces.  That would solve the problem of people pulling out that policy and
pointing to it as a reason for why their stuff doesn't at least semi-work.

On the topic of which browsers to include, I recommend against having a hard
list (Firefox, Chrome, IE, etc.).  I think it would be preferable to use
percentages, but keep a list of what browsers meet that criteria at any given
time (preferably automatically updated).  I think a static list of browser,
while correct and relevant now, may not be 5 years down the line.  Although
everyone at the WMF and who volunteers with the WMF is a lot better about
updating outdated policies than almost anywhere else I have ever seen, we all
know that we have our fair share of outdated policies and documentation.

Anyhow, that's where I stand at least.

Thank you,
Derric Atzrott
Computer Specialist
Alizee Pathology

[0] http://lynx.browser.org/


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

Re: [Wikitech-l] Question about 2-phase dump

[vitalif]

Brion Vibber wrote 2012-11-21 23:20:

While generating a full dump, we're holding the database connection
open for a long, long time. Hours, days, or weeks in the case of
English Wikipedia.

There's two issues with this:
* the DB server needs to maintain a consistent snapshot of data since 
when
we started the connection, so it's doing extra work to keep old data 
around
* the DB connection needs to actually remain open; if the DB goes 
down or

the dump process crashes, whoops! you just lost all your work.

So, grabbing just the page and revision metadata lets us generate a 
file

with a consistent snapshot as quickly as possible. We get to let the
databases go, and the second pass can die and restart as many times 
as it
needs while fetching actual text, which is immutable (thus no worries 
about

consistency in the second pass).

We definitely use this system for Wikimedia's data dumps!


Oh, thanks, now I understand!
But the revisions are also immutable - isn't it simpler just to select 
maximum revision ID in the beginning of dump and just discard newer page 
and image revisions during dump generation?


Also, I have the same question about 'spawn' feature of 
backupTextPass.inc :) what is it intended for? :)


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

Re: [Wikitech-l] Proposed new WMF browser support framework for MediaWiki

[Trevor Parscal]

Whether it be a targeted list of browsers, a list of browsers we explicitly
ignore, or something else entirely, anything that helps us balance
engineering resources is a good thing.

In 2010 I suggested a rule, which became somewhat of a policy, that WMF
won't spend time/money supporting browsers that have 0.1% market share or
less based on our own stats[1] for reading and editing Wikitext source code
in a textarea. Other kinds of features, such as extra editing features or,
in the case of my current project, using the VisualEditor can have higher
thresholds, and these thresholds will be set based on whatever the team
sees as a balance between supporting as many users as possible and making
enough progress to get things out the door at a reasonable pace.

The most important distinction here is that there are different levels of
support based on the feature being considered. This is known as
progressive enhancement, it's a very common technique, and we use it all
the time with success. Currently we depend on our jquery.client module to
black-list certain browsers with known compatibility issues. This allows
new browsers, or ones we haven't tested with yet, to not be shut out just
because we didn't explicitly give them the OK. I believe that this is an
effective way to be friendly to the future, while also resolving
known compatibility problems.

Bottom line:

   1. Doing whatever it takes to make all features work in all browsers
   means spending 90% of our money on 10% of our users.
  - Spending 90% of our money on 10% of our users is a waste of donated
  money.
  - Wasting donated money is unethical.
  - Even if it were 80% of our money for 20% of our users, it's still
  out of balance.
   2. Only spending money on engineering projects that will easily work for
   100% of our users will severely limit what we can do.
  - Severe limitations on what we can do will make our user experience
  inferior to the rest of the web.
  - An inferior user experience will reduce the number of users we have.
  - Even if this only costs us 10% of our users, we've just lost the
  same number of people, but now our software sucks.
   3. Balancing compatibility with better features will result in a better
   user experience.
  - A better user experience will increase the number of users we have.
  - This can easily offset the users we lost because they are still
  using IE 5.5 on Windows 2000.

- Trevor

[1] http://stats.wikimedia.org/wikimedia/squids/SquidReportClients.htm

On Wed, Nov 21, 2012 at 12:19 PM, Gabriel Wicke wrote:

> On 11/21/2012 11:33 AM, Steven Walling wrote:
> > I was going to go on a long rant here in response to your assertion that
> we
> > shouldn't have a flashy interface, but I'll spare everyone and just say
> > that I strongly disagree.
>
> I am not opposed to having a flashy interface at all and did not assert
> anything like that.
>
> However, having flashy interfaces does not automatically mean that the
> user experience for users with older soft / hardware has to be bad. In
> many cases, it is actually pretty easy from a technical perspective to
> provide a reasonable experience for older browsers while still having
> flashy things where supported.
>
> I fear that a binary browser policy would discourage people from keeping
> this in mind, and think that we can do better than that.
>
> --
> Gabriel Wicke
> Senior Software Developer
> 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] Proposed new WMF browser support framework for MediaWiki

[Leslie Carr]

On Wed, Nov 21, 2012 at 9:33 AM, James Forrester
 wrote:
> On 20 November 2012 23:54, Martijn Hoekstra  wrote:
>> I think a best of both worlds would be preferable. I haven't seen the
>> stats, but I'd assume market share of IE 10 will be quite low. Still it
>> would be silly to not strive to support it.
>
> Well, until this month IE 10 wasn't released (just a developer
> version; I wasn't counting these). Thus the "current and
> immediately-previous versions" for IE would have been 9 and 8.
> Supporting browsers before they're released is a nice-to-have and, as
> you say, sensible to get ahead of the work, but it's not as crucial as
> fixing "live" versions for millions of people.
>
>> How about any browser released
>> in the last n months whose browser family has more then x % market share
>> plus any individual browser version with more then m % market share for
>> some sensible figures n, x and m?
>
> Interesting idea. Perhaps x = 5, m = 1 and n = 12; with these numbers
> we'd get pretty much what I suggested, plus IE 7 and Opera 12. The
> cost of supporting these (especially IE 7) would be heroic in some
> areas, however - but that's what the "local policies" for different
> features are for, after all.
>

I think this sounds like a great compromise (perhaps even with m = 2 ?)

Leslie

> J.
> --
> James D. Forrester
> Product Manager, VisualEditor
> Wikimedia Foundation, Inc.
>
> jforres...@wikimedia.org | @jdforrester
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l



-- 
Leslie Carr
Wikimedia Foundation
AS 14907, 43821
http://as14907.peeringdb.com/

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

[Wikitech-l] Deleting tags

[Chad]

Hi all,

Early today, Nikerabbit noticed he couldn't delete a tag on
a project he's owner of. This was a problem, so I've fixed it
for everyone. If you're the owner of a project, you can now
delete tags from the command line as expected.

`git push origin :refs/tags/mytag`

There's no way in the Gerrit UI to delete a tag, but this is
the standard Git way to do it.

-Chad

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

[Wikitech-l] Thanksgiving - many staffers away tomorrow & Friday

[Sumana Harihareswara]

Because of US Thanksgiving https://en.wikipedia.org/wiki/Thanksgiving ,
many Wikimedia Foundation staffers in the US will be unavailable
tomorrow and Friday November 22 & 23.  If you have an emergency, I
believe #wikimedia-tech will be responsive, just as it is on weekends.
-- 
Sumana Harihareswara
Engineering Community Manager
Wikimedia Foundation

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

Re: [Wikitech-l] Question about 2-phase dump

[Brion Vibber]

On Wed, Nov 21, 2012 at 12:31 PM,  wrote:

> Oh, thanks, now I understand!
> But the revisions are also immutable - isn't it simpler just to select
> maximum revision ID in the beginning of dump and just discard newer page
> and image revisions during dump generation?
>

Page history structure isn't quite immutable; revisions may be added or
deleted, pages may be renamed, etc etc.



> Also, I have the same question about 'spawn' feature of backupTextPass.inc
> :) what is it intended for? :)


Shelling out to an external process means when that process dies due to a
dead database connection etc, we can restart it cleanly.

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

Re: [Wikitech-l] Deleting tags

[Željko Filipin]

On Wed, Nov 21, 2012 at 10:27 PM, Chad  wrote:
> `git push origin :refs/tags/mytag`

Should we be able to delete branches too? This does not work for me:

$ git push gerrit :debug
remote: Processing changes: refs: 1, done
To ssh://zfili...@gerrit.wikimedia.org:29418/qa/browsertests
 ! [remote rejected] debug (can not delete references)
error: failed to push some refs to 'ssh://
zfili...@gerrit.wikimedia.org:29418/qa/browsertests'

I have pushed to debug branch at gerrit (instead of pushing it to another
remote) so I wanted to delete the branch. Am I doing it wrong?

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

Re: [Wikitech-l] Deleting tags

[Chad]

On Wed, Nov 21, 2012 at 4:47 PM, Željko Filipin  wrote:
> On Wed, Nov 21, 2012 at 10:27 PM, Chad  wrote:
>> `git push origin :refs/tags/mytag`
>
> Should we be able to delete branches too? This does not work for me:
>
> $ git push gerrit :debug
> remote: Processing changes: refs: 1, done
> To ssh://zfili...@gerrit.wikimedia.org:29418/qa/browsertests
>  ! [remote rejected] debug (can not delete references)
> error: failed to push some refs to 'ssh://
> zfili...@gerrit.wikimedia.org:29418/qa/browsertests'
>
> I have pushed to debug branch at gerrit (instead of pushing it to another
> remote) so I wanted to delete the branch. Am I doing it wrong?
>

If you've got the permission to delete branches, they should
show up in the UI as deletable. This should be the case for
all project owners.

-Chad

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

Re: [Wikitech-l] Jenkins now lints javascript!

[Antoine Musso]

Le 20/11/12 23:27, Krinkle a écrit :
> TL;DR: jshint is now running from Jenkins on mediawiki/core
> (joining the linting sequence for php and puppet files).

Congratulations Timo :-]  Can't wait to get the other linters in!

-- 
Antoine "hashar" Musso


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

Re: [Wikitech-l] Deleting tags

[Željko Filipin]

On Wed, Nov 21, 2012 at 10:50 PM, Chad  wrote:
> If you've got the permission to delete branches, they should
> show up in the UI as deletable.

Thanks, found the branch in the UI and deleted it:

https://gerrit.wikimedia.org/r/#/admin/projects/qa/browsertests,branches

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

Re: [Wikitech-l] Proposed new WMF browser support framework for MediaWiki

[bawolff]

>If I want to do things on Wikipedia from Lynx [0] I should
>be able to do as much as Lynx supports, not less because my useragent doesn't
>match something that we support.

Also if we cut lynx support Jidini will come and kill us in our sleep.
Dead developers = productivity loss
;)

-
On a serious note, I agree with what others have said about making
sure that there is a link that you can click and get to an edit form
that will submit on essentially all browsers is not hard and something
that should always work. More fancy features don't need to work on all
browsers. Personally doing something like support last two latest
versions of browser X doesn't really make sense to me. We should
support what people use. If no one uses latest and greatest browser X,
we shouldn't bother with it. If (a significant number of) people are
still using firefox 3.5 for some unknown reason, we should still
support it. Thus I think we should stick to using percentages, perhaps
with varying levels of support for different percentages. I'm really
unclear on what benefit we would get from declaring a list of
supported browsers [that are somewhat unrelated to viewership
percentages] instead of directly looking at the user-agent statistics.

-bawolff

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

Re: [Wikitech-l] A Newbie!

[Sébastien Santoro]

Hello,

Thank you for the interest in this outreach program.

You also need to ask a developer access on the following page:
https://www.mediawiki.org/wiki/Developer_access

Once you have your creditentials, I will be happy to assist you to
configure a developer environment (we use Git as source control and
Gerrit as code review system) on our IRC channel #mediawiki on
Freenode.

On Mon, Nov 19, 2012 at 9:09 PM, Amir E. Aharoni
 wrote:
> 2012/11/19 Hasini Abeywickrama :
>> Hi all!
>>
>> I am a new member to this mailing group & I am interested in taking part in
>> the Outreach Programme for Women!
>>
>> I would like to make my contribution to Wikimedia. I read through the
>> webpage but I have no clear idea on where do download the code & source
>> files etc.
>>
>> Can someone out there please help?
>
> Hello, and welcome!
>
> Take a look at the following page:
> https://www.mediawiki.org/wiki/How_to_become_a_MediaWiki_hacker
>
> --
> Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
> http://aharoni.wordpress.com
> ‪“We're living in pieces,
> I want to live in peace.” – T. Moore‬
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

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

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

Re: [Wikitech-l] A Newbie!

[bawolff]

On Wed, Nov 21, 2012 at 6:18 PM, Sébastien Santoro
 wrote:
> Hello,
>
> Thank you for the interest in this outreach program.
>
> You also need to ask a developer access on the following page:
> https://www.mediawiki.org/wiki/Developer_access
>
> Once you have your creditentials, I will be happy to assist you to
> configure a developer environment (we use Git as source control and
> Gerrit as code review system) on our IRC channel #mediawiki on
> Freenode.
>

As an important note on that, one does not need developer access to
play with the code (although I highly recommend you do get dev
access). One can make anonymous checkouts to start exploring
immediately without having to wait.

-bawolff

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

Re: [Wikitech-l] Proposed new WMF browser support framework for MediaWiki

[Platonides]

On 21/11/12 18:33, James Forrester wrote:
> On 20 November 2012 23:54, Martijn Hoekstra wrote:
>> I think a best of both worlds would be preferable. I haven't seen the
>> stats, but I'd assume market share of IE 10 will be quite low. Still it
>> would be silly to not strive to support it.
> 
> Well, until this month IE 10 wasn't released (just a developer
> version; I wasn't counting these). Thus the "current and
> immediately-previous versions" for IE would have been 9 and 8.
> Supporting browsers before they're released is a nice-to-have and, as
> you say, sensible to get ahead of the work, but it's not as crucial as
> fixing "live" versions for millions of people.

Funnily, Firefox 17 was released yesterday. So the latest Firefox is in
fact not shown in [[VisualEditor/2012-13_Q2_forward-look]] and I doubt
anyone on this thread had it installed when it started.

Which serves as a counterexample for the Brion statement of "nobody
should be running Chrome 22". Which was released two months ago.

I think that in addition to the some rule for the rapid release
versions, like "plus all its versions released in the last year" would
be needed.

Does it seem too much? Well, a year ago we were at Firefox 9. But
Firefox 10 is itself an Extended Support Release.
Does this mean much more work? It depends. For common browsers, we could
develop for the "new" and "old" versions. If it works for both, it is
likely to work in all the releases inbetween, too.
If the feature only works for some version (eg. suppose ContentEditable
had been added on FF 12 [if was in fact FF 3]), it could be documented,
and the feature supported just from that one onwards.

We must support old browsers, to the point where a browser designed in
the HTML4 days should provide an _acceptable_ experience. Yes, you
wouldn't have fancy HTML5 video or . But that shouldn't mean that you
couldn't rollback a certain vandalism with malformed wiktext because it
completely broke your editor.


We should have such a great-vision goal in mind. Then for «hard»
features such as Visual Editor, we may need to be satisfied with much
less, of course.

The bad thing I see with saying "volunteers can add VE support for
$SMALLBROWSER if they wish" is that only a few will be able to
understand the code, much less to fix it.


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

Re: [Wikitech-l] Proposed new WMF browser support framework for MediaWiki

[Juergen Fenn]

2012/11/21 James Forrester :

> So, the new proposal:
>
> There would be a "top level" outline policy - a small number
> of browsers are supported (i.e., WMF will keep spending money until they
> work):
>
> * Desktop: Current and immediately-previous versions of Chrome, Firefox,
> MSIE and Safari

May I please remind you of the fact that many Mac users are running
older systems until they stop working without updating their system? I
for one will keep running my MacBook with Mac OS X 10.6.8 with Safari
5.1. In TeX development we have received complaints from Mac users
running desktop systems no longer supported by MacTeX which currently
supports system 10.5 and later. So supporting the current and
immediately-previous versions of Safari may not be sufficient. Those
users also usually cannot switch to current versions of Chrome or
Firefox because they need too much memory.

Regards,
Jürgen.

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

[Wikitech-l] Manual testing strategy - DRAFT

[Quim Gil]

Here is a first stab for a draft proposal to organize our volunteer 
testing activities:


http://www.mediawiki.org/wiki/Talk:QA/Strategy#Manual_testing_strategy

Written after some lousy discussions with Chris and Sumana, and reading 
a bunch of related wiki pages. Your feedback is welcome.


Ideally this _theory_ will be immediately applicable to some pilots that 
we can run in the upcoming weeks. The Language and Mobile teams seem to 
be ready for a try - maybe even before the end of the year. Visual 
Editor and Editor Engagement teams might come next in January.


The door is open for any other project willing to run QA activities with 
volunteers. Just let me know.


--
Quim Gil
Technical Contributor Coordinator
Wikimedia Foundation

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

Re: [Wikitech-l] Question about 2-phase dump

[Platonides]

You may also be interested in the xmldatadumps mailing list.


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

Re: [Wikitech-l] Manual testing strategy - DRAFT

[Chris McMahon]

This is a great outline. I am looking forward to contributing to the areas
where I have some experience and expertise, and learning about the areas
where Quim does and I don't!
-Chris

On Wed, Nov 21, 2012 at 4:45 PM, Quim Gil  wrote:

> Here is a first stab for a draft proposal to organize our volunteer
> testing activities:
>
> http://www.mediawiki.org/wiki/**Talk:QA/Strategy#Manual_**testing_strategy
>
> Written after some lousy discussions with Chris and Sumana, and reading a
> bunch of related wiki pages. Your feedback is welcome.
>
> Ideally this _theory_ will be immediately applicable to some pilots that
> we can run in the upcoming weeks. The Language and Mobile teams seem to be
> ready for a try - maybe even before the end of the year. Visual Editor and
> Editor Engagement teams might come next in January.
>
> The door is open for any other project willing to run QA activities with
> volunteers. Just let me know.
>
> --
> Quim Gil
> Technical Contributor Coordinator
> 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] LevelUp (sequel to "What do you want to learn?" & 20% time)

[Sumana Harihareswara]

LevelUp is a mentorship program that will start in January 2013 and that
replaces the "20% time" policy
https://www.mediawiki.org/wiki/Wikimedia_engineering_20%25_policy for
Wikimedia Foundation engineers.  Technical contributors, volunteer or
staff, have the opportunity to participate; see
https://www.mediawiki.org/wiki/Mentorship_programs/LevelUp for more details.

We started 20% time to ensure that Wikimedia Foundation engineers would
spend at least 20% of each week on tasks that directly serve the
Wikimedia developer and user community, including bug triage, code
review, extension review, documentation, urgent bugfixes, and so on.  It
had various flaws. 1 day every week, I made people task-switch and it
got in the way of their deadlines, and it was perceived as a chore that
always needed doing.

It felt like enforcing a rota to do the dishes.  So instead, let's build
a dishwasher.  :-)  We can cross-train each other and fill in the empty
rows on the maintainership table
https://www.mediawiki.org/wiki/Developers/Maintainers so our whole
community gains the capacity to get stuff done faster.

If you've been frustrated because of code review delays, I want you to
sign up for LevelUp -- by March 2013 you could be a comaintainer of a
codebase and be merging and improving other people's patchsets, which
will give them more time and incentive to merge yours. :-)

When I asked what people wanted to learn, I got a variety of responses
-- including "MediaWiki in general", "puppet", "networking", and "JS,
PHP, HTML, CSS, SQL" -- all of which you can learn through LevelUp.
When I asked how you wanted to learn, all of you said you wanted
real-life, hands-on work with mentors who could answer your questions.
Here you go. :-)

I won't be starting the matchmaking process in earnest till I come back
from the Thanksgiving break on Monday, but I will reply to talk page
messages and emails then. :-)
-- 
Sumana Harihareswara
Engineering Community Manager
Wikimedia Foundation

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

Re: [Wikitech-l] Manual testing strategy - DRAFT

[Steven Walling]

On Wed, Nov 21, 2012 at 3:45 PM, Quim Gil  wrote:

> Here is a first stab for a draft proposal to organize our volunteer
> testing activities:
>
> http://www.mediawiki.org/wiki/**Talk:QA/Strategy#Manual_**testing_strategy
>
> Written after some lousy discussions with Chris and Sumana, and reading a
> bunch of related wiki pages. Your feedback is welcome.
>
> Ideally this _theory_ will be immediately applicable to some pilots that
> we can run in the upcoming weeks. The Language and Mobile teams seem to be
> ready for a try - maybe even before the end of the year. Visual Editor and
> Editor Engagement teams might come next in January.
>

This proposal feels detached from reality. Right now features teams mostly
do one of the following, in my experience:

1). Product managers and developers do their own manual QA. For PMs this
aligns with verifying requirements, for developers it's checking their own
work. It can be a pain in the ass but it works for the most part.
2). A lucky few teams have dedicated QA help, like mobile.

In either situation, manual QA tends to be done on a tight deadline,
requires an intimiate understanding of the goals and requirements, and
within a very specific scope.

I don't have a lot of experience working at a large open source project, as
a caveat, so I haven't had the opportunity to see volunteer QA in action.
But considering my current working situation, I would rather continue doing
my own QA rather than rely on a volunteer who cannot be held to a deadline
and is not personally responsible for the quality of our work. The only
solutions in my mind are A) much more robust automated testing. B) hiring
experienced QA people. Anything else is just going to slow us down.

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

Re: [Wikitech-l] LevelUp (sequel to "What do you want to learn?" & 20% time)

[bawolff]

On Wed, Nov 21, 2012 at 8:10 PM, Sumana Harihareswara
 wrote:
> LevelUp is a mentorship program that will start in January 2013 and that
> replaces the "20% time" policy
> https://www.mediawiki.org/wiki/Wikimedia_engineering_20%25_policy for
> Wikimedia Foundation engineers.  Technical contributors, volunteer or
> staff, have the opportunity to participate; see
> https://www.mediawiki.org/wiki/Mentorship_programs/LevelUp for more details.
>
> We started 20% time to ensure that Wikimedia Foundation engineers would
> spend at least 20% of each week on tasks that directly serve the
> Wikimedia developer and user community, including bug triage, code
> review, extension review, documentation, urgent bugfixes, and so on.  It
> had various flaws. 1 day every week, I made people task-switch and it
> got in the way of their deadlines, and it was perceived as a chore that
> always needed doing.
>
> It felt like enforcing a rota to do the dishes.  So instead, let's build
> a dishwasher.  :-)  We can cross-train each other and fill in the empty
> rows on the maintainership table
> https://www.mediawiki.org/wiki/Developers/Maintainers so our whole
> community gains the capacity to get stuff done faster.
>
> If you've been frustrated because of code review delays, I want you to
> sign up for LevelUp -- by March 2013 you could be a comaintainer of a
> codebase and be merging and improving other people's patchsets, which
> will give them more time and incentive to merge yours. :-)
>
> When I asked what people wanted to learn, I got a variety of responses
> -- including "MediaWiki in general", "puppet", "networking", and "JS,
> PHP, HTML, CSS, SQL" -- all of which you can learn through LevelUp.
> When I asked how you wanted to learn, all of you said you wanted
> real-life, hands-on work with mentors who could answer your questions.
> Here you go. :-)
>
> I won't be starting the matchmaking process in earnest till I come back
> from the Thanksgiving break on Monday, but I will reply to talk page
> messages and emails then. :-)
> --
> Sumana Harihareswara
> Engineering Community Manager
> Wikimedia Foundation
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

I know they just came from the bugzilla descriptions (which really
need to be updated in some cases), but some of the component
descriptions are just funny:
*API: RESTful Web-based API that lets people interact with MediaWiki
programmatically
*Job queue (available since 1.21)
(They're funny because the API isn't RESTful and the Job Queue isn't
new in 1.21).

-bawolff

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

Re: [Wikitech-l] Manual testing strategy - DRAFT

[Chris McMahon]

>
>
> This proposal feels detached from reality. Right now features teams mostly
> do one of the following, in my experience:
>
> 1). Product managers and developers do their own manual QA. For PMs this
> aligns with verifying requirements, for developers it's checking their own
> work. It can be a pain in the ass but it works for the most part.
> 2). A lucky few teams have dedicated QA help, like mobile.
>

I've mentioned this before but I've been pretty quiet about it.  QA at WMF
is still a pretty new idea, and we're still getting a lot of bits sorted,
but if your project has a need for software testing/QA, I am always willing
to help, and Zeljko and Michelle are also expert on the subject.

In either situation, manual QA tends to be done on a tight deadline,
> requires an intimiate understanding of the goals and requirements, and
> within a very specific scope.
>

Community QA is less about deadlines and more about organizing around
windows of opportunity.  My best example is the testing session that we ran
for AFTv5 just before the first limited release to production.  A nice mix
of Wikipedians and outside software testers provided well-considered
testing, and we changed AFTv5 in significant ways before the release as a
result of that feedback.


> I don't have a lot of experience working at a large open source project,
> a caveat, so I haven't had the opportunity to see volunteer QA in action.
> But considering my current working situation, I would rather continue doing
> my own QA rather than rely on a volunteer who cannot be held to a deadline
> and is not personally responsible for the quality of our work. The only
> solutions in my mind are A) much more robust automated testing. B) hiring
> experienced QA people. Anything else is just going to slow us down.


Automated testing is hugely important, and it has been my focus in recent
times, I'll be making some announcements about that very soon.   On the
community testing side, it is quite possible to have those who understand
the requirements and desired behavior create guided test "charters" for
those who are not necessarily intimately aware of the project goals.

One of the biggest impediments we have to community testing (or even user
testing by insiders) is the lack of reasonable test environments.  The
"test" and "test2" environments are not only misnamed, but are of marginal
utility.  We've been investing in beta labs, and beta is so much better
than it used to be, but we still have a way to go there.  As I mentioned on
this list before, the best way to improve beta labs at this point is to use
it.

WMF has a small but dedicated QA staff.  My idea of the role of QA/testing
is that QA/testing is a service we may provide to particular projects.
 Some projects may not need QA/testing.  Some projects may need it from
time to time, but not always.  Some projects may need community testing,
and we can support that also.

What I do not want to see is for QA/testing to be some sort of mandatory
gateway/hand-off/quality-police function that everything must pass through.
 That way lies madness.
-Chris
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Manual testing strategy - DRAFT

[sankarshan]

On Thu, Nov 22, 2012 at 5:15 AM, Quim Gil  wrote:
> Here is a first stab for a draft proposal to organize our volunteer testing
> activities:
>
> http://www.mediawiki.org/wiki/Talk:QA/Strategy#Manual_testing_strategy
>
> Written after some lousy discussions with Chris and Sumana, and reading a
> bunch of related wiki pages. Your feedback is welcome.

QA activity days often lead to a large number of duplicate issues
being filed. The bugmaster (I'm assuming this is Andre) should
probably have a say in whether there is capacity built in to handle
de-duplication either manually or, automatically.

The other thought I had was about the layered personas being created
for the team. Since Chris points out later in this thread that QA is a
relatively "new concept", being egalitarian would have a much higher
chance at a larger percentage of committed members of a QA group.

-- 
sankarshan mukhopadhyay


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

Re: [Wikitech-l] Manual testing strategy - DRAFT

[Chris McMahon]

>
>
> QA activity days often lead to a large number of duplicate issues
> being filed.


This is true.  But I think there is value when new users (for some value of
"new") file duplicate issues.  In particular, I think it points up a
possible need to increase the severity/priority of the issues reported.

The other thought I had was about the layered personas being created
> for the team. Since Chris points out later in this thread that QA is a
> relatively "new concept", being egalitarian would have a much higher
> chance at a larger percentage of committed members of a QA group.
>

Thank you.  Again, I think this comes down to testing activities or
"charters" being designed well, in advance, by those who have some
knowledge of the project being tested, for the benefit of those who have
less knowledge.  The level of expertise from project to project for any
particular person will change radically over the course of multiple test
exercises.  "Egalitarian" is a good word.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Wikimedia-l] Fwd: [Tech/Product] Engineering/Product org structure

[Quim Gil]

Thanks Erik for the extensive response.

Ultimately what counts is ongoing progress. If the model proposed is an 
improvement from the current, solving specific problems we currently 
have, then fine and I'm all or it.


I'm still stuck in one point:

On 11/19/2012 07:54 PM, Erik Moeller wrote:

3) Why not have an even flatter structure?

My prediction with a structure like the one you propose would be the following:

If you increase the number of direct engineering-related reports to
Sue from 1 to 5, her ability to meet and seriously interact with any
one of them will drop to close to zero, with no time for goal-setting
conversations, career pathing, or serious conflict resolution.


One could ask why so many things need to be reported to or pass through 
a single person? This is the factor defining the angle of verticality of 
an organization.


Why not having more decentralized reporting (broadcasting), 
goal-setting, career path, or serious conflict resolution?


Why not betting on a more brave contemporary model being a non-profit 
foundation, with hundred-something employees, an open source culture, an 
Internet culture, a wiki culture, a remote work culture, a contributors 
culture, an online community culture, a San Francisco Bay tech startup 
inspiration?


I understand what you are explaining about the board being the first 
body defining this kind of game. As for today the board is an entity too 
unilateral and abstract for me, but I'm willing to help bringing this 
type of message to them if these opinions are shared by others.


BUT

Well, at least your proposal doesn't go against this scenario. Perhaps 
is one step in that direction. Good enough here and now, I guess. Thank 
you for trying!  And for opening this discussion. Just please consider 
further steps flattening and decentralizing the WMF.


There is a blog post & video circulating these days, about how GitHub 
Inc is organized as a company. They also manage a version control system 
promoting decentralized collaboration, plus other tools supporting this 
core goal and the big community around it. They are also 
hundred-something. They have also offices in San Francisco. They are 
also a young organization growing fast. Etc.


The video is interesting and entertaining. The slides are simple and 
fun. I'm not a person for watching 40min YouTube videos, even less about 
HR & business management topics - but this one was very interesting to 
watch. Even if only as a documentary of how certain company running 
certain product I like happens to work:


Your team should work like an open source project
http://tomayko.com/writings/adopt-an-open-source-process-constraints
http://youtu.be/mrONxcyQo4E

--
Quim

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

Re: [Wikitech-l] outreach program for women

[Sumana Harihareswara]

On 11/21/2012 02:32 PM, Navdeep Bagga wrote:
> On Thu, Nov 22, 2012 at 12:31 AM, Quim Gil  wrote:
> 
>> Difficult to say without knowing much about you.
>>
>> From your blog one can see that you have gone through the list of proposals.
>> Why not choosing one or two that fit your skills and interests? Then you can
>> contact the related mentors for further advice.
>>
>> And what about a microtask? Have you check the links offered at
>> https://www.mediawiki.org/wiki/Outreach_Program_for_Women#Microtasks ?
>>
> 
> I found this page
> http://socialcoding4good.org/organizations/wikimedia
> 
> and I select task given in last of volunteer opportunities list.
> i.e
> Improve our math support using TeX and OCaml.  Make it easier for
> people to write and read mathematical formulae in Wikipedia.
> 
> Is this project valid to show in OPW.
> if not then suggest me.
> 
>> Or at least you can explain yourself with more details in this list, and we
>> will do our best helping you finding an appropriate microtask & project.
> 
> I have done work on ldap, kannel, api, odtphp, latex, limesurvey
> 
> Languages : html, css, javascript, php and mysql
> 
> Live projects
> http://vigilancebureaupunjab.org/
> http://gndec.ac.in/~igs/ldh/
> 
> I am good in database management
> I have Studied and experimented with database of LimeSurvey
> (http://limesurvey.com/)
> git repo (https://github.com/NavdeepBagga/Applicant-Form-For-Faculty-Member)
> 
> Thanking You

Hi, Navdeep.  Thanks for writing to us.  I agree with Quim that you
should go ahead and contact the mentors who are mentoring the specific
activities you're interested in that are mentioned on
https://www.mediawiki.org/wiki/Outreach_Program_for_Women .  I'm
contacting a few people who are specifically interested in math support
in MediaWiki to see whether they'd be interested in talking with you
about this potential internship.

Some additional steps that might help you:

* Register a free account at mediawiki.org.
* Request developer access
https://www.mediawiki.org/wiki/Developer_access so it'll be easier for
you to navigate Gerrit, our source control system.  We'll grant it
within a business day.
* Read the most recent monthly Wikimedia Foundation engineering report
for background on interesting things happening in Wikimedia engineering:
https://www.mediawiki.org/wiki/Wikimedia_engineering_report/2012/October
* Read https://www.mediawiki.org/wiki/Manual:MediaWiki_architecture for
an overview of the MediaWiki web-based application

The deadline for applications to the Women Outreach Program is December
3rd.  You are encouraged to list yourself at

https://www.mediawiki.org/wiki/Outreach_Program_for_Women#Candidates

and link to the relevant pages as soon as possible. We like transparency
and we are used to work-in-progress.  :)

Then, come chat with us in our 24/7 chat channel on IRC.  Details:
https://www.mediawiki.org/wiki/MediaWiki_on_IRC

Thanks again.

-- 
Sumana Harihareswara
Engineering Community Manager
Wikimedia Foundation

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

Re: [Wikitech-l] [Wikimedia-l] Fwd: [Tech/Product] Engineering/Product org structure

[Erik Moeller]

On Wed, Nov 21, 2012 at 6:02 PM, Quim Gil  wrote:
> There is a blog post & video circulating these days, about how GitHub Inc is
> organized as a company. They also manage a version control system promoting
> decentralized collaboration, plus other tools supporting this core goal and
> the big community around it. They are also hundred-something. They have also
> offices in San Francisco. They are also a young organization growing fast.
> Etc.

Yeah, I'm familiar with it. There's also a similarly interesting
description of the organizational culture at Valve (makers of
Half-Life, Portal, etc.) in the form of their employee handbook:

http://newcdn.flamehaus.com/Valve_Handbook_LowRes.pdf

I like a lot about the picture these presentations and documents
paint, and I think there's a ton we can learn from them. There are of
course also crucial differences between Wikimedia and a Git hosting
company or a game developer, and less obvious ways that power is
exercised in both organizations (e.g. the role of the founders).

> Well, at least your proposal doesn't go against this scenario. Perhaps is one 
> step in that direction.

[Fair warning, below is really starting to drift away from being
on-topic for wikitech-l and going into general OD stuff.]

I believe so. I do think we should have bigger conversations about
what kind of organization we want to be, and what tradeoffs we'd need
to accept if we wanted to move away from what's stilll in many ways a
fairly hierarchical model. Like I said, I don't think you can make
major structural changes in isolation, or you'll just end up with
mismatched expectations and broken hearts. ;-)

I do think flat structures are pretty enticing, though. I encourage
you (and anyone) to look a bit more into the way things currently work
if you want to help be part of continued evolutionary change. I've had
conversations with Sue about this and she's pretty open to supporting
well-justified structural changes (hence this discussion). The Board,
too, is generally open-minded and responsive.

An example where I think change is badly needed is the Annual Planning
process. There are few aspects of WMF that follow as conventional a
hierarchical model as this one. You see the output: a 71 page document
[1] describing the organization's planned financials, key activities
and targets, etc. To get to that point, we went through a multi-month
process driven primarily by managers, sending drafts and submissions
up and down and up the organizational ladder, with final review by Sue
and ultimate approval by the Board. This was followed by the Narrowing
Focus resolution, the Narrowing Focus process (with again lots of
leadership involvement), the Narrowing Focus document and its
approval, the Wikimedia Foundation FDC submission and its approval,
etc.

That's a lot of time spent on meta-level work. I'm not arguing it's
time and effort wasted, but I do think there's a lot of room for
streamlining and consolidating processes. I also think it's predicated
on the assumption that creating a more comprehensive plan will lead to
a better outcome, and I would challenge that belief -- there's a
threshold at which point the opposite is true, and I think in a lot of
our work that threshold is very low because the unknowns are pretty
large and new ideas and opportunities may emerge all the time.

Moreover, to get back to the point you were making, I think this is
the kind of thing that creates a lot of dependency on conventional
management approaches -- time that could be spent, by those same
people, on doing the actual work the plan talks about, while creating
a less rigid harness for the organization as a whole, in turn allowing
for structures to be simplified and enabling greater autonomy across
the board.

So, I'm not arguing against deeper structural changes -- just for
change that's harmoniously managed in concert with the various other
factors at play.

Cheers,
Erik

[1] 
https://upload.wikimedia.org/wikipedia/foundation/4/4f/2012-13_Wikimedia_Foundation_Plan_FINAL_FOR_WEBSITE.pdf

-- 
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation

Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate

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

Re: [Wikitech-l] Manual testing strategy - DRAFT

[Quim Gil]

On 11/21/2012 04:30 PM, Steven Walling wrote:

On Wed, Nov 21, 2012 at 3:45 PM, Quim Gil  wrote:


Here is a first stab for a draft proposal to organize our volunteer
testing activities:

http://www.mediawiki.org/wiki/**Talk:QA/Strategy#Manual_**testing_strategy

Written after some lousy discussions with Chris and Sumana, and reading a
bunch of related wiki pages. Your feedback is welcome.

Ideally this _theory_ will be immediately applicable to some pilots that
we can run in the upcoming weeks. The Language and Mobile teams seem to be
ready for a try - maybe even before the end of the year. Visual Editor and
Editor Engagement teams might come next in January.



This proposal feels detached from reality.


If we want to change the current reality we need a bit of detachment, 
isn't it.  :)  I believe the proposal is realistic, though. At least is 
feasible to get us started and then fine tune after each real pilot.



Right now features teams mostly
do one of the following, in my experience:

1). Product managers and developers do their own manual QA. For PMs this
aligns with verifying requirements, for developers it's checking their own
work. It can be a pain in the ass but it works for the most part.
2). A lucky few teams have dedicated QA help, like mobile.

In either situation, manual QA tends to be done on a tight deadline,
requires an intimiate understanding of the goals and requirements, and
within a very specific scope.


All this is very true for a bunch of critical missions measured against 
a limited set of pre-defined criteria. You can still get some very 
specific and focused help from volunteers for this type of work (as 
Chris has pointed out), but I agree with you that is not easy and might 
lead to extra work for everybody.


However, there is a lot more to test and in many cases good 
collaboration with volunteers will provide results that no busy 
professional team can realistically produce alone. We can call this "the 
long tail".


"The long tail" are all those areas that ideally your professional team 
would address but that get always postponed or declared out of scope. 
Even areas that are initially planned to be addressed but then they get 
pushed sprint after sprint. Where you can't reach, extra help will help 
and hardly will do any harm.


Another area where volunteers can be a lot more useful than a product 
manager or a professional tester is "user perceived quality". Because 
this something that only people not involved in project can assess. You 
think something is clear and then five outsiders can't go through it. 
You believe a problem is minor and then 3 out of 10 real users get 
systematically stuck there. You see the point.




I don't have a lot of experience working at a large open source project, as
a caveat, so I haven't had the opportunity to see volunteer QA in action.
But considering my current working situation, I would rather continue doing
my own QA rather than rely on a volunteer who cannot be held to a deadline
and is not personally responsible for the quality of our work. The only
solutions in my mind are A) much more robust automated testing. B) hiring
experienced QA people. Anything else is just going to slow us down.


QA volunteers are no substitute for your homework. But don't forget that 
QA volunteers (just like any volunteer profiles in Wikimedia, including 
editors) can be newbies and amateurs, but can also be experts in their 
area. Professionals like you, willing to contribute some time and skills.


We can have a lunch and discuss about these things, but I know the best 
way to convince you and anybody is with results. This is why the 
proposal includes a section about measuring success.  :)


The Language and Mobile teams seem to be looking forward to run the 
first pilots. Let's define something sensible and useful, let's do it 
and let's measure the results.


--
Quim

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

Re: [Wikitech-l] Manual testing strategy - DRAFT

[Quim Gil]

On 11/21/2012 05:18 PM, sankarshan wrote:

QA activity days often lead to a large number of duplicate issues
being filed. The bugmaster (I'm assuming this is Andre) should
probably have a say in whether there is capacity built in to handle
de-duplication either manually or, automatically.


It's not coincidence that the proposal puts bug triaging activities at 
the same level than testing activities. Volunteers can help, and a lot, 
dealing with the long tail of Bugzilla reports that fully dedicated 
teams have no time to go through.




The other thought I had was about the layered personas being created
for the team. Since Chris points out later in this thread that QA is a
relatively "new concept", being egalitarian would have a much higher
chance at a larger percentage of committed members of a QA group.


Sorry, I don't understand this paragraph.

Just in case: in the proposal there are some profiles and roles 
identified, with the simple purpose of agreeing what kind of people we 
are looking for and how do we expect them (us) to interact and 
collaborate with each other beyond the pure tasks of testing or bug 
triaging.


--
Quim Gil
Technical Contributor Coordinator
Wikimedia Foundation

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

Re: [Wikitech-l] Proposed new WMF browser support framework for MediaWiki

[Matthew Bowker]

Actually … I had firefox 17 months ago.  And I'm up to release 20 now.  

Mozilla pushes their pre-beta (dubbed "aurora" - generally 2 releases forward) 
at [0] , and their nightly build (funnily enough, dubbed "nightly" - generally 
4 releases forward) at [1].  They're less stable, but aurora is generally 
feature complete an can be used for testing.  

Matthew Bowker
http://en.wikipedia.org/wiki/User:Matthewrbowker

[0] https://www.mozilla.org/en-US/firefox/aurora/
[1] http://nightly.mozilla.org/

On Nov 21, 2012, at 3:56 PM, Platonides  wrote:

> On 21/11/12 18:33, James Forrester wrote:
>> On 20 November 2012 23:54, Martijn Hoekstra wrote:
>>> I think a best of both worlds would be preferable. I haven't seen the
>>> stats, but I'd assume market share of IE 10 will be quite low. Still it
>>> would be silly to not strive to support it.
>> 
>> Well, until this month IE 10 wasn't released (just a developer
>> version; I wasn't counting these). Thus the "current and
>> immediately-previous versions" for IE would have been 9 and 8.
>> Supporting browsers before they're released is a nice-to-have and, as
>> you say, sensible to get ahead of the work, but it's not as crucial as
>> fixing "live" versions for millions of people.
> 
> Funnily, Firefox 17 was released yesterday. So the latest Firefox is in
> fact not shown in [[VisualEditor/2012-13_Q2_forward-look]] and I doubt
> anyone on this thread had it installed when it started.
> 
> Which serves as a counterexample for the Brion statement of "nobody
> should be running Chrome 22". Which was released two months ago.
> 
> I think that in addition to the some rule for the rapid release
> versions, like "plus all its versions released in the last year" would
> be needed.
> 
> Does it seem too much? Well, a year ago we were at Firefox 9. But
> Firefox 10 is itself an Extended Support Release.
> Does this mean much more work? It depends. For common browsers, we could
> develop for the "new" and "old" versions. If it works for both, it is
> likely to work in all the releases inbetween, too.
> If the feature only works for some version (eg. suppose ContentEditable
> had been added on FF 12 [if was in fact FF 3]), it could be documented,
> and the feature supported just from that one onwards.
> 
> We must support old browsers, to the point where a browser designed in
> the HTML4 days should provide an _acceptable_ experience. Yes, you
> wouldn't have fancy HTML5 video or . But that shouldn't mean that you
> couldn't rollback a certain vandalism with malformed wiktext because it
> completely broke your editor.
> 
> 
> We should have such a great-vision goal in mind. Then for «hard»
> features such as Visual Editor, we may need to be satisfied with much
> less, of course.
> 
> The bad thing I see with saying "volunteers can add VE support for
> $SMALLBROWSER if they wish" is that only a few will be able to
> understand the code, much less to fix it.
> 
> 
> ___
> 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] outreach program for women

[Navdeep Bagga]

On Thu, Nov 22, 2012 at 9:09 AM, Sumana Harihareswara
 wrote:

> Hi, Navdeep.  Thanks for writing to us.  I agree with Quim that you
> should go ahead and contact the mentors who are mentoring the specific
> activities you're interested in that are mentioned on
> https://www.mediawiki.org/wiki/Outreach_Program_for_Women .  I'm
> contacting a few people who are specifically interested in math support
> in MediaWiki to see whether they'd be interested in talking with you
> about this potential internship.

I am interested in below mentioned projects, and found that you are
mentoring these projects.
1. Weekly development summary
2. Operations overview

Please suggest me what to do.
-- 
Navdeep Bagga
Happy Bird
[W] http://navdeepbagga.com
[T]  http://www.navdeepbagga.com/category/daily-diary-3/

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