Point 1: Simplified user interface: I don't see how replacing abbreviations with meaningless, bureaucratic-sounding numbers is easier to use. WEB-399 at first glance tells me this is an issue related to the Second Life web services much more clearly than something like "PROP 101".

The JIRA interface itself could, and probably should be simplified for users, however, creating yet another piece of software to do it seems counter productive. I think a solution would be to modify the existing default dashboard to be more informative. For me, that means lists of unresolved issues by project type. It should be noted that any user can configure their dashboard – their JIRA home page – however they want. I've recently reconfigured my dashboard to give me a better at-a-glance view of new unresolved issues, my watched issues, and issues I've voted on. A portlet on the main page for quickly creating an issue would be a very useful on the default dashboard, and such a plug-in seems to already exist for JIRA, though not available in this installation.

Point 2: Label issue with short phrase. JIRA already does this. In fact, you did it. This issue shows up for me as WEB-399 Feature Voting System Should Be Separated from JIRA and Reformed.

Point 3: Have more than 10 votes for "yes". JIRA already does this.

Point 4: Ability to vote "no". Seems reasonable, and unless there's some strange goings-on with JIRA, I don't see why it couldn't be done. Then again, as this comment is an example, it's very easy to express disapproval with a feature/bug issue. From what I've seen of triages, Lindens and resident coders simply do not ignore comments when reviewing an issue for implementation or other action.

Point 5: Merging duplicates: JIRA already does this with links, with the exception of merging votes, and that anyone can link issues, not just the creator. At first glance, merging votes seems like a good idea, but only if they can be un-merged if the issues were linked and should not have been for whatever reason.

Point 6: Time Outs: By "time-out", do you mean it drops out of the system if no one votes or if it gets too few votes? Why should people have their voices left unheard by the system dropping their issues? Seems counter to your idea of residents being heard.

Point 7: No Specific Linden Response Required: JIRA doesn't seem to require a Linden response either, but Torley and many other Lindens do an excellent job responding here in JIRA – seems much orders of magnitude better than the old Feature Voting Tool.

Point 8: Use a program other than JIRA: As I said, duplicating feature voting in another package seems to add unnecessary complications, and I believe that JIRA can be configured to improve it for user accessibility. I don't see how it is useful to add an additional burden to Lindens by adding a separate place for them check for features, when JIRA is indeed capable of handling the task.

Since JIRA is accessible to ALL SL Residents, I vehemently disagree that it is open only to a handful of coders representing one point of view. In fact, it seems quite the opposite to me, and many people who are not coders are already using JIRA to report issues. I notice them when they forget to search to see if their issue has already been reported (and JIRA regulars do a good job of linking the duplicates), I notice them when their issues lack pertinent information. Nonetheless their issues are very much tracked in JIRA where they can be heard by the Lindens.

There was already a piece of software created, and a third-party site now defunct for various reasons, made by Clubhouse Granville, had a nearly-completely new Feature Voter System ready with the ability to vote "no" and other streamlining, and could be revived.

No one who already finds the JIRA daunting, clunky, and confusing is going to sit and fiddle with the Dashboard, that's just not on. That's cruel to ordinary users.

A plug-in for new issues merely puts a tiny user-friendly interface on the top of a very confusing, arcane, obscure, and self-defeating system that doesn't encourage participation, but discourages it actively.

The point about the phrasing on the name of the issue speaks not to the current form of the JIRA, but the reforms necessary to take the old Feature Voting Tool and turn it into a revised Feature Voting System.

Again re: 10 votes. This is about changing the FVT, since this was retired – destroyed — not migrated. And explaining what about it needs to be changed, including changes made to the JIRA version, to make it viable.

Re "vote" no. Rob closed my suggestion to do this instantly, long ago, citing the inability of the Atlassian software itself to provide this (!!!). I then was sent over to the JIRA of the Atlassian JIRA, where I was instructed to make the same proposal to them. I did. Their developers got back to me with this same utopianist tekkie belief system that it couldn't be done because they didn't like it (it wasn't a technical issue) – they believed in "approval voting" and having the wisdom of the crowd only vote yes and be positive, and they also believed (mistakenly) that "no" votes would be gamed (as if "yes" votes aren't?!). I pushed this with them through several rounds, and they could only shrug and say I could essentially work my way up their own JIRA, even more complicated, and try to push this proposal for approval. No thanks. JIRA's are pretty ineffective as democratic governance tools.

