Re: [Wikitech-l] "Fuck OAuth"

[Daniel Friesen]

It's got bits on the issues in OAuth 1 as well.

In fact it had some interesting tidbits I never heard of before.

For example. Apparently the reason that signatures sucked so badly in  
OAuth 1 doing lots of crazy things with query parameters. Was because one  
of the requirements of OAuth 1 was support for PHP 4 that didn't have  
access to the raw query string.


--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

On Mon, 05 Nov 2012 23:43:47 -0800, Tyler Romeo   
wrote:



Is this video about OAuth 2.0 only, or the original 1.0 as well?

--Tyler Romeo

*--*
*Tyler Romeo*
Stevens Institute of Technology, Class of 2015
Major in Computer Science
www.whizkidztech.com | tylerro...@gmail.com



On Tue, Nov 6, 2012 at 2:40 AM, Daniel Friesen
wrote:


The latest in the outside world's OAuth saga for those interested in the
future of api authentication in MW.

http://hueniverse.com/2012/11/**fuckoauth-realtimeconf/

--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]



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

Re: [Wikitech-l] "Fuck OAuth"

[Tyler Romeo]

Is this video about OAuth 2.0 only, or the original 1.0 as well?

--Tyler Romeo

*--*
*Tyler Romeo*
Stevens Institute of Technology, Class of 2015
Major in Computer Science
www.whizkidztech.com | tylerro...@gmail.com



On Tue, Nov 6, 2012 at 2:40 AM, Daniel Friesen
wrote:

> The latest in the outside world's OAuth saga for those interested in the
> future of api authentication in MW.
>
> http://hueniverse.com/2012/11/**fuckoauth-realtimeconf/
>
> --
> ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
>
>
> __**_
> 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] "Fuck OAuth"

[Daniel Friesen]

The latest in the outside world's OAuth saga for those interested in the  
future of api authentication in MW.


http://hueniverse.com/2012/11/fuckoauth-realtimeconf/

--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]


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

Re: [Wikitech-l] About RESOLVED LATER

[Nathan Larson]

On Mon, Nov 5, 2012 at 5:25 PM, Quim Gil  wrote:

> What about removing the LATER resolution from our Bugzilla? It feels like
> sweeping reports under the carpet. If a team is convinced that something
> won't be addressed any time soon then they can WONTFIX. If anybody feels
> differently then they can take the report back and fix it.
>
> Before we could simply reopen the 311 reports filed under RESOLVED LATER:
>

Should we create a new status, e.g. BLOCKED or LATER (rather than RESOLVED
LATER) for these?
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] want to contribute

[Harsh Kothari]

Thanks Quim

I will solve the small bugs first. What is the procedure of solving bug? Can 
you just show me to solve one bug? any small bug or any that you are currently 
solving..

Thanks 
Harsh
---
Harsh Kothari
Research Fellow, 
Physical Research Laboratory(PRL).
Ahmedabad.


On 06-Nov-2012, at 6:09 AM, Quim Gil wrote:

> On 11/05/2012 09:58 AM, Harsh Kothari wrote:
>> Hi Quim
>> 
>> Thanks for your response. Now How can I fix this bug?
> 
> You can find information on how to contribute to mobile projects at 
> http://meta.wikimedia.org/wiki/Mobile_projects/Contribute
> 
> But that is a good question, and the fact that you ask it might mean that 
> perhaps that report is not as good as I thought for starters.
> 
> There is a keyboard "easy" identifying bug reports explicitly thought to be 
> easy for newcomers:
> 
> https://bugzilla.wikimedia.org/buglist.cgi?keywords=easy&resolution=---
> 
> 131 bugs found. You can go through them and pick one.
> 
> You can also search "minor" or "trivial" bugs through the advanced search. 
> Many of them are easy for starters even if when they are not flagged as such.
> 
> After fixing several minor/trivial bugs you will acquire the experience to go 
> after bigger problems.
> 
>>> https://bugzilla.wikimedia.org/query.cgi?format=advanced
> 
>>> Show English search result if none in other language
>>> https://bugzilla.wikimedia.org/show_bug.cgi?id=32541
> 
> --
> Quim
> 
> ___
> 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] About RESOLVED LATER

[Daniel Friesen]

-1

