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 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 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 Pre-Dogfood Server
- Recording a screencast could be nice too, once we have that feature, or if we use an external service
- This should be to
- Get a Wishlist Team going to monitor the Wishlist
- For the 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
;){kind=link}
;){kind=link}
;){kind=link}
;){kind=link}