Again, you can't seem to understand the thrust of this proposal, which is: restore the Feature Voting Tool as a free-standing tool as it was before, keeping all its proposals and votes, but modify it with some of these sensible features that are useful, like naming and voting more than 10.

As for "merging" having the Links is not at all what I mean. I'm talking about an actual parliamentary-like merging of different drafts in a bill to have different factions or interest groups settle on a compromise or an improved bill in mark-up that they then reissue for vote.

My proposal to merge votes springs out of the critique some have that they find duplicates unbearable. I don't. I would contact those people and try to manually and politically settle with them, then they could in theory merge manually. But by making this a series of switches, we could improve its effectiveness.

The problem of consent of the voters, and knowledge of their merged status, remains. One could have a switch to pre-set it to the proposal-makers merge actions, if he were trusted enough to get your vote, you could trust him enough to merge sensibly with another similar proposal. If not, it would be a toggle of consent, so that when a maker of a proposal merged, it would trigger a notification to agree to the merger – or not. If you did, you added on to the new merged item; if you didn't, your vote fell off.

I'm glad you're so troubled by having people's voices left unheard. And that's exactly what is happening, as busybodies come along and close their issues merely because they have 0 or only a few votes, they don't seem to have any merit, they seem unreasonable, or somebody just doesn't like them. Therefore they RESOLVE or CLOSE them and there isn't even any notification to let the person know who made them that whoops, they just had their issue RESOLVED or even CLOSED.

So if you are troubled by THAT, then you should join me in my cardinal issue here, which is abuse of the JIRA precisely in that direction. Because those who go around closing things arbitrarily just for the sake of no clutter, then invoke "clutter" of "too many open proposals" to me, I suggest a timer.

The timer was invoked precisely to address their concern; I don't even require it in a system I'd devise, because open issues don't trouble me by their existence, the way they trouble others who are more fastidious.

A person gets a notification telling him his issue is about to time-out if he takes no action to address motions to close (a close action is a motion, not a final closure). Indeed, much of Second Life would improve if people had real respect for the entire community of issues, instead of false respect for the individual. People who logged off and never returned to SL are allowed to keep their free 4096s or paid-up 512s cluttered with junk for entire years with no action by Lindens in the name of private property and individual consent, and everyone around those parcels suffers the blight and even griefing., What about their individual rights? Again, I don't care if there isn't a timer, I'm not wedded at all to that system as I see no burning issue to keep removing issues. I figure the live issues with the votes that are marked major or show-stopper find their way to the top view and anything else isn't the burden that some like WarKirby imagine.

I find that quite a bit of the Linden action here is of the "close it and forget it" variety and declaring premature victory, or declaring "resolved" and "fixed internally" when it is very, very far from seeing the light of day. Again, my proposal to have a tool that doesn't bind Lindens to response is a way of addressing the concern that these systems "make work for Lindens". They don't need to fear any "work". The community drives the good ideas up to the top, votes for the best, and eventually, either the Lindens find hundreds of votes compelling or not, but I wouldn't suggest some magic threshold like "500".

I don't see that there is any will to change JIRA; though it is in BETA, I don't see a scintilla of willingess from Lindens or the "good citizens" who seized it to admit that RESOLVE is a world that needs to be changed. It's not something that you MUST live with, surely it can be changed to better reflect the meaning of the action, which is more like RETURNED or PENDING FURTHER INFORMATION.

It's absolutely, indisputably preposterous to say that JIRA is open to all. It isn't. Most have never heard of it. Those few who make their way here run away screaming, in knock-kneed terror. Those that brave it are quickly dismayed at how they are tossed about, getting their issues declared invalid, falsely resolved, or closed. They have to be incredibly aggressive and persistant, or else technically competent and with "points" among the Office Linden regulars to be able to get something sensible put through.

Precisely to avoid all this whining about burdens to Lindens (which are already present in this clunky and stupid JIRA as it is now! – creating a false premise of "needing helpers" to "lighten the burden for these busy Lindens"), I've suggested that the code to the old FVT be thrown up, and invitations made to third parties to either fix it with some new features, or make a new voting system. I don't think it's the rocket science you imagine.

Point 8: Use a program other than JIRA: As I said, duplicating feature voting in another package seems to add unnecessary complications, and I believe that JIRA can be configured to improve it for user accessibility. I don't see how it is useful to add an additional burden to Lindens by adding a separate place for them check for features, when JIRA is indeed capable of handling the task.

