Talk:Team Practices Group/Measuring Types of Work

Add topic
From mediawiki.org
Latest comment: 8 years ago by JAufrecht (WMF) in topic Edge Cases

Categories A and B in "Maintenance vs New Work"[edit]

I am unclear about the current distinction between "Keeping the lights on" and "Maintenance". I am also unclear what the value would be in defining these as separate classifications. Khorn (WMF) (talk) 20:17, 17 August 2015 (UTC)Reply

Terry has a distinction for budgeting and accounting purposes but nobody has expressed any confidence about being able to tease them apart in Engineering and Terry is not objecting to our lumping A and B into a single "Maintenance" category.

Maintenance vs New work - Uncategorized[edit]

A few comments of my own about this section

  • Prototyping/Research - I don't know that I have ever seen "prototyping" that wasn't new work. Research should probably be its own line: It can easily go either way, depending on what is being researched or analyzed.
  • Tech Debt - Definitely maintenance
  • responsive correction - What is this?
  • meta-work - I'm not sure what this is either.

Khorn (WMF) (talk) 20:22, 17 August 2015 (UTC)Reply

I don't know what responsive correction is either. Meta-work to me means work about work - this discussion, planning, budgeting, estimating and forecasting; Sprint ceremonies; indirect work. Things that if you do them poorly you will fail to deliver anything, but if you only do them, you will never deliver anything.

Interrupt vs planned[edit]

I think the main characteristic of "Interrupt" is that it was a thing we didn't know we were going to have to address as an "unbreak now". Frequently, we are well aware of fragile components in the system (and have sparsely-worded cards about beefing them up in our backlog), but the rapid escalation in the severity of the problem is a surprise. On the other hand, they can also be complete surprises. The value in tracking interrupts is to be able to pad out planning estimations to account for work we didn't think we had to do deliberately at that time, whether or not those things were on the radar for a farther-off future. Khorn (WMF) (talk) 20:28, 17 August 2015 (UTC)Reply

Edge Cases[edit]

Tasks that indicate significant effort for several teams[edit]

  • Example?
  • Are there any big enough to matter?

Tracking tasks[edit]

  • Example?
  • Should be excluded from reporting

Timing of Interrupt vs main thrust[edit]

Q: For a Scrum team, would this just be "This work was added after we had locked in our tasks for this sprint", or would it also include "We have known about this for months but is not part of our main thrust"?

I think there are at least three different cases implied here: work that is added after committing scope for a sprint; work that we are doing that is not "part of our main thrust" (being done before work addressing a higher priority goal); and work that for a long time was not "part of our main thrust" but abruptly changed priority (because its goal changed priority, or because it got aligned with a different goal. 1) and 3) sound like "interrupt" to me but 2) doesn't. JAufrecht (WMF) (talk) 23:28, 2 September 2015 (UTC)Reply

New Work - for projects in maintenance vs in development[edit]

Hello, this may already have been answered but I could not find it anywhere - for Category C type work, are we talking about new features being added to projects that have been completed and in maintenance mode or just things that are in progress? In Language Engineering, we have a clear distinction between projects that are in these 2 phases (e.g. ULS in maintenance, CX in development). Projects in maintenance have type AB work and C is mostly (at present) deferred in favour of all work for the in-development project. For the project in development too we have AB work as its in use as a beta tool. Considering all AB work can be identified with one tag, we would require some distinction for C in-maintenance and on going C for in-development projects. Thanks.--Runa Bhattacharjee (WMF) (talk) 18:05, 20 August 2015 (UTC)Reply

Can you link a few specific tasks like this? JAufrecht (WMF) (talk) 18:31, 21 August 2015 (UTC)Reply
C in-development would be everything on this board and a few things related to deployment needs. Examples of C in-maintenance are phab:T104912 and phab:T70077. Thanks. --Runa Bhattacharjee (WMF) (talk) 18:55, 21 August 2015 (UTC)Reply
Are you saying that you have an project that is in maintenance mode, so you want to treat all work in it as AB without tagging individual tasks, but that if we consider new functionality to such projects as category C then tracking gets much more complicated? I guess the more general edge case here is, work that extends the functionality of an existing mature product? --JAufrecht (WMF) (talk) 23:59, 2 September 2015 (UTC)Reply

What about work required to modify existing functionality to support adding a new data center? Is that maintenance, because we're just making the existing functionality be more flexible about where it runs? Or is it new functionality, because adding a data center is a big new thing with user benefits? FWIW, I chose "new". --KSmith (WMF) (talk) 18:28, 27 August 2015 (UTC)Reply

Re: "keep search ticking"[edit]

There seems to be some non-general leftover of some previous incarnation of this advice. --Nemo 07:50, 27 August 2015 (UTC)Reply

Re: Endogenous vs Exogenous[edit]

I can't make sense of the sentence "Developers/Maintainers and Upstream_projects and who (if anyone) is tasked with fixing bugs in extensions/code that no existing team/individual is currently (officially) working on". Among other things, it lacks a main proposition. --Nemo 07:50, 27 August 2015 (UTC)Reply

How about, "Category D work is work that satisfies the needs of other developers rather than a user base; for example, collaboration where the other party is is a Mediawiki Developer or Maintainer or Upstream or Downstream development team. It might also include work on projects for which no-one is formally accountable (although this might be a distinct category).JAufrecht (WMF) (talk) 23:43, 2 September 2015 (UTC)Reply

Phabricator projects[edit]

The decision at phabricator:T109492 is quite noisy and certainly unreliable. Anyway, the descriptions of those projects refer to this page, which however doesn't seem to explain how to use them. --Nemo 07:50, 27 August 2015 (UTC)Reply

Fwd: Add support for task types[edit]

How does all this relate to T93499: Add support for task types? --Nemo 07:55, 27 August 2015 (UTC)Reply