Where to report bugs

Issues with situation in 2011

1. Currently, bugs are reported in many different places
   • tiki-devel mailing list: it clogs the list, works sometimes, but for others, they are just lost
   • dev.tiki.org wishlist: not systematically monitored, as we have an inactive WishList Team
   • forums (not properly tracked)
   • IRC (not properly tracked)
   • On wiki pages (not properly tracked), especially at release time: Tiki8, Tiki7, Tiki6,Tiki5, Tiki4, Tiki3.
2. Sometimes, the user doesn't know if it's a bug or just a misconfiguration or misunderstanding (so an opportunity for better UI or documentation)
3. It's very hard to get the bug known to the right people since Tiki is so vast
4. There is pressure to fix bugs in unfinished features
   • The priority of the release team should be regressions and packaging, not new finishing new features.

These issues have a consequence that releases are too much about bug fixing vs just packaging. We need to improve the situation in previous steps.

Proposal for 2012

• New guidelines on where to report bugs
  • Bug in a stable version (it never worked): should be in Wishlist or in the wiki page of the relevant Keyword (it's the choice of the bug reporter).
  • Regression (it used to work) in a stable version: Should be on a wiki page on dev unimaginatively called: Regressions in 8x, Regressions in 9x and Regressions in trunk
    • This should be to
      • Report something that worked in a previous stable version (any stable version)
      • For upgrade bugs
    • This should not be to
      • Report a bug with an enhancement
    • Preferred way of demonstrating issue is i18n.tiki.org or Pre-Dogfood Server
      • Recording a screencast could be nice too, once we have that feature, or if we use an external service
• Get a WishList Team going to monitor the Wishlist
• For the release coordinator of the next version to monitor Regressions in trunk