There is an important difference between WONTFIX and LATER.

WONTFIX is something rejected because it's a bad idea, etc...
LATER is something rejected because there are technical reasons we can't  
do it any time soon now. But in the future after some major even it's  
possible that we can finally fix it.


The key point being that we don't ditch it because we won't fix it, but  
rather because we can't yet.


And that is very important.

If something is RESOLVED LATER. Then periodically and after major things  
happen we can look back through RESOLVED LATER and finally pick out old  
bugs we can fix. Something beautiful since these can be major improvements  
to MediaWiki.


But if we instead resolve things we might be able to fix in the future as  
WONTFIX and dilute them right along side bugs that should NEVER be  
implemented... then we can no longer look back and find old bugs we can  
finally fix.


If you want to get rid of RESOLVED LATER. You should first compile a full  
history of bugs and make a list of all bugs that were once marked RESOLVED  
LATER and then were given a new resolution.


--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

On Mon, 05 Nov 2012 14:25:12 -0800, Quim Gil  wrote:

I was a bit of a lazy child, specially when it came to clean up my room  
or do my homework. I tried to convince my mom and teachers about the  
paradigm of RESOLVED LATER, but they never bought it. At the end I had  
to clean up my room and do my homework.


Even as a child I suspected that they were actually right. If something  
has been postponed for later it can't be called "resolved". Now it's me  
who hears from time to time excuses from my kids that sound more or less  
like RESOLVED LATER. "Yeah, sure", I tell them, pointing to the source  
of pending work.  :)


And now to the topic:

What about removing the LATER resolution from our Bugzilla? It feels  
like sweeping reports under the carpet. If a team is convinced that  
something won't be addressed any time soon then they can WONTFIX. If  
anybody feels differently then they can take the report back and fix it.


Before we could simply reopen the 311 reports filed under RESOLVED LATER:

http://bit.ly/YxW60z

Huggle  1
MediaWiki   74
MediaWiki extensions104
Monuments database  1
mwEmbed 3
Parsoid 1
Tools   2
WikiLoves Monuments Mobile  4
Wikimedia   114
Wikimedia Labs  1
Wikimedia Mobile3
Wikipedia App   3
Total   311


Looking at the total amount of open bugs, the impact is not that big.  
The house will be as tidy/untidy as before, but at least things wll be  
clearer now.


What do you think?

--
Quim



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

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

[Erik Moeller]

FYI


-- Forwarded message --
From: Erik Moeller 
Date: Mon, Nov 5, 2012 at 5:38 PM
Subject: [Tech/Product] Engineering/Product org structure
To: Staff All 


Hi folks,

consistent with Sue's narrowing focus mandate, I’ve been thinking &
talking the last few weeks a fair bit with a bunch of different people
about the future organizational structure of the engineering/product
department. Long story short, if we want to scale the dept, and take
seriously our identity as a tech org (as stated by Sue), it’s my view
that we need to split the current department into an engineering dept
and a product dept in about 6-8 months.

To avoid fear and anxiety, and to make sure the plan makes sense, I
want to start an open conversation now. If you think any of the below
is a terrible idea, or have suggestions on how to improve the plan,
I’d love to hear from you. I’ll make myself personally available to
anyone who wants to talk more about it. (I'm traveling a bit starting
tomorrow, but will be available via email during that time.) We can
also discuss it at coming tech lunches and such.

There’s also nothing private here, so I’m forwarding this note to
wikitech-l@ and wikimedia-l@ as well. That said, there’s no urgency in
this note, so feel free to set it aside for later.

Here’s why I’m recommending to Sue that we create distinct engineering
and product departments:

- It’ll give product development and the user experience more
visibility at the senior mgmt level, which means we’ll have more
conversations at that level about the work that most of the
organization actually does. Right now, a single dept of ~70 people is
represented by 1 person across both engineering and product functions
- me. That was fine when it was half the size. Right now it’s out of
whack.

- It’ll give us the ability to add Director-level leadership functions
as appropriate without making my head explode.

- I believe that separating the two functions is consistent with Sue’s
recommendation to narrow our focus and develop our identity as an
engineering organization. It will allow for more sustained effort in
managing product priorities and greater advocacy for core platform
issues (APIs, site performance, search, ops improvements, etc.) that
are less visible than our feature priorities.

