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
- Test/triage all reported patches
- Contact them to invite them to commit directly and be active in the community
- Test/triage all reported bug reports
- Test the fixes and close the bugs
- 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.
- 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
- 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
This will
- Motivate new community members, because they have quick feedback (and we'll get more committers)
- Free up tiki-devel of bug reports
- Make sure that all easy things are fixed
- Give a good overview of all issues and opportunities (ex.: report of all wishes on blogs is useful before a revamp)
Urgent
- 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.
- Merge/harmonize all the wish reporting process
- Merge field 56 into field 93, after checking that 93 is what we want
- field 93: check with standard, and document
Tasks
- 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
- 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
- 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)
- 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
alias