Loading...
 

Wishlist Triage Team

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.
  • 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

How

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.

This will

  1. Motivate new community members, because they have 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)

Checklist

  • 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

Progress

Bernard Sfez / Tiki Specialist: https://dev.tiki.org/item993-Watch-forums-links-icons-RSS-links-icons-on-tiki-forums-php

Reporting

 Need to be reviewed
We have many reports page/list. They were indicated here without being checked or tested. The list will be cleaned along the way with first results and sessions to rerge/harmonize all the wish reporting process

Documentation

 Added as is
Those items were reported from the previous attempt to check the bug tracker items. The team may have nothing to do with the documentation. Reported for evaluation

Additional tasks

 Added as is
Those items were reported from the previous attempt to check the bug tracker items. Some may be obsolete or completed already...

  • 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

Who

Related links

alias