Second the Vote

Comment on feature proposals with Hoodwink.d

While forum threads are useful for discussing feature proposals, they have the impedances of being neither in place on the voting pages nor available for every proposal. (While you could open a thread for a threadless proposal, there's no way for you, the good samaritan, to add the link.)

So it's interesting to consider a system such as Hoodwink.d, a third party system using client side code to add commenting to any web site. This idea has been around for quite a while, such as in the original buzz-catching startup during the first dot com boom, ThirdVoice. ThirdVoice's current web legacy now mostly comprises the anti-ThirdVoice activism from back when people cared about it, provoking much the same reaction as Microsoft SmartTags did. As Hoodwink.d does the same thing as ThirdVoice--enables viewers to add "hidden" comments not under the control of authors--if it becomes popular, I wouldn't be surprised if it receives the same welcome from proponents of hardline authorism, as well as people who (quite rightly) simply don't see the point.

<Neill> what's the added value? the ability to mouth off about something you saw on the web? to your circle of friends? there are not already technologies to do this? am I not using such a technology right now as I'm typing this?

If you're interested, don't worry too much if you don't understand the "main" Hoodwink.d page; it's deliberately obtuse for (supposed) coolness. The first step is to make it possible to visit the real Hoodwink.d page, as described at this "absolute simpleton's guide" to step one. Once you can visit hoodwink.d, you can register and set up the service, which requires either Greasemonkey for Firefox or a Ruby page-rewriting web proxy called Mousehole.

Take care with these user scripts, though. Because Hoodwink.d has to ask the server for instructions on where to place its commenting apparatus, the script will report to Hoodwink.d what web sites you visit. You can easily limit these by setting the Hoodwink.d user script to only run on certain sites. This also saves time as the Hoodwink.d JavaScript doesn't have to run when other pages load. To do it in Greasemonkey, go to Tools → Manage User Scripts, select the "Hoodwink'd!!" script, then change the URL patterns in the "Included pages" section. Remove the * entry and add patterns for specific pages, such as http://secondlife.com/vote/*.

All was well and good when I was trying this out, until I found that the feature proposal site links to strange URLs for the proposals, which broke the way the Hoodwink.d script showed comment counts. So I wrote an additional user script that seems to fix it. After installing Hoodwink.d and that script, the feature proposal site should have magically grown blog-like comments.

This is a very roundabout way to discuss it, but I have to confess that the continued misuse by residents and lack of Linden gardening of the voting system makes me much more likely to contribute snide comments in a private register like Hoodwink.d than to post constructive criticism on this site. You, being the kind of person who cares enough to read drivel like this, generally don't need my advice. I really have to look at the projects I have on the table and think, why bother?

However I'll cut the self-effacing blather there, and share a discussion question instead. What positive action could you or I take to cut the endless torrent of crap into the feature system? Adding a third party discussion system like Hoodwink.d is a possible answer, but I'll be surprised if it's used as more than a snarky backchannel.

Make your case

Obviously you think your idea is a great, viable feature concept, or you wouldn't bother proposing it. However, the value of a good proposal is not self-evident. (If it were self-evident, your idea would probably already have been proposed.) Therefore the purpose of your proposal is not only to describe your idea, but to convince other residents of its worth.

✓ Make your case.

A surprising number of proposals don't even try to sell the reader on the idea. Take for example yet another voice chat proposal:

Voice-For Secondlife: 52 votes/24 voters

I just have to say that I love this game, I can think of one thing that I believe will make it even better....Voice. Or some type of option in SL to able us all to talk to each other at once voice to voice.

While the proposal asserts that "I believe [voice chat] will make [SL] even better," no reason or argument is given. This is quite like the classic advice when writing fiction, "Show, don't tell." Your proposal should not tell us what a great idea yours is; it should show us, through a reasoned argument you've considered fully.

Neglecting to present your argument is a good way to avoid thinking it through. Part of presenting your case is to present it clearly and effectively. Several recent proposals present rationales, but indicate insufficient consideration for the reader's understanding (to put it nicely). For example:

Disable camera clicks on your land: 5 votes/5 voters

I would like to propose that the LL make some sort of option so that the taking of pictures on one's land should be able to be disabled.

Particularly useful if you are running large displays and such.

First, perhaps I'm not in world enough, but I have no idea what this author means by "large displays." I assume the author means artistic displays like you'd see at Burning Life. In that case, why would disabling snapshots be "particularly useful?" While some real world museums prevent photography, what use is that in Second Life? If you did prevent snapshots from being taken by someone on your land, what prevents someone from moving to a neighboring plot and taking a snapshot from there?

If you've made your case properly, your reader has fewer questions, not more. Those are the questions you want your reader to have: the ones that relate to the core issue. If this proposal properly made its case, my only question would be, "Should land owners be able to control what residents can snapshot?" and I could vote for it if I agree.

Even if you think your idea is obviously good on its face, having to compose an argument to that effect is a good way to discover flaws. It's one last chance for you to think through your request before presenting it to others, and there are a few interrelated things to keep in mind as you do.

• The motivation. Your core argument should present the motivation for implementing your proposal. That is: why bother? Consider if the goal of your proposal is aligned with the residents' goals, or the goals of Second Life as a whole.
• The stakeholders. Your proposal should improve the SL experience for all involved parties. The first question then is: who is involved? While a feature may improve the world for the average resident, it may be against the ultimate interests of content developers, script developers, paying customers, landowners, or Linden Lab itself and its investors.
• The counterarguments. If you're asking for something new, Linden Lab hasn't seen fit to add it yet. Make sure to consider the reasons why that might be. Would implementing your idea unbalance some system? Under what conditions would your suggestion be a bad idea?
  

When you fully present the rationale for your proposal, not only will readers clearly understand your idea and its benefits, but you will be convinced anew that posting your proposal is the right thing to do. Making your case is something all too few proposal writers do, yet it's an important and necessary ingredient in a good proposal.

Don't ask for things you can do yourself

Discussing the OpenID proposal, Cienna Rand had a great suggestion:

[W]ould it not be possible to create a resident-run openID server? One group could handle the verification of who you are in-world and then provide authentication to others. Adoption could be driven by other third party sites referencing the community server.

This is exactly something I intended to discuss, only I hadn't quite thought of it in this context. Yes, it would be possible to build a passable OpenID server without help from Linden Lab, and that's a flaw in my proposal. (So now you know, for the record, I'm not perfect.)

✗ Don't ask for things you can do yourself.

Many of the suggestions I give are designed to prevent work on the part of Linden Lab to manage the proposal system. The biggest thing you can do to make less work is not propose features you don't need. The biggest group of these are plain old bad ideas, but many of them are simply things that you don't need Linden Lab to do.

When I thought of this rule, I had seen a proposal similar to #469 Listening to your favorite music regardless of land, which is short enough I'll quote it here:

Give players another audio control that gives them the ability to locally listen to their MP3 collection or enter a URL to listen to their favorite streaming audio.

This is a useful feature that everyone should agree should be possible. The reason this is a bad proposal is because it already is possible: when you play Second Life, you have at your disposal a whole computer, capable of doing wonderful amazing things such as this. If you want to listen to your music or a stream of your choice, you are fully capable of running a separate music player program designed specifically to do exactly that.

I hadn't connected that thought with the OpenID suggestion, but it still applies. You could very well build your own OpenID server for Second Life accounts. It would still have to verify you in-world instead of through secondlife.com, but residents would only have to do that once, not for every site. You would still have to remember an additional password, but it would only be one, not one for every site. That would improve the current account situation, and still encourage third-party web sites, though perhaps not as much as if Linden Lab built it.

However, many things are possible through hacks and workarounds. How does this rule not prevent almost every suggestion? Those "but"s are the main reason. While a resident-run OpenID server would be both possible and useful, it would really work better as an automatic process without the in-world validation step. In this case, there's also something to be said about trusting secondlife.com's authority with Second Life residents more than, say, openid.slworld.com. If your own idea requires too big a hack or too messy a workaround, you might go straight from idea to proposal.

Building your own OpenID server would best serve as a proof of concept for Linden Lab's implementation. Any idea that's reasonably implementable by a resident should be implemented first, to prove it works and that it would make a good feature. Science tells us your proposal will be one thousand times more applicable with real proof and experience behind it. And who knows? You may find it wasn't such a good idea after all. (Not that that would happen with your idea, of course.)

In both the client and the world, it's in Linden Lab's best interests to leave out features. A lot of making good software is making a good interface, and a lot of designing a good interface is leaving out as much as possible. Apple is historically the king of leaving things out, but Linden Lab prides themselves on it too, in that the Second Life client is a relatively slender download in the neighborhood of 20 MB. (They then depend on it by not having patches when a new version comes out, instead redownloading the entire client.) Linden Lab is also a resource-strapped startup, unable to build even the features they want to do as fast as they'd like.

Leaving out features is absolutely critical to Second Life's development, so it's remarkable and wonderful that Linden Lab is still so open to accepting community suggestions. You shouldn't squander their limited resources by asking for things you could already do or make yourself.

OpenID proposal posted

I created a forum thread for the example OpenID proposal I posted here and fully proposed it. Feel free to offer feedback on the idea in the forum thread, and feedback on how I could improve my proposal on the blog entry.

Proposal: Offer resident accounts as OpenIDs

Here's a proposal I wrote today:

Residents should be able to use their SL accounts as OpenID identities. Allowing residents to authenticate against their Second Life accounts on third-party web sites with the OpenID protocol would benefit residents and third-party content creators alike. Creators of web services such as Snapzilla, SLboutique, and Landmarker could allow residents to sign in directly with their Second Life accounts instead of requiring separate registration and in-world authentication. Residents would be able to use fun and interesting third-party services without registering and without revealing their Second Life passwords.

For example, if Landmarker provided OpenID support, Alice Example might enter her name in a "Sign in with your SL name" field and be directed to secondlife.com/openid/ . There she would sign into secondlife.com (if she hadn't already signed in) and confirm she would like to sign into Landmarker. Then, using the OpenID protocol, secondlife.com would confirm to Landmarker that Alice is who she says she is (eg secondlife.com/users/Alice_Example ) and Landmarker would treat Alice as a regular user of the service. This is the standard way OpenID servers work.

Documentation for OpenID is available at http://www.openid.net/ .

I observed the guidelines I posted about here, and some that I plan to write about in the future. I checked for previous proposals for my feature and wrote a good title. I made sure my feature is not something we already have by a different name, and that it's not something I can do myself. I also made my case, suggested a possible design without presupposing a solution, and checked my spelling. I won't post it to the vote system until I have a discussion URL for it.

This is, in my opinion, a good proposal. What would you change?

Write a clear, complete, accurate title

The first thing people see when seeing your proposal for the first time is your title. People who don't even click through to read your actual proposal are going to read your title. That makes it the most important part of your entire proposal.

✓ Write a clear, complete, accurate title.

Your title needs to convey your entire proposal in eighty letters. Your description can be almost 32 times as large, but should only elaborate on your idea. The essential gist of your proposal should be in the title.

Your title should be clear. To that end, unless your proposal asks for a completely new feature, your title should also be a command. Think of your proposal's title as finishing the sentence:

Lindens, would you...?

More specifically, your title should be a full sentence in the imperative mood. Currently titles are often written as noun phrases with no verb at all; that's appropriate when you're asking for a new feature, as that's the name of the new feature you want. However, by itself, that title would leave a reader not familiar with Second Life unclear whether you want the named thing added, removed, or changed.

Here are some recent noun phrase proposal titles that can be punched up as imperative sentences:

• SL IM Timestamps → Show timestamps in IM
• Better lag detection mechanisms → Improve lag detection
• Mouse Look Movement → Allow avatar movement by right-dragging

When your proposal is for a completely new feature, you can use a simple noun phrase. Here are some good noun phrase titles:

• llGetParent() - Return the key of parent object
• Orthographic views for editing
• Animated particle textures

Your title should be complete. While you can say a lot more in the proposal body, all the important parts of your proposal should be in the title. For example, when proposing a new LSL function, your title should be what the new function will do, not what you think that function's name should be. If you can't write a complete title because your proposal has several parts, that may indicate you  actually have more than one proposal.

For example, "Clothing offline" is vague. It could mean Linden Lab should require users to wear clothes at all times, with a system of webcams and advanced AI anti-obscenity software. Instead it's a proposal for an offline clothing editor and previewer. A more complete title would be "Allow offline edit and preview of clothes."

Lastly, your title should be accurate. It should say what you would actually like the Lindens to do, or at least state the problem you would like them to solve. "Unmute music" is a bad title when you actually want the ability to mute game sounds and leave music playing; "Allow muting game sounds" is more appropriate. While the distinctions aren't that great, they're important when trying to get your message across in a proposal title.

While it's not fair to judge a book by its cover, people will. People will especially judge your proposal by its title. You should make yours clear, complete, and accurate to give your proposal a fair shake at gathering votes and getting accepted.

Don't ask for Linden Lab to go out of business

As a general class of proposal not to make, anything that requires Linden Lab to change its business model will not happen in the short term. Anything that requires Linden Lab to stop being a potentially viable commercial concern is simply not going to happen, ever, if the Lindens can help it.

✗ Don't ask for Linden Lab to go out of business.

It is reasonable to assume that you would like Second Life to continue to exist, in which case you probably do not intend for Linden Lab to go out of business. When writing your proposal, you should keep a few things in mind:

• Linden Lab has to make money. While it did receive US$8 million in venture funding, you aren't given that much money unless the people who own that money think you can turn it into even more money. Any proposal that would not create a sink for money or time (after all, time is money) is simply not going to be accepted.
• Linden Lab has legal responsibilites. Many virtual worlds operate as temporary autonomous zones, but they are largely volunteer-run and non-commercial. Linden Lab is a legally incorporated entity with a board, officers, and physical offices (I've seen them, they're not shabby). It's required to operate Second Life within the laws of San Francisco, California, and the United States of America. Some rules you are asked to accept are required out of simple legal necessity. (Those very same rules suggest I should state that I am not a lawyer and this is not legal advice.)
• Linden Lab does not need to please you individually. As a corrolary to the need to make money, Linden Lab has to please its customers to keep them paying. Depending on their business model, this may or may not include you. (I know it doesn't include me.) While Linden Lab may choose to cater to your needs, that's because your needs match most of their paying customers' needs, directly or indirectly (for example, free accounts are good because paying land owners need a customer base to buy their virtual goods). No one's needs are more directly important than paying customers'.

These are important factors to keep in mind when deciding if your idea is viable enough to become a proposal. However, they have subtle myriad ramifications when you actually work through them. Take care when deciding your idea is good enough to propose.

Requests that would add new terms of service or exempt some residents from the rules are mainly not worth considering. The rules have been worked out as a compromise between business managers and the company's lawyers to balance business needs against legal liability, and are only indirectly informed by the product design. While the terms of service are open to discussion, I wouldn't think that discussion is best undertaken in the feature voting system.

Don't ask Linden Lab to give up revenue without proposing how to replace it. Celebrated skeptic Carl Sagan said, "Extraordinary claims demand extraordinary evidence." Your suggestion of an obvious way to make less money is extraordinary; you'll need an extraordinary proposal on how that causes you to generate more. You can't suggest SL be 100% gratis then wave your hands, "I dunno, sell ads or something." Many proposals aren't that obvious, but have similar effects. You might suggest open sourcing Second Life to improve the quality of the software. How does Linden Lab then recover the revenue lost by competing with other providers of Second Life service? There are ways, and many people believe it's possible to compete in an open source market, but Linden Lab would need an ironclad business case to consider creating direct rivals.

In a manner of speaking, all esoteric feature requests are in this category, as they are demands on Linden Lab's limited resources. New features have various costs: designers' time, engineers' time, the support staff's time, and usability impact to name a few. Any feature that doesn't generate at least its cost in revenue is not worth accepting. While that's hard to measure directly, a good product designer can simply tell that some feature requests are too esoteric to be a net positive revenue addition. (That's what makes them good product designers.) Some of these strange proposals seem to be the first time their respective ideas have been exposed to public scrutiny. Your ideas would be well served by being discussed before being put to a vote; you can always add a proposal later.

Some proposals, such as #369 Limit ability of land barrons to monopolize property and #391 Increase L$ Supply, relate not to Second Life's operation within a free market but the operation of a free market within Second Life. This is an important distinction, similar to how the first amendment to the US Bill of Rights guarantees citizens the freedom from government restrictions on their speech, but not freedom from actions of private citizens or organizations because of their speech. These are not the cases I mean here; I hope to cover these issues separately later.

Lastly, when proposing Linden Lab close up shop, the unspoken scenario is if you do, in fact, want Linden Lab to go out of business. You are free to espouse that notion, loudly and publically. However, the feature voting system is not the appropriate venue. There are SL forums in which you can vent, and many weblog services that would be delighted to receive your business. An entire internet is at your disposal; please don't clutter Linden Lab's feature feedback mechanism with your discontent.

I hope you'll keep these points in mind when wishing for changes and new features. While Second Life is an amazing experiment in personal freedom, Linden Lab simply cannot comply with requests that they cease to exist. You shouldn't ask them to.

Don't ask for voice chat

For this blog I'm keeping a series of specific proposals you should not make. These are popular requests to propose for one reason or another, but there are good reasons (or, at least, reasons) why Linden Lab won't commit to those features. The first of these I'd like to talk about is voice chat.

✗ Don't ask for voice chat.

First, people already have, as you should have discovered in the old proposals.

• Directional Voice Over Internet Protocol for live chatting: "Can we please do away with an exclusive reliance on typing to chat? Let's have live voice that is directional (sounds appear to come from their given source) so that people can communicate with other people through voice." 327 votes/139 voters--so if you want to vote for voice chat, vote here!
• Voice in SL: "it would be great if we had voice in SL. To me it would be easier to communicate i dont know if it would cause lag problems but while i run another program to talk to my sl friends i get no lag." 2 votes/2 voters
• Voice Chat: "the ability to use voice in SL" 3 votes/3 voters
• Voice in SL: "Just like in There, Secondlife should have a voice option for it's users. It should be able to be controled just like the video and audio volume, so you can have it on when you want to :)" 64 votes/30 voters
• How about some Voice function?: "I mean even THERE has a voice feature so we can talk to our friends and dont have to type, i think this would be really fun to have, but should probably be set so you can only talk in IM windows to reduce lag/and loud children flooding sims with their screeming. but if impemented into an IM it would be great!" 107 votes/32 voters

As you can see, the total votes for voice chat actually number 503, while single individual voice chat proposals have at most 327 votes. For current vote counts, 503 votes would make voice chat the 15th most popular proposal. As discussed last time, combining like proposals would bump several other proposals up, but 503 would still put it at least around #15.

Second, there are plenty of third-party services that offer voice chat. (One of my general "Don't" guidelines will be "Don't ask for something you can get with third-party software" once I can put those thoughts together.) SLUniverse has a list of voice chat services, including all the major IM systems. There's also Google Talk, which goes to show there are new voice chat services popping up all the time. SLUniverse also runs a Teamspeak server, with easy instructions for using it. While no third-party service can offer location-based chatting, you can get the equivalent of voice IM with any of them.

Lastly, there are philosophical objections to implementing voice chat in virtual worlds. The best piece on this topic is Not Yet You Fools! by Richard Bartle for gamegirladvance. (Richard Bartle is best known as the creator of MUD. Not a MUD, but the Multi-User Dungeon game.)

One of the consequences of adding real-time voice communication to virtual worlds is that it will attract newbies; this is why marketers want it. Another of the consequences is that when players cease to be newbies they won't stay for as long; this is why designers should be telling marketers they can't have it. ...

Adding reality to a virtual world robs it of what makes it compelling.... Voice is reality.

Cory Ondrejka, VP of product at Linden Lab and contributor to Terra Nova, seems to be wary of the immersion breaking effect of voice chat, while aware of how Second Life residents use it already. He recounts exactly that in his response to a Terra Nova post about voice chat a year and a half ago:

Text allows you to role-play and to be immersed in a way that true voice transmission breaks... and this immersion is important enough to accept the massive loss in P2P bandwidth caused by text chat.

To which Richard, another Terra Nova contributor, responds, "I ought to mention for clarity's sake that there are some virtual worlds for which VoIP isn't an issue, for example ones where there's no central role-playing paradigm. It seems to me that voice in SL as a whole would be fine, although people who have built game-like areas within SL might want the facility to be switch-offable."

So there you have it. There are several reasons why Linden Lab won't agree to add voice chat just yet. Of course, if you still want voice chat, tell Linden Lab by voting on proposal #140. Just don't open a new proposal for it.

Find existing proposals for your problem

When writing a proposal, the most egregious mistake you can make is asking for something that's already been proposed. Not only are you contributing to the noise, but you may very well be splitting the vote for your request, making it less likely to be accepted.

✓ Find existing proposals for your problem.

In a perfect world Linden Lab would notice and combine all votes for a particular feature. With so many proposals, Linden Lab will surely look first at the proposals with the most votes. If the total votes to solve a particular problem are split among too many proposals, the community's actual desire for a solution is not readily apparent. Your vote could be overlooked.

As an experiment, I made a list of the top 100 proposals by vote count, and tried to collapse multiple proposals for the same feature by hand. Here are the top 15 desired features by vote. Note that while there are five collapsed features listed here, only two of those features were represented in the top 15 before I collapsed them.

#	Feature	Votes
1	Havok 2	2439
2	Try Before Buy	1590
3	Allow multi-select in inventory	1405
4	Point-to-point teleporting (32, 89)	1344
5	Bill of Rights	1281
6	Hide from friends (52, 474, 479)	1140
7	Generalized Texture Layers	1022
8	Better/custom default animations (67, 25)	1011
9	Bring back event support for events other then education	993
10	Native Linux Client	922
11	Object to Object communication	790
12	Non-primitive building primitives (49, 318, 138)	781
13	Real Time Weather	714
14	Mature-only SL (279, 459)	624
15	Register Mafias-No Report Rule	556

If the creators of duplicate proposals had looked for existing proposals that matched their desires, so many issues would not be so ill represented.

While looking for proposals that address your problem, you may find some that come close but don't solve quite the same problem, or don't address an aspect of the problem that's important to you. You may notice that I combined proposals #67 User-Defineable, Replaceable Default Animations and #25 Improve Avatar default animations above. These proposals both deal with the stock avatar animations, but suggest very different solutions: #25 is simply that the stock animations should be replaced with new and better animations, whereas #67 is that residents should be able to select what animations play for the stock animations' events (that is, build animation overrides into SL). While these proposals differ, they both address one problem, namely deficient stock animations.

My advice for residents in this situation is, if at all possible, get in touch with the author of the other proposal and craft a new, combined proposal. The new proposal should address the problem, and suggesting either or both of your solutions as potential remedies. For example:

#600 Fix default animations
The current default animations are not very nice. They could be improved in two complementary ways:

1. Replace the current stock animations with new ones. This would be an opportunity for an animator contest, in the vein of the game developer contest and avatar expo.
2. Enable residents to select animations in their inventories to replace default animations. While this would kill the market for animation override devices, it would encourage new innovation in animations. Default animation selection could be an extension of the existing Gesture system if need be.

So what can be done now, with so many duplicate proposals already filed? In addition to direct action on the part of proposal authors as above, Linden Lab might consider adding a notification system to voting. The system would allow the resident who opened a proposal to notify all who voted for it that there's a better game in town. For example, if someone added a new proposal called "Free pony rides," I might be able to select an option on the page for One (1) pony to send a note to all voters suggesting they confer their votes to "Free pony rides" instead.

This vaguely resembles logrolling, the age old political practice of you-scratch-my-back. Logrolling differs in an important way though: where it's a two-way trade of votes for two issues, a vote consolidation system transfers votes for one single issue to someone else's similar proposal. It would be interesting to consider if such a system could enable actual influence peddling, though.

Until Linden Lab adds such a feature to the voting system (and even then), you should always check for existing proposals that already ask for the thing you want, and simply vote for that proposal instead of starting your own.

Welcome to Second the Vote

On April 13, Philip Rosedale announced on his blog that Second Life now had a new feature voting system. As the system describes itself:

As we make our plans for future development, we'll use your votes to help us decide what to tackle next. We'll look at both how important the feature is to you based on the number of votes it has received, and at our own estimates of the complexity and time involved in implementation.

Since its launch, almost 600 proposals have been filed. However, one of the most recent proposals decries the experiment in feature voting as a failure:

It was supposed to be something awesome and great. It was too... for three days. Now it's a waste of time because it has no credibility. LL doesn't seem to be paying attention to voting, most of the active proposals are pretty moronic anyways, so let's just end this failed experiment gracefully.

Ahroun is right about the current quality of proposals. As anyone who has browsed the list can plainly see, the average quality is atrocious. Here's a sampling of recent stupid proposals:

• more money: "i think we should get more money for our stuppend or allowence" 55 votes/14 voters
• Banned?: "Banned for months because of my age, I applied for Teen Second life, and of course I was still IP banned, and I cannot play Secondlife from any other computer in my house, and I really am hooked on second life, and to think I was playing heavinly, and then boop banned. How to figure out my age? Someone ratted on me...." 12 votes/6 voters
• Upload files, upload bandwidth p/w insted of $L10 per file: "I suggest we get rid of this stupid upload tariff, in favour for a more realistic bandwidth upload limit per week, since half the stuff people upload are real small files anyway, so linden can set this bandwidth say 10mb allowed each week, or whatever they feel they can handle, its fair for all." 47 votes/14 voters

The saddest part about the current state of the voting system is the following truth. It's the truth indicated by successful projects like the Java Community Process, the entire history of successful text-based online communities, and open source software development projects like Mozilla Firefox. It's also where Ahroun is wrong.

It doesn't have to be this way.

This weblog will describe how.