A split dept structure wouldn’t affect the way we assemble teams --
we’d still pull from required functions (devs, product, UI/UX, etc.),
and teams would continue to pursue their objectives fairly
autonomously.

It’s not all roses -- we might see more conflict between the two
functions, more us vs. them thinking, and more communications
breakdowns or forum shopping. But net I think the positives would
outweigh the negatives, and there are ways to mitigate against the
negatives.

The way we’d get there:

I’m prepared to resign from my engineering management responsibilities
and to focus solely on my remaining role as VP of Product, as soon as
a successor for VP of Engineering has been identified. We would start
that hiring process probably in early 2013. I’m recommending to Sue
that we seriously consider internal candidates for the VP of
Engineering role, as we have a strong engineering management team in
place today.

So realistically we'd probably identify that person towards the end of
the fiscal year.

Obviously I can’t make any promises to you that in that brave new
world, you’ll love whoever gets hired into the VP of Engineering role,
so there’s some unavoidable uncertainty there. I’ll support Sue in the
search, though, and I’m sure she’d appreciate feedback from you on the
kind of person who you think would be ideal for the job.

The VP of Product role would encompass a combination of functions.
Howie and I would work with the department to figure out what makes
sense as an internal structure. My opening view is that Analytics and
User Experience are potential areas that may benefit from dedicated
Director-level support roles. (Analytics is tricky because it includes
a strong engineering piece, but also a research/analyst piece working
closely with product.) The new structure would therefore be as
follows:

* VP of Engineering -> Directors of Engineering
* VP of Product -> Director of Product Development, plus new
Director-level functions (we've discussed UX/Design as a likely new
leadership function, and Analytics as a _potential_ area to centralize
here because it works so closely with product)

Why Product? I’m happy to help the org in whatever way I can; I
believe I’d be most useful to it in focusing there and helping build
this relatively new organizational function. Based on my past
experience, Howie & I make a great team. I know how engineering
operates, which could help mitigate against some of the aforementioned
issues. Plus, our product priorities generally already reflect lots of
thought and consideration, and we have no intent of reopening
questions like "Is Visual Editor the top product priority".

I look forward to hearing your

Re: [Wikitech-l] MW 1.20 release tomorrow

[Krinkle]

On Nov 5, 2012, at 8:46 PM, Mark A. Hershberger  wrote:

> I said last week that I would be releasing 1.20 today.  Due to some
> hiccups, I won't be able to do that.  I'll work on the release tonight
> and prep it for tomorrow.
> 
> Thank you for your patience,
> 
> Mark.


Open regressions introduced during 1.20 development:
https://bugzilla.wikimedia.org/buglist.cgi?resolution=---&keywords=code-update-regression&keywords_type=anywords&query_format=advanced&product=MediaWiki&version=1.20&list_id=157826

> 12 bugs found.

Open tickets milestoned 1.20.0:
https://bugzilla.wikimedia.org/buglist.cgi?resolution=---&query_format=advanced&product=MediaWiki&target_milestone=1.20.0%20release&list_id=157827

> Zarro Boogs found.

Nice :)


-- Krinkle


[1] https://toolserver.org/~krinkle/wmfBugZillaPortal/ (version 1.20 open regr. 
& milestone 1.20.0 open)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] About RESOLVED LATER

[Krinkle]

On Nov 5, 2012, at 11:54 PM, Platonides  wrote:

> How many of them depend on action from somebody else?
> (eg. upstream fixing its tool)
> 
> Of course, if we are waiting for upstream, it should list the upstream
> bug id, have upstream keyword, someone actually noticing when it's
> fixed, etc.  but those are form issues, not the status.
> (and yes, 'resolved' is a misnomer)



On Nov 6, 2012, at 12:02 AM, Nabil Maynard  wrote:

> LATER = We acknowledge this is a valid bug, and we agree that it should be
> fixed, but don't have time right now.  We will be voluntarily revisiting
> this soon.
> 
> While we could arguably just dump both situations into WONTFIX, I think
> that would muddy the triage process pretty heavily, making it more
> difficult to track bugs we intend to revisit.
> 
> That said, it IS easy for LATER to become a procrastination paradise, where
> it gets resolved and then never thought of again.  Would it be worthwhile
> to set up an automated notice when a LATER bug ages past a certain date
> (say, a month without being touched), instead of axing the resolution?
> 
> 

