Page MenuHomePhabricator

Create technical-debt project
Closed, ResolvedPublic

Description

Name: technical-debt
Type of project: Tag
Description:

Technical debt (also known as design debt[1] or code debt) is a recent metaphor referring to the eventual consequences of poor system design, software architecture or software development within a codebase. The debt can be thought of as work that needs to be done before a particular job can be considered complete or proper. If the debt is not repaid, then it will keep on accumulating interest, making it hard to implement changes later on. Unaddressed technical debt increases software entropy. - https://en.wikipedia.org/wiki/Technical_debt
Examples: Missing unit tests, duplicate code.

Event Timeline

JanZerebecki raised the priority of this task from to Needs Triage.
JanZerebecki updated the task description. (Show Details)
JanZerebecki added a project: Project-Admins.
JanZerebecki changed Security from none to None.
Reedy renamed this task from create technical-dept to create technical-debt.Nov 25 2014, 3:10 PM
Reedy updated the task description. (Show Details)
Tgr added a subscriber: Tgr.Nov 25 2014, 10:05 PM

+1, this would be useful. How much tech debt vs. feature work gets done is a sort of project health metric (as is the number of tech debt tickets, of course). A team might decide to spend X% of its time on working off tech debt, etc. An explicit way of marking tech debt tasks would make it much easier to track that.

Shouldn't we maybe just convert T2700 from a tracking bug into a tag project? :)

Also wondering if that means that tasks in #VisualEditor-TechnicalDebt should be moved to the generic VisualEditor project && that new Technical-Debt tag project (or whatever it will be called).
And maybe same for #MobileFrontend-Hygiene ?

Aklapper renamed this task from create technical-debt to Create technical-debt project.Nov 27 2014, 3:39 AM
Aklapper triaged this task as Low priority.
Aklapper added a project: Project-Management.

Rather than create a new project, just re-label one of the existing two and be done with it?

Qgil added a subscriber: Qgil.Nov 28 2014, 7:59 AM

+1 to renaming an existing project and consolidating the rest (tracking bug etc) around it.

+1 also on sharing a clear definition of what is and what is not "technical debt". Frequently I have heard this term in product management and management management conversations with the meaning of "old bugs and feature requests that are standing somewhere and we never had the time to address".

This "old bugs and feature requests that are standing somewhere and we never had the time to address" definitively does not describe _technical_ debt. Some specific technical debt may at the same time also be a functionality bug, but neither is a sufficient condition for the other.

See the link to en.wp in the description. do you think that does not sufficiently define the term?

Qgil added a comment.Nov 28 2014, 12:15 PM

Yes, yes, I agree with you and I am glad that we have such a good description in Wikipedia. I wasn't referring to the theoretical description but to the deviation in regular use that might occur if we don't pay attention.

This "old bugs and feature requests that are standing somewhere and we never had the time to address" definitively does not describe _technical_ debt. Some specific technical debt may at the same time also be a functionality bug, but neither is a sufficient condition for the other.
See the link to en.wp in the description. do you think that does not sufficiently define the term?

Indeed, the definition on enwiki is very badly worded. Technical debt covers "poor" decisions about code structure, but it also covers great decisions that turn out five years later to be inadequate for future needs. E.g. a reasonable technical debt bug would be "Have MediaWiki use a NoSQL rather than RDBMS back-end"; the "decision" not to use NoSQL never happened, because MediaWiki's design and creation pre-dates that technology.

Some real-world examples of types from VisualEditor: T51439 is (was) a criticism of our code that we made when we built the original; T49344 is a subsequent decision about what architecture would be better given developing needs.

Qgil raised the priority of this task from Low to Normal.Dec 1 2014, 11:54 AM

Rather than create a new project, just re-label one of the existing two and be done with it?

Should we go for renaming #VisualEditor-TechnicalDebt ?

In T75892#824439, @Qgil wrote:

Rather than create a new project, just re-label one of the existing two and be done with it?

Should we go for renaming #VisualEditor-TechnicalDebt ?

That would involve the fewest tasks needing to have a project added, so WFM. Let's do it?

Qgil added a comment.Dec 8 2014, 8:41 PM

Editable By VisualEditor (Project)

You do it. :)

In T75892#831488, @Qgil wrote:

Editable By VisualEditor (Project)

You do it. :)

Done: https://phabricator.wikimedia.org/project/view/609/
I also merged all the MobileFrontend tasks into it, archived that project with a note, and added the old projects' tags to the new one.

What needs to be done here for Wikidata, or can we mark this as Resolved?

We need to tag existing bugs with the keyword. But this ticket can be closed. Thanks for creating the keyword.

Jdforrester-WMF closed this task as Resolved.Dec 8 2014, 10:08 PM