Actions

Filing bugs and issues

From Joomla! Documentation

Revision as of 06:39, 21 January 2008 by Jinx (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Reporting bugs

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.