User Tools

  • Logged in as: anonymous (anonymous)
  • Log Out

Site Tools


mantisbt:issue_voting_requirements

This is an old revision of the document!


Issue Voting Requirements

Author: Victor Boctor

Introduction

The idea of voting is to allow users to vote on the issues that matter most to them. Given that most of the time it is good to have all features implemented and bugs fixed, users should do some choice when deciding to vote for the more important issues. Users should also be able to vote against feature requests that they believe will be of harm to the product.

Database Schema Changes

  • mantis_bug_table
    • votes_positive as integer.
    • votes_negative as integer.
  • mantis_bug_votes_table
    • issue_id
    • user_id
    • weight (can be positive or negative, typically -1 or +1), can't be 0.

Configuration Changes

  • voting_enabled (boolean, default true) - enable or disable the whole voting feature.
  • voting_place_vote_threshold (default REPORTER) - access level required for users to vote on issues.
  • voting_view_user_votes_threshold (default DEVELOPER) - access level required for users to view the users who voted and their votes.

Votes Columns

  • It should be possible to expose the positive, negative or overall votes as a column in export csv, Excel, View Issues, etc. Overall votes are positive votes minus negative votes.

View Issue Page

  • The view issues page should allow users to vote positively or negatively. Also if users have already voted before and the issue is not resolved, then they can remove their vote.
  • Display the total number of positive / negative votes (kind of thumbs-up / thumbs-down counters)
  • The list of users who voted positively or negatively are listed in the same way users monitoring the issue are listed.

The Act of Voting

  • Ensure that users can vote (i.e. have the required access level).
  • If users have voted before for this issue, and their new vote is different then remove their current vote.
  • Add a record in the votes table.
  • Update overall counters on the issue.
  • DO NOT Update issue last updated timestamp. If necessary we can make this behavior configurable.
  • Update Issue History

Implementation Details

  • Deleting an issue must delete all associated votes.
  • Deleting a user must delete all associated votes, no update for last_update of the issues.
  • Implement core/vote_api.php
    • vote_add( $p_issue_id, $p_weight, $p_user_id = null )
    • vote_delete_issue_votes( $p_issue_id );
    • vote_delete_user_votes( $p_user_id );
    • vote_get_issue_votes( $p_issue_id ) - returns an array of user ids, weight.
    • vote_is_enabled( $p_project_id = ALL_PROJECTS )
    • vote_can_vote( $p_issue_id, $p_user_id = null )
    • vote_can_view_vote_details( $p_issue_id, $p_user_id = null )
  • Deleting an issue should delete all associated votes.
  • Deleting a user should delete all associated votes.

View Issues, CSV, Print Issues

Add support to the View Issues, CSV export and Print Issues page to be able to include the following columns:

  • votes_balance
  • votes_positive
  • votes_negative

Filter

  • Users should be able to filter on issues they have voted on (similar to issues that have monitored).

Email Notifications

  • Similar to the way email notifications can be customized for issue notes authors, it should be possible to configure email notifications for voters.

Future Ideas

  • Ability to vote on issue notes - This may mean that we should have a generic mantis_votes_table and include a type and id, rather than having a mantis_bug_votes_table and just having an id.
  • Limit the amount of votes users have
    • Users regularly get granted credits to use for voting.
    • Users get granted credits to use for voting based on certain actions (e.g. submitting an issue, adding a note, etc).
    • Users buy credits to vote.
    • Users get assigned credits manually by users above certain level.
    • Users above a certain access level bypass limits (default DEVELOPER)

Feedback

Please place any feedback here.

2007-07-31 ave : I would like to vote without changing weight sometimes just to show that 'I have reviewed the issue'. How about adding an configuration option for voting with weight=0?
2007-09-02 vboctor: Should we just have one field in the bug table to carry the overall vote balance?
2007-10-31 CADbloke: You're gunna hate me. A lot. I'd like a voting range, say from -5 to 0 to 5 (I agree with ave about 0 votes and I think negative votes are important), indicating how important the user thinks this issue is (say from DILLIGAF to OMFG-no/yes). I'd then like to be able to see, in the individual bug report, a vote summary with the total number of votes, subtotals of each vote-level (a bar graph would be lovely but possibly superfluous) and the average, to gauge the range of importance of the issue. That way I could prioritise bugs / feature requests and perhaps adjust the targeted release version, or at least see what is giving my users the ….

I'd like to see both the average and the number of votes as columns in the bug lists too. If the vote average is to be displayed in lists of bugs then the average (and the number of votes, and perhaps the subtotal for vote-level .. oh, I can feel a cron job coming on) should be recalculated and stored when a new vote is made to save a massive calculation efforts every time you generate a list of bugs. I think this reporting should be enabled only for the developers, admins etc - there is probably too much calculating and SQL action going on the have this running for everyone.

This level of fancy reporting could (should ?) be done by exporting as a CSV or Excel so the end user (me) could do whatever with the data. If it is unrealistic and over-complicated (as I tend to be, so my Wife tells me) to expect this level of reporting to be implemented in the core - just the export function would be nice, even if it just exports all open issues and their votes. In this case, just a table with Issue# and vote_value would suffice. A user could export this table to do statistical analysis on.

I hope I haven't ruined a perfectly simple idea for everyone. Victor, I'll understand if you delete this before it gets out! ;)

2008-02-20 CADbloke: - Reading that back is giving me a headache. I think my predilection for over complication got the better of me there. I'd be happy with 1-vote means I want it, no votes means indifference - just like any democracy.
mantisbt/issue_voting_requirements.1204436017.txt.gz · Last modified: 2008/10/29 04:32 (external edit)