How to write good feature requests

[Erica]

Dear Dynalisters,

We know you have an exciting feature request that will make Dynalist better, and we’re excited to hear it!

To make sure your feature request has maximized impact and the highest chance of getting noticed and implemented, we strongly recommend taking a few minutes to read this article: https://github.com/rstudio/rstudio/wiki/Writing-Good-Feature-Requests.

It covers a few common mistakes people make and saves lots of back-and-forths if everyone follows them. I’ll paraphrase the post below specifically for Dynalist:

Make sure it’s unique

Your first job when filing a feature request is to make sure that it isn’t already filed. We get feature requests every day, so there’s a reasonable chance that someone else has had the same idea; just search in our forum. If you don’t find it, try to think of other keywords other people might use.

If you find that someone else has already filed the feature request, don’t just move on! Instead, help us know that you’re interested, too:

1. Add a Like to the feature request to vote for it. This helps the request become more visible to the team.
2. Optionally add a comment with any insight and background you have that isn’t already part of the conversation.

Describe your use case

A good feature request describes the context in which the feature will be used. It’s easy to forget to write about context because you already know it so well that it seems obvious! Just like any tool, though, the best improvements are made with a deep understanding of how it’s used.

Vague

Add a button to bulk convert all uploaded files from private to public

Improved

I uploaded lots of files when first starting to use Dynalist. However, without knowing the privacy settings, I uploaded them with the default private permission and they can’t be viewed by my collaborators. I can upload them again, but it’s time-consuming, and I’ve almost run out of my monthly file upload quota.

Describe the problem and propose a solution

Most feature requests only describe solutions – that is, a specific product improvement.

Make your feature request better by describing the problem you are facing, and only then proposing the feature request as one solution to that problem. You might find that the product team (or another Dynalist user) proposes a different solution you hadn’t thought of.

Solution Only

Make it so scrolling with the mouse wheel is twice as fast when I hold down Ctrl.

Problem and Solution

When I open a document, I start at the top. I often want to scroll to the very bottom to add an item. That takes a long time because my documents are sometimes thousands of lines long. I’d like to be able to scroll faster, and in my second favorite program, I can do that by holding down Ctrl while I scroll.

Link to examples and research

Is there already software that has the behavior you’re interested in? What is it, and how does it work?

Can you give a concrete example of how you’d use the feature? A relevant code sample?

What other ways did you try to solve your problem?

Are there any relevant existing standards or conventions?

Can you draw a picture of what you’re imagining?

You get the idea!

State the title simply and succinctly

There’s no need to decorate the title of your issue with words like Enhancement or Request . Use your feature request’s title to state it as simply and clearly as possible, with ordinary casing. This will help other people find it when they’re looking to contribute.

Bad Title

[REQUEST] Scrolling is TERRIBLE on WINDOWS APP, make it 2x faster

Good title

Increase scroll speed on Windows

Don’t disguise as a bug, and be polite

It should go without saying, but unfortunately it doesn’t: don’t file a feature request as if it were a bug. It might feel like a missing feature “breaks” the product for your use case, but that doesn’t make it a bug!

It’s also not helpful to add comments such as “it’s shameful that this request has been ignored” or “it’s been years, why hasn’t this been implemented yet?”. Many people who are reading this use Dynalist for free, and Dynalist has a small team (the 2 of us do everything from development to answering support to buying office chairs). We care very much about our community and we probably love your idea, but we can only do so many features in each month while keeping quality and stability high. Help us focus on the very best ones by writing great requests!

Thank you!

Many of the best parts of Dynalist started out as ideas from the user community, and we’re very grateful for each one. Thanks so much for taking the time to write up a thoughtful feature request.

- the Dynalist Team