Talk:Feature Requests

This page is currently being worked on as part of a project to overhaul the Community Portal. Anything you see on this page may or may not end up in the final version. If you would like to make any suggestions, feel free to leave them here on the talk page. No guarantees that we'll use any of them, but all feedback is appreciated. --Indirik (talk), Editor (talk) 01:23, 22 July 2009 (UTC)

Information required for a suitable feature request

Feature requests will be entered on the community portal by the Community Manager (CM). The CM will not create the feature requests (unless it's his own personal project), nor will he develop them beyond basic organization. All feature requests should be submitted to the Discussion List by the originator for discussion among the BattleMaster community. Once enough discussion has been allowed, and the request deemed to be a good addition to the game, the Community Manager can finalize the discussion, wrap it up, and put it here on the wiki. (Note: The CM has a direct line to the developers, so he should have a good idea for the technical feasibility of any proposed request.)

Remember: The first step of requesting a new feature is to check the existing list of feature requests. Make sure that your feature isn't already on the list of accepted, in-process, or rejected feature requests. Also, check the list of "Frequently asked, frequently rejected" features. These are things that simply will not get added, regardless of how many times you ask.

In order to make sure that your feature request has the greatest chance of being accepted, you should have the following things:

A Name

This is something that people can use when discussing it. It should be short but descriptive. "That widget thing" probably isn't good, but "Widget production by the peasants" should be OK.

Three-line Summary

Think of this as the Executive Summary. It should be enough detail to give a casual reader the basic gist of the idea, but probably shouldn't have any specific mechanics.

Three Paragraphs of Detail

This is where you get the chance to describe your detail in all of its glory. You need to provide all the specific information that makes this a good idea. What does it bring to the game? What differentiates it from existing game mechanics? How do the benefits of this feature justify the work needed to implement it? You should fit your whole idea into three paragraphs (roughly fifteen lines of an e-mail). If you can't fit it all into that much space, then chances are that your idea is just too big. Try splitting it into multiple, smaller feature requests. Try to focus on the core of the idea, and not fall victim to feature creep. You do not need every little piece of detail. Don't get bogged down by listing exact percentage chances of an event happening, or a complete list of options. The dev team is very good at coming up with a lot of twists and turns to build on an existing idea. The key is to get their attention, and convince then that this idea is worth the effort.

Pros and Cons

At the end, provide a brief list of the major benefits of your system. "Provides great RP potential", "Allows for a more flavor-rich environment", etc. Also, highlight any potential problems with the idea. Just because there are unresolved issues with an idea does not mean it will get rejected. Again, the dev can often figure out ways to compensate for or resolve these issues, perhaps by adjusting hidden systems inside the game that are not exposed to the players. The key here is to be honest and objective.

If you can fill out all this information, then you will give the DList community a good bit of material to work with. You also run much less of a risk of the idea getting derailed by people trying to jam way too much (quite possibly unrelated) stuff into any individual feature. ("What do you mean we need to add ship-to-ship combat to this feature?! I only wanted to have my guild title shown in the message signature to guild members!")

Once you send a feature request to the Discussion List, don't forget to check back and make sure that your idea is not being misunderstood, or that some people have found some serious holes in it. Someone may even have some good ways to late the idea to make it better. When you're done, roll all the various desired changed together, and post a recap of the idea. If it's acceptable to the dev team, the CM will post it here on the wiki, and a bugtracker feature request can be created.

Once this feature request system has been implemented, this will be the only approved way to get feature suggestions added onto the bug tracker. This will prevent the bug tracker from filling up with excessive, unacceptable feature requests, or used as a discussion forum for debating the merits of any particular request.

Blech..... more later... --Indirik (talk), Editor (talk) 01:58, 22 July 2009 (UTC)