Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Wikipedia: Wikitech

A balanced approach to 20% time

 

 

Wikipedia wikitech RSS feed   Index | Next | Previous | View Threaded


robla at wikimedia

Apr 12, 2012, 1:56 PM

Post #1 of 2 (264 views)
Permalink
A balanced approach to 20% time

Hi everyone,

I'm forking off from the "Development process doesn't work" thread to
highlight a message that Sumana sent the other day.

Last year, Erik asked me to manage the 20% policy time that has frequently
been referenced here. Prior to the Git migration, I've made a point of
emphasizing code review, because we had a pretty large backlog, and the
consequences of falling behind there were more severe than letting other
things slide.

The goal of the 20% policy has always been to have a bounded but
appropriately large time set aside for supporting volunteer development and
high priority bugfixing. Now that we're on Git, and more specifically, now
that we're doing pre-commit review, there are a number of activities that
we can afford to bump up the priority on. They include:
* Reviewing extensions for deployment
* Deploying extensions
* Patches in Bugzilla
* Bugfixing problems outside of developers' focus areas
* Shell requests
* (possibly in the glorious future) pull requests issued in mirrors (e.g.
Github, Gitorious, etc)

That's a simplified version. A more complete view is here:
https://www.mediawiki.org/wiki/Wikimedia_engineering_20%25_policy#Scope

I've handed the baton off to Sumana to manage 20% time on behalf of the
community, a point that was included in her message below, but may have
been missed. We need to look at the totality of volunteer development
activity, plus take a look at high priority bug fixing on behalf of the
reader and editor community, and coordinate our approach in addressing
those issues. That's what I've asked Sumana to do, which is reflected in
her message below. If you haven't already read this, please do.

Thanks
Rob
---------- Forwarded message ----------
From: Sumana Harihareswara <sumanah [at] wikimedia>
Date: Tue, Apr 10, 2012 at 5:02 AM
Subject: Re: [Wikitech-l] Development process doesn't work (yes this is
another complaint from another community member)
To: Wikimedia developers <wikitech-l [at] lists>


On 04/04/2012 09:14 AM, Sumana Harihareswara wrote:
> Petr:
>
> My sympathies on the frustration. First I'm going to talk about the
> problem in general, then about your issue.

I can't tell whether anyone read my message on the 4th. I know it was
long, but that's because I was addressing pretty much all the open
questions at the time. :-) If you have concerns about this issue,
please do read it.

Petr replied to me offlist to straighten out his particular situation.
It sounds like for one of his extensions the ball is in his court, and
for the other (OnlineStatusBar), it's in the WMF's.

I've updated three pages to clarify and document our process:
* https://www.mediawiki.org/wiki/Writing_an_extension_for_deployment now
explains that I'm the point of contact to get extensions authors their
initial technical design reviews, Howie Fung is their contact to get
initial user experience design reviews, and the release manager is their
contact to get reviewed code deployed.

* https://www.mediawiki.org/wiki/Review_queue now has the status of each
extension; about 8 are waiting for more WMF work, and 9 are waiting for
responses from extension authors.

* https://www.mediawiki.org/wiki/Deployment_queue

So I need to get some user experience reviews and some technical/code
reviews going for the 8 extensions that are awaiting more WMF work. Tim
suggested that it might be more efficient and pleasant if WMF engineers
could concentrate on one project each for their 20% community service
time, and RobLa has now decided that I should be the one prioritizing
and allocating 20%-time responsibilities. So I'm going to be asking
some WMF engineers if they could switch from doing patch review (in
Gerrit) to reviewing particular extensions, for their 20% days. I have
a few people in mind.

Another snag, in at least one case, was that WMF engineers are unclear
on who qualifies for deployment privileges and how to get them. That's
something we started talking about in December in
http://lists.wikimedia.org/pipermail/wikitech-l/2011-December/thread.html#56982
and that still needs followup - I believe Ian is going to put some
preliminary notes on mediawiki.org soon, and Platform Engineering
(specifically RobLa & I) will follow up on that.

Hope this helps.

--
Sumana Harihareswara
Volunteer Development Coordinator
Wikimedia Foundation

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


benapetr at gmail

Apr 12, 2012, 9:54 PM

Post #2 of 2 (259 views)
Permalink
Re: A balanced approach to 20% time [In reply to]

It's nice to see that you are working on fixing this problem! Thanks

