Many people on the forums, at Linden Office Hours, and on third-party sites express great dissatisfaction with the JIRA as a governance tool for proposing features and even prioritizing bugs in Second Life. This is not disputed. They find the JIRA complex, hard to search, arcane as to its rules and "culture," and daunting, as a very technically-inclined few are basically able to control it. By closing, moving, changing issues based on a very narrow set of developers' priorities and in a very closed developers' culture, they make it too difficult for people with even some working technical knowledge as users to work the levers of the JIRA to signal really serious problems in SL (like objects showing up in search without people's consent) or to make proposals even for the JIRA itself (like requiring author's consent or timing out proposals). More than a year ago, the Features Voting Tool was revised unilaterally by one very intensive resident, Angel Fluffy, who unilaterally decided what votes were legitimate and what were not – without any democratic participation, and with an inworld group in which only he himself was an officer. Busy Lindens applauded this difficult part-garbage-duty work, and then presided not over the reform of the FVT, as had been promised, but over its destruction. It was folded into the JIRA, with many of its key features destroyed. I propose separating a Features Voting System in revised form out of the JIRA and simplifying it and doing a publicity campaign to ensure wider use of it, possibly even putting access to it into the Viewer. No one knew about the demise of the FVT as it was not announced on the official blog – in fact, we received misleading information from emails to Lindens and questions at office hours as we were told repeatedly that it was being "refomed" and offered with "improved features" – and that hasn't been the case, in fact it was removed, destroyed, and a very skeleton features voting system within a very complex and rigid JIRA system is all that exists now. Here are the features that need reforming in a new, revised Features Voting System: o simplified user interface, where unnecessary labelling like VWR that people find confusing are removed in favour of numbers, and unnecessary items like "SL version" or "operating system" etc are removed, and a simple box for typing a label and an idea in 500 words or less with a link to any third-party forum discussion or inworld event with a SLURL. The aspect of SL and the appropriate version can always be added on after an issue is finally approved and accepted by Lindens – this baggage does not need to be part of the drafting procedure. o ability to label issues not only with aspect and number, but add a short phrase to describe it in words to make it more memorable, so that it becomes a tag, like PROP 101 NO SAVE CHANGES ON CLASSIFIEDS o have more than 10 votes for "yes" o ability to vote "no" – this cannot be gamed any more than "yes" can be gamed, flashmobs can happen on either side of the issue, and it means that votes deceptively appearing popular have a necessary popular corrective o have the ability for each proposal-maker, when he sees a duplicate, to make an automatic offer, as part of the template, to another person with a similar proposal, and automatically merge their unique votes under the new merged proposal – this provides a great incentive to get rid of duplicates, and prevents campaigning fatigue from trying to have to get the same votes all over again for new aggregated proposals. People can either signal ahead that they concede to mergers ahead of time, or toggle to agree to each new merger by getting an automatic notification. o have a web page with the Feature Voting System explained, and top voted items shown, with rubrics for easy finding of votes that may not turn up with key words o have time-outs for features that age 30 days or 60 days without any votes at all, or some number of votes like 10. o not require Lindens to respond at 500 votes, they may respond at any time or no time o do not use JIRA software for this feature, which does not seem adaptable for a workable FVS, but bid it out to third-parties to make and then co-opt it for SL use If something that seems "impossible to code" like "privacy walls you can't web-cam through" comes up, let people vote for it. Let a mllion people vote for it, even if impossible, Lindens can learn what people need in a virtual world and even if not possible to code now, when SL is open sourced, perhaps someone else can take it on. The governance for the software for the entire Metaverse using Second Life, when it is open-sourced, cannot be run by a handful of coders representing one point of view on an obscure, arcane system that defeats participation instead of encourages it. It has to serve many diverse groups.