There are not "many people who are not coders" using the JIRA, and many of them who are do not realize how often their issues are moved and even resolved or closed without their consent that they could be pushing back on considerably.

The old feature voting system was riddled with duplicated issues, and made it far more difficult to determine whether a proposal was duplicated by, or subsumed under, another proposal than is possible with JIRA. The utility of avoiding gratuitous duplication of issues seems self-evident to me--feature voting, unlike initiative petition in RL, is essentially without cost, so there's no motivation for proponents to bother to check for duplicates, just as there's no motivation for spammers to target people who might actually be interested in what they're selling.

"many... do not realize how often their issues are moved and even resolved or closed without their consent"? Well, "You are not watching this issue. Watch it to be notified of changes" seems pretty clear to me; does someone who doesn't bother to ask for notification of changes really care about the issue? Perhaps the default should be that the creator of an issue is automatically marked as watching that issue.

Really? "Many" meaning a large proportion of people in forums etc.? People are far more likely to complain than to compliment, so it's not clear that that's a representative sample, and I seriously doubt that people in forums, at Linden Office hours, or on third-party sites constitute a significant fraction of the total residents of SL.

"It's absolutely, indisputably preposterous to say that JIRA is open to all. It isn't. Most have never heard of it."

Back during the old feature voting mechanism's reign, when I suggested to someone that they vote on a particular issue, the invariable response was "I can vote?" Of course, the set of people I did that to/with may not be a representative sample, either; I can only say that I met very few people in SL that displayed any awareness of the old feature voting mechanism.

Asserting something very firmly is not proof, or evidence.

It is not disputed. That indeed is the case. Many is many, indeed, as the issue isn't "are these participants a significant percentage of SL"; the issue is "are these participants greater than the number who take on JIRA".

Indeed those hundreds of people participating in blogs, office hours, forums, and third-party sites constitute "many" – and certainly many more "many" than the "few" who are here running the JIRA.

Most have never heard of it; it is hard to use; its jargon is obscure (take as a glaring example the word "resolved" which doesn't mean solved or closed but means pushed back to you because someone else didn't like it or felt like you should do more work on it – totally counterintuitive).

I don't portray the old system as somehow some stellar robust system. it, too, was clunky. But it had a lot more use for feature voting, and had more integrity. Here are its main salient features:

o no one could close your proposal or remove it or merge it without your consent
o the interface was simpler for just opening up the box, writing in it, and starting the vote
o the dashboard for seeing where your content was opened up automatically without you having to configure it
o the key word search seemed to work better
o by having links to forums or blogs where the debates took place, rather than comments, there was less of a sense that anyone could kill off other votes by putting up their sole comment in sharp disagreement that in fact contained bias and errors – it's easier on a forums to notice where a thread is going and respond to it – comments left buried in JIRAs aren't at the surface
o the FVT contained the helpful point that you should first discuss the idea in the forums (later on a third-party site) before finalizing it and posting it
o the FVT was not confused and harried by having to compete with bugs for attention, or be confused with bugs; it was understandably separate

While you may have met "very few people" who took part in the old voter, the record of it shows that it had thousands of participants. That participation for features was greater than what we see here, and given that there are many more people in SL than there were then, we should really see more.

Basically, the JIRA is useless, except to a small cabal of techies who will fight to the death for it since they understand it....and can manipulate the hell out of it with the small number of voters/users.

As far as ease of use, its like every other OS program out there. Confusing interface, cryptic commands, designed by techies for other techies. it IS hard to use and obscure at the best of times. But the techies love it, as it reinforces their feelings of superiority over the 'end lusers'. Note the condenscension of one user above about how its not hard to use, and how she refuses to acknowledge there is something broken with JIRA when any chimp can close someone's issue...but hones in on the lack of notice and lectures about 'watching the issue' and how folks 'don't care if they don't watch'. Some of us have lives outside of SL and the JIRA, we care but may not have time to piss around with defending a post from the techies out to close things as a mode of control.

ANYTHING would beat the hell out of the JIRA for voting....absolutely anything, including mailing postcards to LL.

Put your money where your mouth is. Commission it yourself.

The feature voting tool was an illusion of democracy, nothing more. It got nothing done, It went nowhere. It served little purpose other than to give people a place to rant, so they could be easily ignored.

Jira is progressing. Things get fixed .Things are debated here, new solutions forged.You cannot simply ask for a feature and say "do it". Yet the FVT was full of exactly that. Issues on jira provide solid, actionable details. Designs, implementation plans. And they get closed if they don't.

