This is a proposal for a new way to list wishlist items by priority.

Interesting article about prioritizing:

Problems with current system

  • Too many high priorities
    • This comes from end-users who can't select a fitting priority because they there are no guidelines or they don't know better. They just know that's pretty important for them in that moment, so they add a high priority.
  • No feeling of difficulty of solving the issue
  • No realistic dashboard or low-hanging fruit

Proposal: Make a score from difficulty and importance and dogfood (for technical reasons, it's easier to not do "dogfood" as of Tiki11)

We are now using Mathematical Calculation Field to determine a priority, which is a score from 1 to 100. Every time the tracker item is saved, this priority is updated and this field can be used for sorting.

We should move to a scale of 1-5 instead of 1-10 but we first need some improvements in PluginListExecute to be able to do this

  • Easy: 10 points (5-10 minutes to fix, no risk of regression, etc.)
  • Medium: 5 points (a few hours, can be done by many different people)
  • Difficult to fix: 1 point (Requires days of work, or needs very specific skills)

  • Important: 10 points (popular feature, severe problem, no workaround)
  • Medium: 5 points
  • Unimportant: 1 point (edge case)

Priority would set by multiplying importance x ease and would be used as the default sort.

Bonus points

  • if there is a show instance (we can't easily check it was really configured, but we can check it was created)
  • if users voted it up, using the rating feature.
  • if in the category "Dogfood on a * site"


Kissaki:In my opinion, this won't fix the problem. End users will still not know neither the difficulty of implementation/fixing nor the importance for the project.
ML: 1- Some will know, 2- Let's educate 3-Wishlist team is supposed to review

Bsfez: May be we could try to use something abstract like a gauge instead of hard value. This need a little blurring to ease the process. (reducing score also will help).

mikeua: $$money can help motivate sometimes :-) maybe add fields for developers to respond with 'hours necessary for development' and 'cost for development'? This might make it more clear and direct for both sides and might spur faster, market driven development - at least for specific projects end-users 'want' (might be more difficult with back-end projects that Tiki 'needs').