• Release responsibilities
• Ongoing
• Wish list triage proposal
• Urgent
• Tasks
• Projects
• Who
• Related links

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

• 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

• 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 future disappointments.
• Todo: clarify what open / pending / closed means and all the resolution statuses
  • http://dev.tiki.org/tiki-index_raw.php?page=Wishlist%20Team#About_ticket_types which is different from http://dev.tiki.org/How+to+Submit+a+new+item+on+the+Wishlist
  • Proposal
    • Open means it needs to be worked on
    • Pending: being worked on, waiting for answer
    • Closed Resolved/Invalid, just kept posterity
• 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)

• 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

• 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

• ✔ 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 luci and roberto take this now
• 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
• Too many useless or redundant fields when editing a wish

• luciash d' being 🧙
• Roberto Kirschbaum

• What makes a good bug report?

• Triage Team
• Wishlist Team