On Tue, Dec 29, 2015 at 11:41 AM, Steve Fink <sf...@mozilla.com> wrote:

> On 12/22/2015 10:06 AM, L. David Baron wrote:
>
>> On Tuesday 2015-12-22 11:49 -0500, Ehsan Akhgari wrote:
>>
>>> On 2015-12-22 11:18 AM, Kartikaya Gupta wrote:
>>>
>>>> On Mon, Dec 21, 2015 at 3:11 PM, L. David Baron <dba...@dbaron.org>
>>>> wrote:
>>>>
>>>>> I agree it's definitely gone up recently, and agree that it causes a
>>>>> lot of wasted time.  I'm not convinced about closing the tree,
>>>>> though; keeping the tree closed for extended periods just leads to
>>>>> big backups.
>>>>>
>>>>> How about everybody reading this message takes a look at the list on
>>>>> http://brasstacks.mozilla.com/orangefactor/ and takes one of them to
>>>>> fix?  (Or, better, redoes the search filtered on the last 3 days
>>>>> instead of last 7.)
>>>>>
>>>>
>>>> I feel like a voluntary approach is likely to have very little effect,
>>>> given the way our goals and priorities are structured. There's very
>>>> little incentive to voluntarily spend time banging your head against a
>>>> wall. That's why I'm more in favor of a forced approach that is
>>>> mandated by managers/product owners/sheriffs (i.e. people who can
>>>> actually tell us to some extent what to do).
>>>>
>>> I have tried to volunteer some time from my weekends occasionally to look
>>> into the most recurring oranges every few weeks, and usually every time I
>>> manage to figure out a handful of bugs by spending a few hours and as a
>>> result OF would go down in the following week, but then it would go back
>>> up
>>> again.  This is a demotivating task and doesn't really scale to the
>>> magnitude of our orange problem.  I agree with kats that a voluntary
>>> based
>>> approach will not go anywhere.
>>>
>> Managers should definitely be supporting this, and sheriffs (and
>> anybody else with push access) should be backing things out for
>> causing intermittent oranges (even if that's not discovered until
>> days/weeks later).
>>
>> If people don't feel they can fix intermittent oranges during the
>> business day as part of their job, that's a problem.
>>
>
> Hm... it seems like you could take that further. Fixing oranges could be
> considered to be going "above and beyond" your normal responsibilities
> (unless you're just fixing your own!). So for employees, you could convert
> N hours of orange-fixing into up to M hours of additional PTO whenever the
> orange factor > k. :-) If intermittent orange is indeed a large
> project-wide drag on resources (and I believe it is), then the M+N hours of
> regular work "lost" in this way should be more than compensated for by the
> reduced overhead on everyone.
>
> Just a thought from someone who wouldn't have to work through the details.
> And it's crazy enough already that I won't mention the tacked-on idea that
> if unpaid contributors spend time fixing oranges, then we'd send them free
> graphics hardware of the sorts that we have low pre-release coverage on,
> with no strings attached other than "if you give this away, please don't
> remove the sticker that says 'You can help Firefox! Just switch to the beta
> release channel! This card is worth 42 points on Mozilla's Hardware
> Diversity Scoreboard.'")... ;-)
>
> But I don't think having mozilla-inbound/mozilla-central be closed
>> more than it already is is going to help anything.  It will just
>> make people frustrated that they can't land what they've been
>> working on.
>>
>
> Amen. Trying to artificially force this stuff is going in the wrong
> direction. After all, you'd be reducing productivity from the top-down in
> order to improve productivity. It might work, it might not, it might help
> for a while but have long-term negative consequences.
>
> Personally, I feel like getting farther away from our volunteer-driven
> roots is dangerous. Sure, we have lots of paid staff now, but you really
> don't want any more selection pressure to push the overall contributor base
> towards people who are involved for the money and away from people who are
> motivated by the mission.


I don't follow the concerns in this last part. Can you clarify which
proposal you're concerned will take us farther from our volunteer-driven
roots? The part about ordering paid staff to do unpleasant-but-necessary
things, or something else?


>
> _______________________________________________
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Reply via email to