Another flaw of the FVT that you somehow see as an advantage, is the fact that discussions play out in the forum. A forum which only payment info on file users have acess to, and from which you yourself are banned. Explain that one.

Noone closes features to control. We close things which cannot be done, or are not clear about how they should be done.

Things get debated, yes but usually by the same very small band of users (of which I am one). FVT may have been an illusion of democracy, but JIRA is not democracy at all, because so few use it and voting levels are abysmally low.

Warkirby, if you are worried about rants, then support a Faeture VOting Tool without comments. Trying to force everything into JIRA because you like it is ignoring the fact that more users ignore JIRA.

On the other hand it may be that JIRA just can't do the things required, or that it would be far quicker to use some other sort of tool.

I don't know. One of the problems here is that we are entering what seems like an uncharted area. Most issue tracking systems are meant for use in business situations, where there are unlikely to be great and intrinsic disagreements. When there are, they tend to fall apart a bit, and matters have to be resolved through other means (usually politicking and backbiting in my experience, but that is another thing) and then resubmitted. The situation is rather like wikis - whilst, say, Wikipedia has proven wikis can handle lots of violently disagreeing people, it also shows that they are not very good at it, and that lots of moderation is required, and in some cases seemingly arbitrary locks and bans as well as constant vigilance.

Second Life is not a business (Linden Lab is the business), there is a great plurality of and lack of hierarchy within residents compared to business employees, and residents will disagree, often strongly and vocally. This is not a bad thing. It results in a wider view of issues that cannot otherwise be gotten. But it means that business tools may not be suitable.

Regardless of how it is to be achieved though I think that there are a couple of points which are essential:

• The current JIRA interface is horrible and unintuitive and needs changing. I find it irritating and intimidating, and I am not what you'd call the least technical of people. Not only does it put people off reporting things at all it adds to the number of misplaced issues.

• For feature requests, a "no" vote is definitely required. This is standard across the internet and society and history in any case where you want to get feedback on what people think of something - opinion polls don't just have a "yes" box. When it comes to simple bugs it may be the case that a system can dispense with "no" votes as people rarely object to bugs being fixed, they just have different priorities as to what they want fixed first, but feature requests aren't in this category.

Features do not require technical expertise to make nor can they be the domain only of tekkies to "implement them". Sorry, but tekkies – and this particular bunch of tekkies don't get to take over a shared, user-generated world where many have a variety of stakes.

Oh, everything about Second Life is an illusion. If you are going to go start knocking SL for being an illusion, you might as well go back to bowling alone in Real Life. That's not an argument. The FVT was enough of a democratic, participatory tool to matter. It did not go nowhere; Lindens cited it as justification to put in p2p the way they did, merely on the strength of many votes. There were changes to land menu and group tools made through this device. Why, we even got a Pony in the Welcome Area! It was a good way for people to refine and gain support for their actual proposals to the Lindens in an organized way. Far from perfect, but good enough – and more user-friendly than the JIRA.

The JIRA is only progressing in the minds of those few who control it. To others, it is woefully out of step. The FVT provided mainly doable features, they were the overwhelming majority. Those that weren't doable in fact surprisingly more often than people admit became doable far down the line. Who would ever think it was possible to paint the sky pink? Now Windlight is being put in. And so on. The idea that something is "impossible" or "can't be done" shouldn't be part of the Second Life vocabulary whatsoever. Leave out the pie-in-the-sky ideas to gather support – or not. Time them out. And if they are rabidly popular, then people will actually start to figure what part of them might be done.

Getting something closed is a controlling, death-like objective. Indeed, the manual to the JIRA speaks of the closed state as "the final resting place". What if someone said "Make it so I can have one-prim soft rounded pillows" and it was closed and put in its final resting place? Where would sculpties come in? It's absurb in a user-generated open-ended world that is dynamically changing to posit that there have to be so many closures and false resolutions and fake victories. There don't have to be.

Currently, there is no longer a place to discuss feature proposals as there once was on the forums with the rubrics "land and economy" and "polysci" or even "general." Being banned, I simply linked to third-party sites or my own blog for discussions. Forums that are free are better places to discuss things. People here are always fearful of being blasted by the insiders, or worse, banned by the Lindens. It's not a scientific place; it's a corporate place, and free discussion necessary for science cannot take place here as a result.

