Page MenuHomePhabricator

Create project tags for tracking maintenance-type of work
Closed, ResolvedPublic

Description

We would like to track "Maintenance Fraction", or portion of team work that is dedicated to maintenance of existing functionality vs creation of new functionality. While there are many half-answered theoretical questions around this, teams participating in the pilot would like to start tagging their stories ASAP, and continue discussing open questions while experimenting with tagging. Participating teams have agreed on the following:

  1. Of the three suggested categories ("keep the lights on", "preventative maintenance", "new functionality"), teams will not attempt to differentiate between the first two in the initial pilot, so we need to track three categories
  2. Teams will track their work by tagging tasks with a project tag, unless they already have a way to track this.
  3. To reduce effort, teams may track only one of the two categories and assume all untagged tasks are in the other category. Since some team backlogs may be biased to one category or the other, teams may want to use either tag this way, so we still need two tags.

The proposed mechanism to agree on tag names is informal discussion through the comment thread of this task. Proposed tag names to start discussion:

#CoreMaintenance
#NewProject

Broader description of project: https://www.mediawiki.org/wiki/Measuring_Types_of_Work, including links to previous discussions and directives.

Event Timeline

JAufrecht raised the priority of this task from to Needs Triage.
JAufrecht updated the task description. (Show Details)
JAufrecht added a project: Project-Admins.
JAufrecht added a subscriber: JAufrecht.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptAug 18 2015, 6:15 PM

Project descriptions welcome.

Regarding the proposed names, #Core-Maintenance and #New-Project make me pretty afraid that random reporters might tag "stuff broken in the MediaWiki core codebase that needs maintenance" and "I'm a maintainer and I want my MediaWiki extension project hosted in Wikimedia Git / want a project for it in Phabricator" with these tags...

Why not make team specific tags?
i.e. #Fr-Tech-New-Work

It would make them harder to find if you are not in that specific team.

It would make them harder to find if you are not in that specific team.

And impossible to sum up across all teams…

Why not make team specific tags?
i.e. #Fr-Tech-New-Work
It would make them harder to find if you are not in that specific team.

Hmm, I'm not sure how being a member of that team is relevant? Could you elaborate? :)
(To make projects harder to find I'd rather recommend not using dashes or spaces in project names as Phabricator uses them to split search tokens. If that was really wanted.)

greg added subscribers: greg, demon.Aug 18 2015, 11:53 PM

Not a fan of team/project specific tags here (and you can use queries to limit your searches/workboards to only those in your team/project, if wanted).

I'm fine with WorkTypeMaintenance and WorkTypeNewFunctionality

I prefer not using 'Project' in the tag name and prefer keeping it to 'Feature' or 'Functionality' because some tasks may not be big enough to make it into the Master Project List.

as for @ksmith's suggestion, how about re-ordering the words to be a little more readable:
#MaintenanceTypeWork and #NewFunctionalityTypeWork

Arrbee added a subscriber: Arrbee.Aug 19 2015, 5:19 AM
Dzahn added a subscriber: Dzahn.Aug 19 2015, 5:19 AM

It's actually more readable if the wider category (WorkType) is first and the specific type (maintenance or new functionaly) is second.

It would make them harder to find if you are not in that specific team.

And impossible to sum up across all teams…

What would you "sum" up? You can't compare estimates or effort across teams. I don't want anyone attempting this with FR-tech data. Please see me offline if you have questions.

It would make them harder to find if you are not in that specific team.

And impossible to sum up across all teams…

What would you "sum" up? You can't compare estimates or effort across teams.

Nonsense. If you have a team with 5 FTEs and 40% of your resource is spent on Type 1 work and 60% on Type 2, and another with 3 FTEs and a 50:50 split, then that's trivially comparable. The entire point of this exercise is to compare teams for resourcing considerations, right? If we can't compare we might as well just close this task as Declined.

It would make them harder to find if you are not in that specific team.

And impossible to sum up across all teams…

What would you "sum" up? You can't compare estimates or effort across teams.

Nonsense. If you have a team with 5 FTEs and 40% of your resource is spent on Type 1 work and 60% on Type 2, and another with 3 FTEs and a 50:50 split, then that's trivially comparable. The entire point of this exercise is to compare teams for resourcing considerations, right? If we can't compare we might as well just close this task as Declined.

But you can't pull estimates from one team and compare them to another team. Querying all tasks of a certain type across multiple teams doesn't give you anything useful.

Each team will have to calculate the percentages relative to all of their work.

Okay, I propose that we proceed with #WorkTypeMaintenance and #WorkTypeNewFunctionality. Given the non-zero amount of discussion, and the ease of changing this later, I'm passing this on to Andre to implement without further discussion (barring hollers of disagreement).

Followup clarification - I think the "will we sum up by tag across team" discussion is a side issue that does not affect the original purpose of the tags, which is to report on Maintenance fraction. The argument for per-team tags is to discourage accidental misuse of the tags for other purposes, and that is mitigated with the "WorkType" prefix.

Hi, I added a comment on the talk page but seems like this is the appropriate place to get answers. There is an edge case (see previous link) for the Language team and some insights would be really helpful. Thanks.

Can we have dashes so these are somewhat readable? WorkType-Maintenance and WorkType-NewFunctionality?

I added WorkType-Maintenance and WorkType-NewFunctionality as alternate hashtags, for easier autocomplete.

I would also be fine if the projects were officially renamed to have dashes.

Anybody is free to rename. :)
Dashes make it easier to find for those who don't type "WorkType" but potentially also for folks who will request random NewFunctionality or Maintenance work (see T109492#1550230). ;)

Nemo_bis added a subscriber: Nemo_bis.

This very report is an example of paperwork/"maintenance".

Is the WorkType-NewFunctionality basically the same what "enhancement" severity or "[Feature request] in summary" used to be in Bugzilla?

Restricted Application added a subscriber: StudiesWorld. · View Herald TranscriptFeb 14 2016, 2:59 AM
greg added a comment.Feb 14 2016, 4:06 AM

No, not really. It's mostly for teams to track the proportion of work spent
in maintenance versus doing "new" work.

It's part of https://www.mediawiki.org/wiki/Team_Practices_Group/Tracking_core_and_strategic_work. It's the output of the pilot attempt to measure this information, https://www.mediawiki.org/wiki/Team_Practices_Group/Measuring_Types_of_Work, in which we ended up with two categories, "New Functionality" and "Maintenance". The current names for the categories to track are "Core" and "Strategic", raising the question of whether we should rename the existing two tags or create new ones.

Thanks, I just wanted to find out if suggested new tag #Feature-Request was not a duplicate to this.

Thanks, I just wanted to find out if suggested new tag #Feature-Request was not a duplicate to this.

I can't (any longer) find the report/place where such proposal was made.
https://www.mediawiki.org/w/index.php?title=User_talk%3ADanny_B.&type=revision&diff=2076268&oldid=220880

demon removed a subscriber: demon.Mar 14 2016, 2:55 PM
Dzahn removed a subscriber: Dzahn.Mar 15 2016, 7:29 PM