On Tue, Aug 11, 2015 at 10:40 AM, Kevin Smith wrote:
>
> On Mon, Aug 10, 2015 at 10:20 AM, Bryan Davis wrote:
>>
>> This "burden" is not unique to the WMF or FLOSS systems. This is one
>> of the reasons that a typical software development organization with
>> stable funding grows its developer te
To me, the basic problem is that all these classifications are based on
relatively subjective judgments of what is good (vs. debt), necessary or
optional. Reasonable people can and do disagree on this.
To establish meaningful numbers, we would need to classify work with a
reasonably uniform set of
Just to throw my 2 cents in here.
I am a huge fan for data analysis and categorization of work. It empowers
us to make more informed decisions.
I'm objectively opposed to apriori buffering or assumed capacity for
certain amounts of work. There have been some comments on the thread about
how much
On Mon, Aug 10, 2015 at 10:20 AM, Bryan Davis wrote:
> I think I would personally invert Kevin's assertion and say that most
> teams are (or should be) spending a non-trivial amount of time
> performing both maintenance and responsive correction work. Hopefully
> this doesn't rise above a reasona
On Mon, Aug 10, 2015 at 10:44 AM, Katie Horn wrote:
>
> I think we can safely assume that any team that relies on any kind of third
> party integration for one or more of their features to continue working,
> will have some degree of the same situation.
I think I'd agree and then point out that M
Speaking just for Fundraising Tech:
If you define maintenance as anything you have to do to preserve key
functionality you already have, most of the work we do is easily qualified
as maintenance.
Our main focus is on maintaining integrations with third party payment
processors, and those third pa
On Fri, Aug 7, 2015 at 1:55 PM, Greg Grossmeier wrote:
> Whereas I think RelEng is probably[0] closer to only 20% in "new".
>
RelEng and Ops are the groups that to me are pretty obviously heavily
weighted toward "keep the lights on" and "maintain in the face of external
forces (e.g. upgrades)".
> On 7 August 2015 at 13:14, Greg Grossmeier wrote:
> >
> > I think the Discovery team could be much more easily categorized in with
> > the mobile apps teams vs in with Editing or any team in Infrastructure
> > :)
> >
>
> Interesting. Why do you think that is?
I think you can answer it best :)
On 7 August 2015 at 13:14, Greg Grossmeier wrote:
>
> I think the Discovery team could be much more easily categorized in with
> the mobile apps teams vs in with Editing or any team in Infrastructure
> :)
>
Interesting. Why do you think that is?
Dan
--
Dan Garry
Lead Product Manager, Discovery
On Fri, Aug 7, 2015 at 1:14 PM, Greg Grossmeier wrote:
> I think the Discovery team could be much more easily categorized in with
> the mobile apps teams vs in with Editing or any team in Infrastructure
Sometimes. There are elastic search upgrades, capacity planning, and
dealing with the occasion
> On Fri, Aug 7, 2015 at 12:17 PM, James Forrester
> wrote:
>
> > On 7 August 2015 at 11:57, Kevin Smith wrote:
> >
> >> And (and this is the main point of this email), for most software
> >> development teams, "keep the lights on" should be near zero, right? So
> >> effectively most of the tea
On 7 August 2015 at 12:41, Kevin Smith wrote:
>
> I also go back to the "bug vs. feature" distinction. Discovery is spending
> a lot of time improving search. Is that maintenance, or new features? I'm
> saying it's new features, because it is innovation aimed at meeting a
> quarterly goal.
>
I ag
Understood. Thanks for the clarification, Joel and Terry.
Dan
On 7 August 2015 at 11:40, Terence Gilbey wrote:
> The only thing I have to add is "What Joel said".. as he made the
> case more eloquently than I do..
>
> On Fri, Aug 7, 2015 at 11:00 AM, Joel Aufrecht
> wrote:
>
>> I'm not
On Fri, Aug 7, 2015 at 12:17 PM, James Forrester
wrote:
> On 7 August 2015 at 11:57, Kevin Smith wrote:
>
>> And (and this is the main point of this email), for most software
>> development teams, "keep the lights on" should be near zero, right? So
>> effectively most of the teams we work with w
On 7 August 2015 at 11:57, Kevin Smith wrote:
> For most software development teams, there should be some (hopefully not
> too much) maintenance, and the bulk of the effort (in theory) should go
> toward new functionality.
>
> And (and this is the main point of this email), for most software
> de
For most software development teams, there should be some (hopefully not
too much) maintenance, and the bulk of the effort (in theory) should go
toward new functionality.
And (and this is the main point of this email), for most software
development teams, "keep the lights on" should be near zero,
The only thing I have to add is "What Joel said".. as he made the case
more eloquently than I do..
On Fri, Aug 7, 2015 at 11:00 AM, Joel Aufrecht
wrote:
> I'm not certain I understand the need to draw a distinction between
>> maintenance and new work. I prefer to think purely in terms of wh
>
> I'm not certain I understand the need to draw a distinction between
> maintenance and new work. I prefer to think purely in terms of what work is
> the most strategic in terms of achieving our mission; for the purposes of
> that, whether work is "maintenance work" or "new work" is irrelevant, a
On 5 August 2015 at 14:33, Greg Grossmeier wrote:
>
> From the notes of our Quarterly Review in July:
>
> ---quote---
> ==All infrastructure teams, in future quarterly reviews==
> --> Lila: for all teams: assess how much of your time goes to:
> * supporting others
> * new projects
> * prototyping
I would guess that it is also related to
https://www.mediawiki.org/wiki/Developers/Maintainers
and https://www.mediawiki.org/wiki/Upstream_projects
and who (if anyone) is tasked with fixing bugs in extensions/code that no
existing team/individual is currently (officially) working on.
On Wed, Aug 5
> I'm not certain I understand the need to draw a distinction between
> maintenance and new work. I prefer to think purely in terms of what work is
> the most strategic in terms of achieving our mission; for the purposes of
> that, whether work is "maintenance work" or "new work" is irrelevant, as
On 5 August 2015 at 12:10, Greg Grossmeier wrote:
>
> Are there any teams at WMF who already have these two buckets defined?
> What are your definitions?
>
Things like restarting the ElasticSearch cluster, and upgrading the
ElasticSearch cluster, are maintenance work for my team. I guess the
crit
Distinguishing between "maintenance" and "new" work seems very gray to me.
Roughly as gray as "bug" vs. "improvement".
I guess a working definition for us right now might be: Either it's part of
a project in the MPL, or it is "maintenance", or there's a reasonable
chance you shouldn't be doing it.
Following on to Joel's message about "interrupt" work, I'd like to start
a thread on maintenance vs new work.
Context: In the last round of quarterly reviews it was requested that
teams be prepared to give an idea of the proportion of work that falls
into "maintenance" vs "new work".
Now, the har
24 matches
Mail list logo
