Filing bugs and issues
From Joomla! Documentation
Revision as of 06:46, 21 January 2008 by Jinx
This article is tagged because it NEEDS REVIEW. You can help the Joomla! Documentation Wiki by contributing to it.
More pages that need help similar to this one are here. NOTE-If you feel the need is satistified, please remove this notice.
Well-written bug reports are incredibly helpful. However, there's a certain amount of overhead involved in working with any bug tracking system, so your help in keeping our ticket tracker as useful as possible is appreciated. In particular:
- Do read the FAQ to see if your issue might be a well-known question.
- Do search the tracker to see if your issue has already been filed.
- Do ask on testing forums first if you're not sure if what you're seeing is a bug.
- Do write complete, reproducible, specific bug reports. Include as much information as you possibly can, complete with code snippets, test cases, etc. A minimal example that illustrates the bug in a nice small test case is the best possible bug report.
- Don't use the tracker system to ask support questions. Use the joomla forums, or the #joomla IRC channel on freenode for that.
- Don't use the trackers to make large-scale feature requests. We like to discuss any big changes to Joomla's core on the developers forums before actually working on them.
- Don't reopen issues that have been marked "not a bug". This mark means that the decision has been made that we can't or won't fix this particular issue. If you're not sure why, please ask on developer forums.
- Don't use the tracker for lengthy discussions, because they're likely to get lost. If a particular artifcact is controversial, please move discussion to developer forums.
Reporting security issues
Report security issues to security [at] joomla [dot] org. This is a private list only open to long-time, highly trusted Joomla developers, and its archives are not publicly readable.
In the event of a confirmed vulnerability in Joomla itself, we will take the following actions:
- Acknowledge to the reporter that we've received the report and that a fix is forthcoming. We'll give a rough timeline and ask the reporter to keep the issue confidential until we announce it.
- Halt all other development as long as is needed to develop a fix, including patches against the current and two previous releases.
- Determine a go-public date for announcing the vulnerability and the fix. To try to mitigate a possible "arms race" between those applying the patch and those trying to exploit the hole, we will not announce security problems immediately.
- Publicly announce the vulnerability and the fix on the pre-determined go-public date. This will probably mean a new release of Joomla! but in some cases it may simply be patches against current releases.