+1
I'd prefer to see quality be a perpetually ongoing effort over a
periodic burst. I'd like to see management rotate people into "quality
mode" by explicitly setting goals and deliverables around addressing it.
The problem in the past has been this notion of "greatest impact".
Things like refactorings and fixing tests always get deprioritized
because it's really hard to estimate how beneficial they are to the
overall mission. It was much easier to say shiny new feature X aligns
nicely with our top-line goals.
Well, finally, our top-line goal is to "build core strength". To me that
means that fixing tests and quality *now have the greatest impact*, and
everyone's deliverables should reflect this new reality.
-Andrew
On 22/12/15 11:40 AM, Bobby Holley wrote:
Do we actually need to have everybody working on oranges / quality at once?
Shouldn't we just prioritize it (probably permanently) in a way such that
_some_ members of every team are working on it?
Saying "everybody needs to work on this together" is a socially expedient
way of getting volunteers to do things, but we have a large paid staff and
management/planning structure that is designed to direct some of our
resources to walking and some of them to chewing gum.
Last spring I worked on media quality while other people worked on
features. It went great, and there was far less coordination overhead than
if everyone was trying to work on the same thing.
bholley
On Tue, Dec 22, 2015 at 8:32 AM, Mike Conley <mcon...@mozilla.com> wrote:
You had me at "quality". :)
On 22/12/2015 11:16 AM, Douglas Turner wrote:
Mike -- totally supportive of this. I would *love* to see a release
cycle completely dedicated to quality. We branch again on January 26.
We could use that cycle to focus on nothing but quality (fixing tests,
bug triaging, no feature development at all).
Thoughts?
On Tue, Dec 22, 2015 at 7:41 AM Mike Conley <mcon...@mozilla.com
<mailto:mcon...@mozilla.com>> wrote:
I would support scheduled time[1] to do maintenance[2] and help
improve our
developer tooling and documentation. I'm less sure how to integrate
such a
thing in practice.
[1]: A day, a week, heck maybe even a release cycle
[2]: Where maintenance is fixing oranges, closing out papercuts,
refactoring, etc.
On 21 December 2015 at 17:35, <jmath...@mozilla.com
<mailto:jmath...@mozilla.com>> wrote:
> On Monday, December 21, 2015 at 1:16:13 PM UTC-6, Kartikaya Gupta
wrote:
> > So, I propose that we create an orangefactor threshold above
which the
> > tree should just be closed until people start fixing intermittent
> > oranges. Thoughts?
> >
> > kats
>
> How about regularly scheduled test fix days where everyone drops
what they
> are doing and spends a day fixing tests? mc could be closed to
everything
> except critical work and test fixes. Managers would be able to opt
> individuals out of this as needed but generally everyone would be
expected
> to take part.
>
> Jim
> _______________________________________________
> dev-platform mailing list
> dev-platform@lists.mozilla.org <mailto:
dev-platform@lists.mozilla.org>
> https://lists.mozilla.org/listinfo/dev-platform
>
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org <mailto:
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
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
