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 🧙
Table of contents
- 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
- 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.
- Identify "good first bugs to fix" to test and train new developers. So code is not too complex / messy / risky and we have an instance of the problem on a show instance
In September 2021 a "task force" was created to review the bug tracker items by 2 people with knowledge of Tiki and/or coding skills. Based on the "Created" date as displayed at : https://dev.tiki.org/tracker5, one will check and classify items from the more recent (https://dev.tiki.org/tracker5?sort_mode=created_desc) down and the another from the older (https://dev.tiki.org/tracker5?sort_mode=created_asc) item up. They will evaluate the issue for about 5-15mn then move to the next. At some point they should meet meaning item have been assigned to a list of issues: for new developers, for skilled developers, fixed, not possible to evaluate, etc (labels are not definitive the team will try to reuse as much as possible existing categories).
The feature requests should be processed as the issues... Need to be evaluated.
- Motivate new community members, because they have 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)
- Evaluate within 5-15 minutes an issue
- Understand if it is still relevant for Tiki master (Tiki24)
- 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.
- Change the status
- Open means it needs to be worked on
- Pending: being worked on, waiting for answer
- Closed Resolved/Invalid, just kept posterity
- Move to the next
- At the end of the session report progress below
- 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)
- Additional lists to review (modified accordingly to the new categories added)
- 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.: papercutsdone:
- 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
- Too many useless or redundant fields when editing a wish
- Merge field 56 into field 93, after checking that 93 is what we want
- field 93: check with standard, and document
- 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