There is no "we", WarKirby – no "we" that any masses recognize with authority. You are not the judge of what cannot be done. You cannot be trusted with even routine matters given the invective, emotion, and hatred that you put into this simple proposal merely to obtain consent. Is "consent" alien to your vocabulary?

http://www.secondlifeinsider.com/2007/05/05/exploring-jira/ by Eloise Pasteur, a long-time and respected SL resident and educator who is also a tekkie

http://www.knowprose.com/node/17549 by Nobody Fugazi, a tekkie himself, who titled this piece, "Navigating Into the JIRA Dungeon: SecondLife Bug Reports and Feature Requests and the Skeletons Who Love Them"

http://www.secondlifeherald.com/slh/2007/08/second-life-sta.html – low percentage of bugs solved

http://www.lovelymachine.com/Dolmere/2007/07/los_arboles_and_jira.html – can't get a simple thing like the dumb typing animation permanently turned off forever

http://materialsquirrel.blogspot.com/2007/05/jira-tutorial.html "very intimidating to the average user"

http://ordinalmalaprop.com/engine/2007/11/25/jam-tomorrow-jam-today/ – putting solutions off to the bright future, confusion on the word "resolved" or "fixed internally"

http://suebaskerville.blogspot.com/2007/06/merging-unrelated-jira-issues-is-bad.html – a tekkie notes that people on JIRA merge unrelated issues

http://blogs.computerworld.com/node/6089#comment-70420, dated Sept. 24, given the date, NOT commenting about any debate I've been in: "I could not believe the amount of anamosity displayed by the various residents towards each other and towards Linden Labs, the creators of Secondlife!"

"It was like Chinese to me," says a blogger about the JIRA, who then dutifully tries to write a tutorial, that is even more complex...

I've summarized a lot of the problems myself here:

http://slrecord.typepad.com/the_second_life_record/2007/08/jeering-the-jir.html

Come into any office hour, public meeting, forums and ask for genuine, honest feedback – you will get it.

Feature tracking systems are a black hole for customer service organizations; they are never perfect, and are fun to develop. Currently LL has such limited engineering resources that spending a huge amount of time harvesting feedback on and prioritizing feature requests seems to me to be just wasted effort.

The way it works in most engineering groups of LL's size is that nearly all requested features will lay dormant until an engineering project in that area is launched. At that point the leader and/or program manager for that project will harvest ALL related issues from Jira, and decide which will be addressed. Imho, the current feature tracking system is sufficient for that process.

No one needs any Lindens harvesting, culling, clucking over it, doing anything at all. The Feature Voting System should be for the communities of SL to propose, revise, make compromises, and settle and when they finally have a bill they have passed, to send it to the president/i.e. Linden Lab for yes or no – that's it. Many issues will never attract enough work on them, or enough votes, to reach the threshold where LL should pay attention.

If you wish Linden Lab to follow the will of the people, there would be no Feature Requests accepted at all. The will of the people as presented to Linden Lab in the form of the Open Letter was very specific in stating that they wished to have "No New Features". This would include any new feature developed by Linden Lab or sugested by any other resident. And with 5,000+ votes on that proposal. I feel the community would be hard pressed to stand together in solidarity enough to vote on a new Open Letter to overturn that proposal.

Yes there are issues with the JIRA as it is. But they are getting better because there are people who are working to make it better.

Would a seperate Feature Voting site work better? I'm not so sure. There are many benefits to having the system in JIRA.

• Feature Requests can be linked to related bug reports and features
• Discussion of a Feature Request should always be retained with the request. Off site discussion can and does dissappear.
• Features accepted for development are tagged visibly as such
• Tracking of feature status is available

A new top level project for Proposals could be created, and even named PROP, fulfilling your PROP-101 requirement.

Of your proposed feature requests, I only see one that can not be done with JIRA as it is right now. And that is merging proposals and votes. Which would be a difficult process even in a custom system as every vote would have to be compared between proposals to remove duplicates, and you may end up with a merged proposal with no more votes then you had in one proposal.

You often take a very literal and strict construction on things. When the Open Letter people discussed no new features, they were no different than Philip Rosedale himself saying that LL would in the next quarter be focusing on bugs and stability rather than new features. Exactly the same thing.

You seem to fear representative democracy and the will of people expressed in the form of 5,000 protesters. You imagine that the technical elite, a small group, can do better, and the people are stupid and don't know what's good for the platform or even themselves if they'd bar "any new features" from the system. Yet their voice is very important, must be heard, and they will be right sometimes and there must be mechanisms for expressing this and taking it on board. Even tyrants want to have a fake election to make it look like they got the vote.

