Second the Vote

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.

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.

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.