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
- 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" or "confirmed" (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 30 days (for example), close it
- 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.
- 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
- 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)
Tasks
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
- 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