[TYPO3-core] Target Versions in TYPO3 CMS Issue Tracker

[Ernesto Baschny]

Hi,

it has been brought to discussion already some days ago, but I would
like to make a concrete enhancement proposal:

Starting (again) as a Release Manager I see myself in the same situation
I had in 2010: No proper way to organize "my work" in Forge amongst the
mess and tons of issues we have.

The most important "toys" for a manager are:

- the Roadmap
- be able to prioritize issues: AKA stick them to the Roadmap

Forge has a nice "Roadmap" view, but it is based on the Target Version
field in issues. And now comes the crazy thing:

We have no rule for Target Version assignment. Everybody sets what he
thinks there ("oh yea, this *definitively* needs to be in next 4.5.333"
or "this would be a good improvement for 6.2.0, let's set that as a
Target" etc).

And on the other hand, after an Issue is resolved, *sometimes* someone
remembers to set the Target version. Sometimes even a wrong one. There
is no regulation, no control and no rules. So by definition it's useless.

Bugfixes have the particularity that they usually affect more than one
stable branch. The field only accepts one version. We have the
convention of using the "lowest branch" where the issue appears. But for
that we also already have the "TYPO3 Version" field to denote the Branch
where the bug first occurs.

Considering these annoyances and inconsistencies, I suggest the
following change:

1) Get rid of all "patchlevel" versions in the Target-Version field. We
have *every* Target Versions since 3.8.0! It's useless. It's also
something the release team has to constantly manually update after every
release - easily forgotten.

2) Remove all currently set Target Versions of all issues. "WOAAAA wait
a minute are ya crazyyy?? So much information thrown away???" - you
might think. Think again: Removing them all we won't really loose any
important information. We have "Merged in Core" script to check which
issue was solved in which exact releases. For the little non resolved
issues that have target versions assigned the info is not correct anyway.

3) Add a new set of Target Versions which could really be useful to the
Release Team. Suggestion:

- Next Patchlevel
- 6.2 General
- 6.2 Logging
- 6.2 UX
- 6.2 FAL
- etc...

This means:

a) Bugfixes which the Release Team thinks are important to be marked for
the "next possible release" should get Target Version "Next Patchlevel"
(doesn't matter the number!). This is useful for having a Roadmap for a
Regression-Fix release or a Security Release.

b) The "6.2 Release Manager" (me...) can then use the "Topic Target
Versions" to maintain sort of separate "Roadmaps" for particular topics
that are important for his release.

c) Subprojects of the Core should then stop creating or maintaining
their own "Versions" and stick to the Core ones. It's simple and more
useful to all.

d) Introduce a simple rule for issue updaters: *Noone* should ever set a
Target Version other than the Release Team! Only exception might be
Subprojects which could manager their own Roadmap (i.e. Extbase) but of
course in coordination with the Release Team.

What do you think about that?

Kind Regards,
Ernesto Baschny

-- 
Ernesto Baschny
TYPO3 CMS Core Developer
Release Manager TYPO3 4.5 & 6.2 LTS

TYPO3 .... inspiring people to share!
Get involved: typo3.org