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. 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.
4. Carry out manual test plans: Instructions for Tiki Testers

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 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" (or something like this)
  • 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 unclear more than x days (for example), put it to pending
• 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
• If a bug is not going to be solved, tag that feature as experimental to avoid disappointments.
• Todo: clarify what open / pending / closed means and all the resolution statuses
  • http://dev.tiki.org/tiki-index.php?page=Wishlist%20Team#About_ticket_types which is different from http://dev.tiki.org/How+to+Submit+a+new+item+on+the+Wishlist

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

This will

1. Motivate new community members, because they have quick feedback (and we'll get more committers)
2. Free up tiki-devel of bug reports
3. Make sure that all easy things are fixed
4. Give a good overview of all issues and opportunities (ex.: report of all wishes on blogs is useful before a revamp)

Urgent

• Chosen is awesome: any chance we can have the description of a category as a mouse-over?
• Rejected and Won't fix should be merged
• Move "Resolution Status" from a drop down to a category for more flexibility (easy rename, multi-choice, etc.)
• For all wishes that were categorized in "Less than 30 minutes to fix", put an ease score of 8.
  • http://dev.tiki.org/Move+from+30+minute+fixes+to+ease+filter
• Merge/harmonize all the wish reporting process
  • Bug Tracker Input Form and Report a Bug
  • How to Submit a new item on the Wishlist
  • Your wish has been cast
  • Bug Tracker List and Search Bugs
• Where to report bugs

• Merge field 56 into field 93, after checking that 93 is what we want
• field 93: check with standard, and document

Tasks

• Decide what to do with this leftover text from the deduplication

{GROUP(groups="Team Developers")}Notes before or while fixing (developers):
*Be in touch with the person that reported so he can help/update/retest/mark as solved.
*If you need to ask another dev something do it by yourself. Answering to the bug reporter that he should ask another dev is usually not working and add confusion.
*Be sure you comment the log report with step taken and bug fix completion (svn release, backporting, etc).{GROUP}

• figure out why Ratings (field 62) keeps on re-appearing as the 1st field
• Change Easy Importance Priority for a scale of 5 instead of a scale of 10, and update all data
  • And at that point change the math to do x4, so it remains on a scale of 100

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 done:
• 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