History: Where to report bugs

^ This is a discussion, which is still unresolved as of 2013 ^  

! Issues with situation in 2011

# 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 ((tw: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)).
# 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)
# It's very hard to get the bug known to the right people since ((tw:FOSS Web Application with the most built-in features|Tiki is so vast))
# 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.
# There are a lot of WYSIWYG bugs reported (proportionally and only a small number of developers that fix them)

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 ((tw:Pre-Dogfood Server))
**** Recording a ((screencast)) could be nice too, once we have that feature, or if we use an external service
* Get a ((tw:Wishlist Team)) going to monitor the ((Wishlist))
* For the ((tw:release coordinator)) of the next version to monitor ((Regressions in trunk))
* For WYSIWYG issues to be on a distinct list section so the non-WYSIWYG devs can get straight to the list