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
- 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
^ 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