Filing bugs and issues
From Joomla! Documentation
Revision as of 05:39, 21 January 2008 by Jinx
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.