Feature proposals do not need to be related to bugs, unless someone determines that the request for them is in fact the function of a bug. Of course Gigs Taggart tried to do that with my earlier proposal to move a simple button on the user interface for the group tools to make it easier to add powers in the groups. It was a simple, eloquent solution to about 4 problems with laggy and buggy group tools, yet Gigs resisted it because he didn't want "simple and today to workaround" he wanted complex and detailed and thorough involving 4 bug solutions.

There is nothing so sacrosanct about the sometimes miles of talk that goes into building a feature that it all has to appear as a long trail on the proposal in its constantly revised form. When a bill becomes a law on Congress, nobody attaches the lengthy transcripts of debates on the senate floor; the text speaks for itself.

The old FVT perfectly well tagged items accepted for development or obviated by new developments.

PROP isn't an abbreviation for "proposals," it's the abbreviation used for "Propositions" in real life, like "Prop 87" for alternative energy. Have you ever voted in a real-life election?

It doesn't matter if a merged proposal has the same votes. And I cannot believe that it is impossible for a piece of software to take two lists and merge them and remove the duplicates.

I didn't know UI buttons could talk.

I'd suggest letting the JIRA "bed in" for a significant period of time before trying to evaluate if a different feature proposal tool is required. At the moment it seems to be doing a reasonable job of letting users express an interest in fixes / features, though I'd argue better maintenance of the database either by volunteers ( we salute you ), or Linden's ( we pay you! ) would improve that.

It's easy to get disillusioned with Linden progress on the few issues one is watching, I've been there myself, but if your take a careful wander through the meeting minutes and information available on the wiki, then keep dipping your toe in the SLDEv traffic, it's apparent that a LOT of JIRA information is at the very least considered.

I'm afraid it's the same feedback problem. I've seen at least one problem that I know has been looked at in detail by a Linden Dev be resolved with the simple line "Needs more Info". This doesn't do the Dev's any favours as it looks like it has been closed with little thought or attention when it probably actually absorbed a few hours of Dev time.

The same is almost certainly true of "Won't Fix" feature requests. It's easy to read that as "Can't be bothered" and be personally insulted if it's your issue, rather than assume it has been discussed and considered.

Note: I am not a Linden fan boy, and give them grief at times, but ... the bane of terse internet communications like "Won't fix" is the lack of information behind that decision and the ease with which that can be read as a rude slap down.

llOwnerSay("This product could be better if you went to [my feature request]">http://jira.secondlife.com/browse/[my feature request] logged in and voted 'yes'.")

Yes, DO use OwnerSay, and yes, DO use any other means you can think of to avoid spamming people's chat channels. I use the touch_start event to throw up an about dialog with such info on items that are sit-by-default and don't need the touch action for anything else. Or add an extra button to a configuration dialog, if appropriate.

like, users can even click the hyperlink from the chat history!

OR (on your personal/corporate web pages, or your profile web page)

[p][a href="https://jira.secondlife.com/sr/jira.issueviews:searchrequest-printable/temp/SearchRequest.html? & reporterSelect=specificuser&reporter=LaeMi+Qian & sorter/field=issuekey & sorter/order=DESC"][strong]My SL feature requests[/strong] (external link)[/a] feel free to vote for any you like.[/p]

For example ;-P

I really don't see that VOTING on JIRA issues is any harder than logging into anything else on the internet - finding issues and creating them is more of a step, but I don't think ANY system can streamline that to the point of llDoWhatIWantNow(key my_brain).

Finding a way to merge proposals and preserving each proposal's votes would be real progress.

I'm more convinced than ever that feature discussions and votes do not belong on an "issue tracker" of this nature.

SL as a service has a way to poll everyone in the world.
The system for features, direction, governance, could be: anyone can propose.
If they get enough signatures to ratify, then send out an llDialog poll to everyone in world:
Proposition X: Yes? No? Later? Do Not Care?
Then collect the numbers.
Done.

Oh, yeah, if its "our world" then that should apply to LL ideas too.
If its a business thing, then explain it to us.
If we like it, then you just got stakeholder buy in.
If we hate it less than other ideas or issues, then... there you go.

Personally, I hate having to follow 50 different websites as part of my 3D world experience.
Moving something like this in-world would be preferable.

No the new "closed" is resolution:"Under Advisement"