The Wishlist Triage Team reviews patches, bug reports and feature requests and prioritizes and categorizes them. They just triage but don't fix. They identify potential contributors and encourage them to go beyond bug reporting. Also known as task garderners. Team leader: luciash d' being 🧙

Release responsibilities

1. Test/triage all reported patches
   • Contact them to invite them to commit directly and be active in the community
2. Test/triage all reported bug reports
   • Test the fixes and close the bugs
3. Review How to Submit a new item on the Wishlist to make sure it's still relevant and update to take advantage of new features.

Ongoing

• Maintain dev.tiki.org, except for developers documentation workspace which is handled by the Developers Team.
• Pre-Dogfood Servers are a great place to test reported issues.

Wish list triage proposal 2013

• One per week (ex.: each Friday), review all new wishes
  • We need a report of a all new wishes
• Within 5-15 minutes
  • Add/modify any appropriate tag/category, so they appear in all the proper reports
  • Add/modify any ratings for Ease Importance Priority so all the low-hanging fruit is at the top of the list.
  • If they are clear, move from "New" to "accepted".
  • If it's not clear, move from "New" to "unclear" and a comment why ex.: please use show.tiki.org, please improve the explanation, etc.
• If you know that this is a priority of a specific developer, assign to that user (and they should receive a mail)
  • We should build a list of topics and developer mapping

• Other reports
  • List of all open wishes, in order or priority
  • List of all open wishes that don't yet have a ease-importance-priority, with most recent at the top so we can progressively go through the backlog (ex.: 5 per week)

This will

2. Free up tiki-devel of bug reports

Tasks

Projects

• Setup show.tiki.org
• Find a person to do triage: valid? duplication? & assigned to
  • Pascal will take this up once show.tiki.org is functional
• Establish a clear policy with respect to Where to report bugs (and reduce bug reporting traffic on dev mailing list)
• Setup two main perspectives on dev.tiki.org
  • Wishes
  • Developers documentation
• Batch actions on the bug tracker
  • Template_Change_Open_to_Pending
• Build and maintain a list of contact people per feature (to inform them of new bug reports for their features)
• Rating of quantity of work ex.: papercuts
• Have different input form for feature requests vs bugs
  • ex.: version number is not relevant for feature request
• Simplify category system on dev (and merge info using tiki-admin_categories.php)
  • Perhaps use Category Transitions
• Merge info from Wishlist Team
• Review all pages with "Dev" in the name and merge any relevant info to dev.tiki.org and delete them.
• Merge categories on dev.tiki.org

Who

Related links

• What makes a good bug report?

• Triage Team