I agree we should drop this status.

We have the following indications that should be used instead:

* blockers / dependencies
* status ASSIGNED
* keyword upstream
* priority low or lowest
* severity minor
* or, resolved-wontfix if that is the case.

Using LATER in any of these cases only causes the bug to be lost end omitted 
from searches and lists.

I don't think it depends on the project, it depends on the user making the 
query not knowing how to utilise the above factors.

If one wants to generate a list to work off of that doesn't contain any of 
these, exclude them in the search parameters as desired. Don't stamp LATER on 
the bugs to make it fit the lazy search that only omits "RESOLVED/**".

@AndreKlapper: What do you think?

-- Krinkle



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

Re: [Wikitech-l] First stab at Bugzilla metrics

[Quim Gil]

On 11/03/2012 12:26 PM, Andre Klapper wrote:

Hi Quim,

On Fri, 2012-11-02 at 16:36 -0700, Quim Gil wrote:

What Bugzilla metrics would you like to see in the monthly report?

Please have a look at
http://www.mediawiki.org/wiki/Talk:Community_Metrics#Drafting_Bugzilla_metrics

It's just a first draft.


Nice, I like it!

Other ideas:
* Top bug closers (fixers is a subset of that, obviously)


Ok, will add it tonight.


* Top bug commenters


I had this one but then I thought that... I'll bring it back.



* Phrasing: Under "Stale bugs" the sections "Older than X" were unclear
to me.  It means "Reports that were filed more than X ago" but at first
I thought of "Reports where the last change happened X or longer ago".


I've cleaned the whole section. Check:

http://www.mediawiki.org/wiki/Talk:Community_Metrics#Stale_bugs



Some queries will require specific Bugzilla permissions, such as "Total
amount of accounts". FYI, https://bugzilla.wikimedia.org/editusers.cgi
currently says "16231 users found."


You can prepare those numbers for the monthly report, or you can explain 
me how to help myself. Up to you.  :)




Stuff like "Average time to response / until resolved" will be hard
(impossible?) to get via functionality provided by the Bugzilla web
interface or XML-RPC. Probably SQL query land instead.


Ok. For the November report I'm happy going for the Bugzilla stats that 
can be retrieved through the regular interface.


The next concern is how to automatize all this in the December report, 
if not before.



Could we have something like http://www.octofish.net/bugjar/ ?


Is the script behind that somewhere available?


I have asked the owner, with you in CC.

--
Quim

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

Re: [Wikitech-l] want to contribute

[Quim Gil]

On 11/05/2012 09:58 AM, Harsh Kothari wrote:

Hi Quim

Thanks for your response. Now How can I fix this bug?


You can find information on how to contribute to mobile projects at 
http://meta.wikimedia.org/wiki/Mobile_projects/Contribute


But that is a good question, and the fact that you ask it might mean 
that perhaps that report is not as good as I thought for starters.


There is a keyboard "easy" identifying bug reports explicitly thought to 
be easy for newcomers:


https://bugzilla.wikimedia.org/buglist.cgi?keywords=easy&resolution=---

131 bugs found. You can go through them and pick one.

You can also search "minor" or "trivial" bugs through the advanced 
search. Many of them are easy for starters even if when they are not 
flagged as such.


After fixing several minor/trivial bugs you will acquire the experience 
to go after bigger problems.



https://bugzilla.wikimedia.org/query.cgi?format=advanced



Show English search result if none in other language
https://bugzilla.wikimedia.org/show_bug.cgi?id=32541


--
Quim

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

Re: [Wikitech-l] About RESOLVED LATER

[Quim Gil]

On 11/05/2012 03:02 PM, Nabil Maynard wrote:

WONTFIX = We acknowledge this is a valid bug, but are choosing not to fix
it due to time and resources necessary to fix it.  We will not be
revisiting this bug unless it is re-raised by others.
LATER = We acknowledge this is a valid bug, and we agree that it should be
fixed, but don't have time right now.  We will be voluntarily revisiting
this soon.


Actually no.

