This is the working area of the Bugfixing team. You can read more on our Bug fixing team page.
- Go to forge.typo3.org, log in (or create a new account) and click on Report Issue.
- Please fill in the Category, Reproducibility, Severity and Priority field as accurate as possible (that will help us a lot).
- Fill in the Summary field with a short title of the bug and the Description field with a more detailed description. The more accurate information, the more likely is the bug to be fixed!
- If this is a code bug, consider using the Advanced Report to add more details.
- Add a file (if you think it contains further helpful information; see below for more details), leave the View Status at public and click on Submit report.
- The developers make use of the status, priority and resolution fields. After having checked a bug report, they can mark it as acknowledged or request feedback, if the original bug poster should elaborate on the issue. If a bug is a duplicate, they can add the ID of the duplicate report and close it.
- To show others that he is currently working on fixing a bug, a developer should assign the bug to himself. This will prevent the developers from doing double work.
- Only bugs in trunk and the current stable version will be fixed. An exception are security related bugs, which are likely to be fixed in older versions, too.
How to submit a bugfix
If you want to submit bugfixes and/or changes to TYPO3 (core or extensions), please follow these guidelines:
- Separate your features: One improvement only per issue. Too many changes with too many lines of code make it hard to locate all different changes.
- Open a new bug report for each issue.
- Comment the changes in the code if it isn't obvious what they do.
- If you have a solution for the problem you found, please provide it as a diff file, since the changes cannot be located otherwise (compare to other patches, look at the bugtracker for example).
- Short patches are preferred, because many people won't bother to read huge changesets... :-|
- If it's an GUI issue, add screenshots of how it looks before and after the change.
Make it easy for the developers; then it's more likely your bugfix/feature will be implemented!
Here is how the developers use the different bug statuses on :
A newly filed bug report. Normally it should be in this state only a short while until a developer responds it and promotes it to another status.
A request for discussing a bug report before deciding what to do with it. This status will be used when there are further questions concerning the report; or to discuss which of multiple solutions to choose, and so on.
A bug report that has enough feedback (or doesn't need any), enough information to be able to reproduce or fix it; but is not yet confirmed (see below).
A bug report that is acknowledged and has been reproduced and/or confirmed.
Someone has been assigned to work on the problem. The bug report should be regularly updated by the assigned person to reflect progress.
The bug is resolved. A fix for the bug has been committed to the Git repository. The bug will be fixed in the next release. To be able to find the patch in Git, the URL of the Gerrit page containing the review should be added to the bug report as the last note.
A bug report is set to this status when:
- a bug is decided not to be resolved (Resolution "wontfix")
- when it was discovered it was not a bug (Resolution "invalid")
- when it is a duplicate (Resolution "duplicate")
- when a version of TYPO3 containing the fix has been published
When closing a bug report, please always add a comment telling people what has been done and why!
Getting your change integrated
If you created a patch for an issue in the TYPO3 core, see our pages on how to contribute to get your changes discussed and finally integrated in the next versions.