On Thu, Apr 12, 2012 at 10:56 PM, Rob Lanphier <robla [at] wikimedia> wrote:
> Hi everyone,
>
> I'm forking off from the "Development process doesn't work" thread to
> highlight a message that Sumana sent the other day.
>
> Last year, Erik asked me to manage the 20% policy time that has frequently
> been referenced here.  Prior to the Git migration, I've made a point of
> emphasizing code review, because we had a pretty large backlog, and the
> consequences of falling behind there were more severe than letting other
> things slide.
>
> The goal of the 20% policy has always been to have a bounded but
> appropriately large time set aside for supporting volunteer development and
> high priority bugfixing. Now that we're on Git, and more specifically, now
> that we're doing pre-commit review, there are a number of activities that
> we can afford to bump up the priority on.  They include:
> *  Reviewing extensions for deployment
> *  Deploying extensions
> *  Patches in Bugzilla
> *  Bugfixing problems outside of developers' focus areas
> *  Shell requests
> *  (possibly in the glorious future) pull requests issued in mirrors (e.g.
> Github, Gitorious, etc)
>
> That's a simplified version.  A more complete view is here:
> https://www.mediawiki.org/wiki/Wikimedia_engineering_20%25_policy#Scope
>
> I've handed the baton off to Sumana to manage 20% time on behalf of the
> community, a point that was included in her message below, but may have
> been missed.  We need to look at the totality of volunteer development
> activity, plus take a look at high priority bug fixing on behalf of the
> reader and editor community, and coordinate our approach in addressing
> those issues.  That's what I've asked Sumana to do, which is reflected in
> her message below.  If you haven't already read this, please do.
>
> Thanks
> Rob
> ---------- Forwarded message ----------
> From: Sumana Harihareswara <sumanah [at] wikimedia>
> Date: Tue, Apr 10, 2012 at 5:02 AM
> Subject: Re: [Wikitech-l] Development process doesn't work (yes this is
> another complaint from another community member)
> To: Wikimedia developers <wikitech-l [at] lists>
>
>
> On 04/04/2012 09:14 AM, Sumana Harihareswara wrote:
>> Petr:
>>
>> My sympathies on the frustration.  First I'm going to talk about the
>> problem in general, then about your issue.
>
> I can't tell whether anyone read my message on the 4th. I know it was
> long, but that's because I was addressing pretty much all the open
> questions at the time. :-)  If you have concerns about this issue,
> please do read it.
>
> Petr replied to me offlist to straighten out his particular situation.
> It sounds like for one of his extensions the ball is in his court, and
> for the other (OnlineStatusBar), it's in the WMF's.
>
> I've updated three pages to clarify and document our process:
> * https://www.mediawiki.org/wiki/Writing_an_extension_for_deployment now
> explains that I'm the point of contact to get extensions authors their
> initial technical design reviews, Howie Fung is their contact to get
> initial user experience design reviews, and the release manager is their
> contact to get reviewed code deployed.
>
> * https://www.mediawiki.org/wiki/Review_queue now has the status of each
> extension; about 8 are waiting for more WMF work, and 9 are waiting for
> responses from extension authors.
>
> * https://www.mediawiki.org/wiki/Deployment_queue
>
> So I need to get some user experience reviews and some technical/code
> reviews going for the 8 extensions that are awaiting more WMF work.  Tim
> suggested that it might be more efficient and pleasant if WMF engineers
> could concentrate on one project each for their 20% community service
> time, and RobLa has now decided that I should be the one prioritizing
> and allocating 20%-time responsibilities.  So I'm going to be asking
> some WMF engineers if they could switch from doing patch review (in
> Gerrit) to reviewing particular extensions, for their 20% days.  I have
> a few people in mind.
>
> Another snag, in at least one case, was that WMF engineers are unclear
> on who qualifies for deployment privileges and how to get them.  That's
> something we started talking about in December in
> http://lists.wikimedia.org/pipermail/wikitech-l/2011-December/thread.html#56982
> and that still needs followup - I believe Ian is going to put some
> preliminary notes on mediawiki.org soon, and Platform Engineering
> (specifically RobLa & I) will follow up on that.
>
> Hope this helps.
>
> --
> Sumana Harihareswara
> Volunteer Development Coordinator
> Wikimedia Foundation
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l [at] lists
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l [at] lists
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

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

Wikipedia wikitech RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.