WONTFIX = Your feature proposed doesn't fit in our plans for this 
project, or the minor bug you get occasionally implies to rewrite 
everything (etc) therefore we choose not to fix it - neither we expect 
anybody else to address it unless they fork the whole project. If you 
believe we are wrong convince us and we might reopen.


If a report is valid but there are no resources to address it then it 
should be left open as NEW with LOW priority, making it easy to be searched.


NEW-LOW and RESOLVED-WONTFIX are clear answers that throw the ball back 
to the reporter or anybody else interested in the report. RESOLVED-LATER 
is confusing and leaves certain expectation, with a higher possibility 
of losing the ball between the cracks.


The comments about LATER make theoretical sense, but the practice of bug 
trackers leaves little room for doubt: the reports that are not open are 
perceived as closed for good. They disappear from lists and reports, and 
are forgotten soon.


--
Quim

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

Re: [Wikitech-l] Dropping "My …" prefix from toolbar labels

[Ryan Kaldari]

There are a few extensions that also follow the 'My' paradigm and should 
be updated: LiquidThreads, EducationProgram, etc.


Ryan Kaldari

On 11/5/12 3:30 PM, Steven Walling wrote:

On Sun, Nov 4, 2012 at 6:50 PM, Trevor Parscal wrote:


I've supported this change for a very long time, glad to see it's on the
table.

+1


To quote James F. from the bug:

Code change merged and presumably will be deployed from wmf4 branch:
https://gerrit.wikimedia.org/r/#/c/31605/

Steven
___
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] About RESOLVED LATER

[Nabil Maynard]

I suppose that depends on the particular project.  From the sounds of it,
the discussion is about removing LATER as a resolution option across the
entire database, including some projects that do have specific people
driving development (some extensions, for instance).  There is also
absolutely no reason newcomers or others couldn't do a search for postponed
bugs, and use that as a jumping off point for contributing to a project.
 You aren't removing that option to contribute from anyone.

Yes, you could arguably just keep it open, but that gets into the same
issue as stuffing everything into WONTFIX, where it is making it more
difficult to track which bugs are fresh, and which are extant bugs you'd
like to get to, but either don't have cycles for or are otherwise blocked.
 The point of having the additional granularity is to make it easier to
keep the database organized.

Nabil


On Mon, Nov 5, 2012 at 3:10 PM, Isarra Yos  wrote:

> On 05/11/2012 16:02, Nabil Maynard wrote:
>
>> Personally, I like having a "Postponed"/"Later" resolution at least
>> available.
>>
>> WONTFIX = We acknowledge this is a valid bug, but are choosing not to fix
>> it due to time and resources necessary to fix it.  We will not be
>> revisiting this bug unless it is re-raised by others.
>> LATER = We acknowledge this is a valid bug, and we agree that it should be
>> fixed, but don't have time right now.  We will be voluntarily revisiting
>> this soon.
>>
> If that's what later means, then why mark it at all? These are big
> projects, and are others or even newcomers later who may indeed have the
> time, so why remove that option from everyone?
>
> Open bugs don't hurt anything, do they?
>
> --
> -— Isarra
>
>
>
> __**_
> 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] Dropping "My …" prefix from toolbar labels

[Steven Walling]

On Sun, Nov 4, 2012 at 6:50 PM, Trevor Parscal wrote:

> I've supported this change for a very long time, glad to see it's on the
> table.
>
> +1
>

To quote James F. from the bug:

Code change merged and presumably will be deployed from wmf4 branch:
https://gerrit.wikimedia.org/r/#/c/31605/

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

Re: [Wikitech-l] About RESOLVED LATER

[Isarra Yos]

On 05/11/2012 16:02, Nabil Maynard wrote:

Personally, I like having a "Postponed"/"Later" resolution at least
available.

WONTFIX = We acknowledge this is a valid bug, but are choosing not to fix
it due to time and resources necessary to fix it.  We will not be
revisiting this bug unless it is re-raised by others.
LATER = We acknowledge this is a valid bug, and we agree that it should be
fixed, but don't have time right now.  We will be voluntarily revisiting
this soon.
If that's what later means, then why mark it at all? These are big 
projects, and are others or even newcomers later who may indeed have the 
time, so why remove that option from everyone?


Open bugs don't hurt anything, do they?

--
-— Isarra


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

Re: [Wikitech-l] About RESOLVED LATER

