[TYPO3-core] Issue handling

[Jigal van Hemert]

Hi,

On 9-5-2013 23:15, Alexander Opitz wrote:
> the last weeks I poked through more then 1.200 very old core issues, closing
> some duplicates or having no response since over one year. But mostly asked
> for Feedback. Sometimes with the feeling that "chrissitopher" stands behind
> me. ;-)

Thank you very much! We need more people who are just willing to test 
issues, see if it is a configuration issue, etc.

> So, now my question to how I should handle the following 2 fields:
>
> - Target version
> - TYPO3 version
>
> TYPO3 version is the major version in which the issue was found. Should this
> field hold the first major or last major version a issue was found?

This is usually filled by the reporter to indicate which version they 
found the issue. It is an important clue for the person who wants to 
test/fix it where to start looking.

> Target version holds the minor version in which it would/will be solved. Who
> should set this field? A developer who plans to bring this in next minor
> release? Or should all 4.7 open issues set to next version as target? And
> what to set if the issue is in 6.1, 6.0, 4.7 and 4.5? 4.5.27 or 6.1.1? Who
> will update this minor version number if an issue passed the release?

For bugs this is the lowest TYPO3 version where it will be fixed. It is 
usually set when somebody starts working on it. The first step in fixing 
it is of course finding the cause. Then it's known where the problem 
originated. Of course, we have to take into consideration if the problem 
is serious enough to backport to branches which are in the phase where 
only security issues and serious bugs are fixed.
During review of the patch it might be decided that it will not be 
ported to some branches, mostly by a decision of the RM.

For features it is the version where the feature is planned to be 
introduced.

This field is also used during development of a release to mark issues 
that need to be fixed for that version. For example: you can set an 
issue to 6.2-beta1 if the development team or the RM thinks it is 
important to fix it before beta1 is published. This makes it easier to 
find the wish-list for these releases.

> The FriendlyGhost (http://forge.typo3.org/projects/typo3v4-core/wiki/FriendlyGhost) document writes, that the 'Needs Feedback' issues
> now have 90 days time for response. I'd like to reduce this to 1 month, as
> we need to get the numbers of open issues down, very fast.

90 days is a good compromise. It has been discussed a few times; I think 
everybody can live with this number.

> Ans last question, if an issue is closed, how a user can contact us? Writing
> in the issue mostly do not help (no assignee and no watchers) and who wants
> to go through the closed issues to look if someone has problems with a patch
> (or why ever the issue was closed).

You could create a new issue.
Many bugtrackers allow to re-open an issue if someone responds to a 
closed issue.
There are various lists to contact people: typo3.teams.core, 
typo3.teams.bugs (low traffic), various project list.
The Friendly Ghost.

Thanks again for going through the issues. Don't be discouraged by 
negative comments of some people. Mostly it's an expression of some form 
of frustration. Know that many people are glad that issues are analysed, 
but they don't say anything :-)

-- 
Jigal van Hemert
TYPO3 CMS Core Team member

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