Just as with the Features Voting Tool, the coders of the JIRA issues page here are incorporating the same bias against having a "no" vote. This apparently springs from their selectivity in endorsing certain interpretations of the "wisdom of crowds" and a mistaken belief that adding a "no" vote will introduce "spamming" or "griefing". In fact, JIRA itself may not even contain the function of "no" based on that mistaken belief, in which case we really need to worry. "No" votes are very important correctives in a group working within a virtual world, where some of the people get to actually change the features, and some particularly vocal or skilled get to influence those people about what changes are made or not made. To enhance authentic democratic participation and freedom, we need to be able to vote "no" on features that do not have support from the broader community. Otherwise, this second, shadow, parallel voting features system that has curiously now sprang up outside the official Features Voting Tool will acquire even more sectarian and in-group powers to influence the platform than FVT has. People sometimes put up pet projects and get 10 or even 30 votes from friends and even Lindens and suddenly feel as if they have "the voice of the community". They don't. Prioritization and designation of issues are vital, and the core of the group or any one determined faction should not be able to pull the entire blanket on themselves. We need the corrective of "no" which provides a very important feedback; failure to get a lot of "yesses" does not mean "no". If "no" can be spammed or gamed, so, arguably, can "yes"; it is not wise to design systems backwards from the premise of how they can be gamed or griefed; you must also serve the public interest and public right to participation in a broader sense by creating options.