[Nabil Maynard]

Personally, I like having a "Postponed"/"Later" resolution at least
available.

WONTFIX = We acknowledge this is a valid bug, but are choosing not to fix
it due to time and resources necessary to fix it.  We will not be
revisiting this bug unless it is re-raised by others.
LATER = We acknowledge this is a valid bug, and we agree that it should be
fixed, but don't have time right now.  We will be voluntarily revisiting
this soon.

While we could arguably just dump both situations into WONTFIX, I think
that would muddy the triage process pretty heavily, making it more
difficult to track bugs we intend to revisit.

That said, it IS easy for LATER to become a procrastination paradise, where
it gets resolved and then never thought of again.  Would it be worthwhile
to set up an automated notice when a LATER bug ages past a certain date
(say, a month without being touched), instead of axing the resolution?

Thanks,
Nabil



On Mon, Nov 5, 2012 at 2:29 PM, Diederik van Liere
wrote:

> Hi,
>
> I made the exact same argument a while back (Dropping the LATER resolution
> in Bugzilla
>
> http://wikimedia.7.n6.nabble.com/Dropping-the-LATER-resolution-in-Bugzilla-td743804.html
> )
> +1
> D
>
>
> On Mon, Nov 5, 2012 at 5:25 PM, Quim Gil  wrote:
>
> > I was a bit of a lazy child, specially when it came to clean up my room
> or
> > do my homework. I tried to convince my mom and teachers about the
> paradigm
> > of RESOLVED LATER, but they never bought it. At the end I had to clean up
> > my room and do my homework.
> >
> > Even as a child I suspected that they were actually right. If something
> > has been postponed for later it can't be called "resolved". Now it's me
> who
> > hears from time to time excuses from my kids that sound more or less like
> > RESOLVED LATER. "Yeah, sure", I tell them, pointing to the source of
> > pending work.  :)
> >
> > And now to the topic:
> >
> > What about removing the LATER resolution from our Bugzilla? It feels like
> > sweeping reports under the carpet. If a team is convinced that something
> > won't be addressed any time soon then they can WONTFIX. If anybody feels
> > differently then they can take the report back and fix it.
> >
> > Before we could simply reopen the 311 reports filed under RESOLVED LATER:
> >
> > http://bit.ly/YxW60z
> >
> > Huggle  1
> > MediaWiki   74
> > MediaWiki extensions104
> > Monuments database  1
> > mwEmbed 3
> > Parsoid 1
> > Tools   2
> > WikiLoves Monuments Mobile  4
> > Wikimedia   114
> > Wikimedia Labs  1
> > Wikimedia Mobile3
> > Wikipedia App   3
> > Total   311
> >
> >
> > Looking at the total amount of open bugs, the impact is not that big. The
> > house will be as tidy/untidy as before, but at least things wll be
> clearer
> > now.
> >
> > What do you think?
> >
> > --
> > Quim
> >
> > __**_
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/**mailman/listinfo/wikitech-l<
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l>
> >
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] About RESOLVED LATER

[Platonides]

How many of them depend on action from somebody else?
(eg. upstream fixing its tool)

Of course, if we are waiting for upstream, it should list the upstream
bug id, have upstream keyword, someone actually noticing when it's
fixed, etc.  but those are form issues, not the status.
(and yes, 'resolved' is a misnomer)

Bug tracking software should be able to communicate between themselves
to automatically open and close its bugs when they have dependencies.


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

Re: [Wikitech-l] About RESOLVED LATER

[Diederik van Liere]

Hi,

I made the exact same argument a while back (Dropping the LATER resolution
in Bugzilla
http://wikimedia.7.n6.nabble.com/Dropping-the-LATER-resolution-in-Bugzilla-td743804.html
)
+1
D


On Mon, Nov 5, 2012 at 5:25 PM, Quim Gil  wrote:

> I was a bit of a lazy child, specially when it came to clean up my room or
> do my homework. I tried to convince my mom and teachers about the paradigm
> of RESOLVED LATER, but they never bought it. At the end I had to clean up
> my room and do my homework.
>
> Even as a child I suspected that they were actually right. If something
> has been postponed for later it can't be called "resolved". Now it's me who
> hears from time to time excuses from my kids that sound more or less like
> RESOLVED LATER. "Yeah, sure", I tell them, pointing to the source of
> pending work.  :)
>
> And now to the topic:
>
> What about removing the LATER resolution from our Bugzilla? It feels like
> sweeping reports under the carpet. If a team is convinced that something
> won't be addressed any time soon then they can WONTFIX. If anybody feels
> differently then they can take the report back and fix it.
>
> Before we could simply reopen the 311 reports filed under RESOLVED LATER:
>
> http://bit.ly/YxW60z
>
> Huggle  1
> MediaWiki   74
> MediaWiki extensions104
> Monuments database  1
> mwEmbed 3
> Parsoid 1
> Tools   2
> WikiLoves Monuments Mobile  4
> Wikimedia   114
> Wikimedia Labs  1
> Wikimedia Mobile3
> Wikipedia App   3
> Total   311
>
>
> Looking at the total amount of open bugs, the impact is not that big. The
> house will be as tidy/untidy as before, but at least things wll be clearer
> now.
>
> What do you think?
>
> --
> Quim
>
> __**_
> 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] MW 1.20 release tomorrow

[Mark A. Hershberger]

I said last week that I would be releasing 1.20 today.  Due to some
hiccups, I won't be able to do that.  I'll work on the release tonight
and prep it for tomorrow.

Thank you for your patience,

Mark.


-- 
http://hexmode.com/

Any time you have "one overriding idea", and push your idea as a
superior ideology, you're going to be wrong. ... The fact is,
reality is complicated -- Linus Torvalds 

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

Re: [Wikitech-l] want to contribute

[Harsh Kothari]

Hi Quim

Thanks for your response. Now How can I fix this bug?

Harsh
---
Harsh Kothari
Research Fellow, 
Physical Research Laboratory(PRL).
Ahmedabad.


On 05-Nov-2012, at 11:24 PM, Quim Gil wrote:

> Hi Harsh!
> 
> On 11/04/2012 10:00 AM, Harsh Kothari wrote:
>> Hello all
>> 
>> I am Harsh Kothari from Gujarat, India. I want to contribute. I am
>> more active on Gujarati Wikipedia. More then 3k+ edits are there and
>> I have also made some wikibot scripts for doing various work on
>> Gujarati Wikipedia. I want to solve bugs, create new scripts for
>> Gujarati as well as English. So How can I start? I am expert in java
>> script and python and very good knowledge of php, Json, Xml etc. So
>> please guide me how can I start. How I can solve the bugs?
> 
> The first step is to find the right bug for you to start. The great news is 
> that we have plenty of open bugs for all profiles and tastes.  ;)
> 
> Play with the advanced search in our Bugzilla. It will also help you 
> understand the projects going on and the priorities that the current 
> developers have set for bugs. Starting with low priority bugs is a good 
> thing, because then you have the luxury to change your mind without much 
> consequences, and make a difference if you do succeed.
> 
> https://bugzilla.wikimedia.org/query.cgi?format=advanced
> 
> Have in mind that Gujarati Wikipedia not only carries bugs relative to 
> Gujarati, but implicitly any bugs present in the MediaWiki engine and the 
> extensions in use. Think also in the mobile implementation, which I bet are 
> relevant in a country like India.
> 
> I did a search and I found this one, as an example:
> 
> Show English search result if none in other language
> https://bugzilla.wikimedia.org/show_bug.cgi?id=32541
> 
> Imagine Gujarati mobile users being able to search and get results at least 
> in English, if a Gujarati version doesn't exist. Makes sense to me, and it 
> seems that the first one suggesting this idea was no less than Vodafone India.
> 
> Of course you can go for any other bug you prefer.
> 
> 
>> Thanks in advance
> 
> Thank YOU in advance for asking.  :)
> 
> --
> Quim
> 
> ___
> 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] want to contribute

[Quim Gil]

Hi Harsh!

On 11/04/2012 10:00 AM, Harsh Kothari wrote:

Hello all

I am Harsh Kothari from Gujarat, India. I want to contribute. I am
more active on Gujarati Wikipedia. More then 3k+ edits are there and
I have also made some wikibot scripts for doing various work on
Gujarati Wikipedia. I want to solve bugs, create new scripts for
Gujarati as well as English. So How can I start? I am expert in java
script and python and very good knowledge of php, Json, Xml etc. So
please guide me how can I start. How I can solve the bugs?


The first step is to find the right bug for you to start. The great news 
is that we have plenty of open bugs for all profiles and tastes.  ;)


Play with the advanced search in our Bugzilla. It will also help you 
understand the projects going on and the priorities that the current 
developers have set for bugs. Starting with low priority bugs is a good 
thing, because then you have the luxury to change your mind without much 
consequences, and make a difference if you do succeed.


https://bugzilla.wikimedia.org/query.cgi?format=advanced

Have in mind that Gujarati Wikipedia not only carries bugs relative to 
Gujarati, but implicitly any bugs present in the MediaWiki engine and 
the extensions in use. Think also in the mobile implementation, which I 
bet are relevant in a country like India.


I did a search and I found this one, as an example:

Show English search result if none in other language
https://bugzilla.wikimedia.org/show_bug.cgi?id=32541

Imagine Gujarati mobile users being able to search and get results at 
least in English, if a Gujarati version doesn't exist. Makes sense to 
me, and it seems that the first one suggesting this idea was no less 
than Vodafone India.


Of course you can go for any other bug you prefer.



Thanks in advance


Thank YOU in advance for asking.  :)

--
Quim

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

[Wikitech-l] Wikimedia & MediaWiki to participate in Outreach Program for Women

[Sumana Harihareswara]

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

I've signed us up to participate in the Outreach Program for Women
(administered by the GNOME Foundation), which provides paid internships
to women to work on our open source projects, January through March
2013.  Wikimedia Foundation is willing to pay the internship stipend for
three to four participants.  More details:
https://live.gnome.org/GnomeWomen/FOSSOutreachProgram

Some reasons I think this is a good idea:

* We'll make strong connections with a few talented people who will
stick around
** We have enough mentors to do this well
* We can encourage people to work on testing, design, documentation,
marketing, and other areas as well as code
* It's a proven method for increasing the number and proportion of women
in an open source community
** GNOME started this effort a few years ago and attendance at their
yearly technical conference has improved from 4% women to 17% women
* Interns don't need to be students, so we're more accepting of age
diversity
* Instead of making newbies write fixed proposals with schedules,
internships can follow broader charters and flex to accommodate
students' interests and abilities

This week I'm taking care of the paperwork, lining up mentors (you can
sign up at [[Outreach Program for Women]]), and adding tiny tasks to
that page (in order to apply, participants have to make a small
contribution, like fixing or reproducing a bug).  Applications will open
this month.

I'll be sending out more information about this as soon as I create it. :-)

-- 
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] whether to do Google Code-In

[Sumana Harihareswara]

On 10/25/2012 03:48 AM, Mark Holmquist wrote:
> On 10/22/2012 06:31 PM, Sumana Harihareswara wrote:
>> Last year we decided not to participate in Google Code-In
>> https://www.google-melange.com/gci/document/show/gci_program/google/gci2012/help_page
>>
>> , an outreach program to help us get more 13-to-17-year-old
>> contributors.  I outlined the reasons here:
>> http://lists.wikimedia.org/pipermail/wikitech-l/2011-October/055937.html
>>
>> This year, we are again eligible to apply to participate.  I estimate
>> that we'd need about 2 organizational administrators and 21 mentors to
>> do it well.  So I've opened signups at
>> https://www.mediawiki.org/wiki/Google_Code-In and explained what those
>> people would be committing to.  If you want us to apply to participate
>> in GCI this winter, please comment on that page by November 1st. Thanks.
> 
> I wanted to ping the list again about thisour project and others
> will really benefit from having new contributors, and the tech community
> at large will benefit from the education we can help provide these
> students. And of course, it means new community members and a generally
> more informed public.
> 
> Please consider signing the list before the deadline, I'd really love to
> see this program happen. I'm willing to help a lot, but I can't do it all!
> 
> Thanks,

We weren't able to get enough mentors to sign up to do Google Code-In,
so we will not be participating.  I know this disappoints some of you;
we do want to encourage new participants, and we want some structured
mentorship that isn't just Google Summer of Code.  I will start a new
thread about a more suitable program for us to participate in. :-)

-- 
Sumana Harihareswara
Engineering Community Manager
Wikimedia Foundation

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