What's the interest out there for this feature or something more close to a true voting system?

Additionally, does anyone have any idea if this idea's possible without changing the database schema? For now I'm assuming it could work as follows:

The fixed fund is assigned per user & based on their user level. In order to calculate their available funds we would need to calculate their total sponsorships for a given project, then negate that from their fixed fund.

OK, lets say I am admin, so I have $100, I sponsor issues till I run out of money, what will happen then? When do I get more money? I would assume that there must be a trigger distributing more money (for example, development started on a new release).

Basically the idea is if you run out of money [votes] & you want to sponsor [vote for] another issue you'd have to reconsider your priorities.

Example: Is this new issue more important to me then any of the other issues I'm currently sponsoring [voting for]? If it is then I'll have to stop sponsoring some other issue in order to give me some free funds [votes] to use on the new issue.

Additionally it might be a good idea if when an issue were closed any funds were "returned" to the origianl sponsors. Adding more money to the mix would only decrease the use of the sponsorship system as it'd reduce the worth of the sponsorship - rather like infaltion would in a real economy; the more money everyone has the less it's worth. And without real money from a real economy the only way to make virtual money worth anything is to limit its availability.

Hopefully you get the idea though...

• I believe users should only be able to re-assign their sponsorships until an issue is started or something. Otherwise, one the issue is in progress they can move their funds elsewhere.

• Should the money be available again for re-used when an issue reaches a configurable status threshold (eg: resolved) rather than neecessarily closed?

• In a lot of cases the people who decide what features should go into a release are not necessarily the people with the highest access levels in Mantis. For example, Business Analysis may have less access than MANAGERS, but may have more input when which feature should be in the next release. Hence, I think the money available to a person should be defined in the user's profile.

I am inclined to think that a proper voting system is a better approach than tweaking the sponsorships to support such scenarios, but I think the discussion may be useful in whatever direction we take.

The idea to use the sponsorship as voting-system ocurs to me too. It would be nice to have some system for the reporter (in our case the customer) to prioritize there problems.

General: I prefer a 'real' voting system instead a sponsorship.

I'd be completely behind a dedicated voting system, as what I outlined above is nothing but a way shoehorn voting onto the current sponsorship system.

I tried hacking elements of this feature in last night & while it was working reasonably it did just seem like it might just be better to implement a true voting system. My main issue was that I wanted to get something up and running that could make a release before too long as my team would benefit greatly from some implementation of a voting system.

My HTML skills are fine, but my SQL skills (certainly when it comes to creating/extending tables are) rather rusty. I would happily provide the API & UI side of it but could do with some sage advice on how a voting might integrate with the current database structure.

Obviously the sponsorship table could be extended for voting, but as it was never designed for that it woulds seem to make sense to add a dedicated voting table. Additionally, there'd be the need to be a place to store the vote allocation for a user & a way of making that allocation per project. I'm also assuming a votes total would need to be added to the bug table.

edited on: 07-23-04 04:52

Even with a true voting system, the idea of being given limited spending is very appealing. (virtual economy etc.)

I think a workable workflow would be:
User has a "bank" of points

Points get assigned to issues until they reach status X (e.g. assigned), until status X is reached, users can re-allocate their points.

Points are freed and given back to the user once the issue reaches status Y (probably resolved).

I agree with the previous comment that point allocation does not really increase with privilege level. There needs to be a finer grained way of controlling how many points each account has to work with.

Voting and Sponsorship are two different systems - maybe adopting somehting like php.net do with there bugs database.

For each bug, a user can 'vote' and give it a score out of 5
1 is - not interested / don't like this idea or whatever the scale is
3 being 'average'
5 strongly for this

Or, you do as suggested, give people '100 points' and they can distribute them as they see fit.

My 'vote' goes to the sugestion of bluetooth (User has a "bank" of points): we have limited resources to fix the bugs. So we are interestet in the opinion of the customers, which issue first. When they can rate every issue with top-prio, they will do it.

The bank of votes/points concept is to me far & away the better option. It allows the best representation of the overall user opinion & allows voting power to be distributed in a way that correctly reflects the structure of any given project.

As there appears to be enough support for a true voting implementation, someone might want to mark this issue as closed (won't fix). The discussion should really be moved back to 0000668.

As requested, making this as resolved.

Let's work out some possible options for a 'voting system' in 0000668