Submit RFE

From WinMerge Development Wiki

Submitting a good feature request is not easy task. This page gives some instructions and hints how to submit a good and useful feature request.

[edit] Rules

There are certain simple rules for every feature request. Failing to fulfill these rules easily leads to ignoring of the request.

1. Only one feature per request. If you want more features, submit separate request for them.
2. There must be a reason for the feature / improvement, and you need to tell us the reason.
3. Give a good and describing summary.
4. Describe the new feature with as much detail as you can and is proper to do.
5. Do not tell us we must do something, or that something is very important.
6. Do not tell us what features other programs have.

[edit] One Request per Item

One easy mistake is to add several (related) feature requests to one item. Unfortunately this makes tracking requests hard for us. What if we want to implement one bug ignore others? Can we close the item when first (of many) requests gets implemented, or keep it open forever?

[edit] Have a Good Reason

We don't add new features just for fun. Implementing a feature might require a lot of work. And we don't need more features just for showing them in adds ("now with 20 new features!").

A good feature request gives answer to question "why?", or more specifically: "why should one developer put considerable amount of free time into this?". Some good reasons can be:

• it improves WinMerge usability (easier/faster to so something, better GUI etc)
• it allows WinMerge to be used in new ways (for real usage cases)
• it improves existing WinMerge features

Some bad reasons are:

• program xyz has it. And we should care because...?
• it makes WinMerge cool. Wait, WinMerge isn't yet?
• your special use case requires it. Sorry, we can't implement personal wishes unless it is generally useful.

[edit] Write a Good Summary

Writing "feature" to the summary doesn't help us, we'd probably just ignore it most of the time. Use a bit of time to think about summary that describes the request so that it is easy to see and find from the long list.

[edit] Write a Good Description

Sometimes we can just say "yes, why didn't we think about that?!" when we see a feature request. Usually we don't, and you have to convince us about usefulness. So why not write a good description that tells what it is about? Better the description is, more changes there is we understand it correctly and consider implementing it.