Renegade Projects Network Forums

Full Version: Proper filing of a feature request
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
In light of recent developments I have decided to start actively enforcing the feature request submission rules which have been public for two and a half years now, and still continuously get ignored.

For the last time, this is how a proper feature request looks like:

The submission rules Wrote:How to request a Feature
Go to bugs.renegadeprojects.com. Click on Login. If you have an account, log into it. If not and you want to be informed about your request's outcome, plan to request several features, or want to report bugs later, click Signup for a new account and register; if not, click Login Anonymously. Once you are logged in, either normally or anonymously, click on Report Issue. If you didn't do so already, the system will ask you to select a project. Choose Ares and click Select Project. Now set:
  • Category: Feature Request
  • Reproducibility: N/A
  • Severity: feature
  • Product Version: empty
  • Summary: A one-sentence description of your request - this is what will appear in the issue list, so if you want us to actually read it, summaries like "ADD THIS PLEASE!!!1!!" are not a good idea.
  • Description: A detailed description of your request - don't write novels, but the more details you have, the easier we can assess the wish.
  • Additional Information: What the title says - possibly a summarized list of the suggested ini flags or something like that. Anything you have in your head about your wish that doesn't quite fit into the request as such.
  • Upload file: This is mainly used for bug reports, but if you did something like a photoshop mockup of your request, you could attach it here.
  • View Status: Public
  • Report Stay: If you wish to return to the report form to add more requests or bug reports, check this.

Afterwards, click Submit Report. Congratulations, you just requested a feature.

In addition, the Priority must not exceed "normal". If it does, the feature will not count as properly filed.

Also, as anyone who has followed tracker discussions knows, an actual usage case for your request is vital.
We don't implement features just because someday, somewhere, an unknown modder might perhaps eventually have a good idea that your request could possibly be absolutely essential for.
Either you can show what your request is good for and that it'll be interesting to the community at large, or its priority will dwindle significantly.

As of 30 minutes ago, every feature request not adhering to these guidelines will be suspended immediately. Duplicating it will only make it worse, duplicating it improperly will pretty much guarantee it'll be ignored forever. If the system allows you to, you can re-open/edit and fix the issue, but rest assured, reopening and leaving an issue improper will not increase our goodwill.

I would like to stress that these rules aren't new. These have been the submission rules ever since the tracker was installed. In the past, we just didn't actively enforce them. Due to the increasing amount of crappy, improperly filed requests we're getting, this time is now over.

In addition, I would like to point out that we're kind of tired of getting spammed with bullshit issues, and that we will employ additional measures to counteract them if necessary - this can range from enforcing registration before request, to an increased number of immediate closings, to an all-out referral of all new issues to a committee of trusted community members who weed out issues and decide what we'll look at in the first place.

We're not doing that just yet, but rest assured, the options are there, and we're ready to make use of them if necessary.

For the curious: 37% of feature requests in the past 16 days have been closed immediately, and out of those, 43.75% were duplicates.