This is a proposal for a new way to list wishlist items by priority.
Interesting article about prioritizing: http://itsmsolutions.com/wp-content/uploads/2013/01/DITYvol3iss1.pdf
- 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 users voted it up, using the rating feature.
Bonus of 10 points if used on tiki.og (This will be for later)
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’).