About Inedo

Feature Request Process

Is one of our products missing something you need? Is there a behavior quirk that is causing you lots of headaches? Let us know! Your bug might just be our next feature.
As part of our open culture, we are publishing our feature request process (along with a few helpful tips).

HOW DO I SUBMIT A FEATURE REQUEST?

A feature request should be submitted as a ticket. In this ticket, you should clearly describe your desired change in the software, along with a rationale for why this change is useful.

EVALUATING A FEATURE REQUEST

We ask all of these questions about new features. If the answer to any is “yes,” then the feature request will probably be rejected. But of course this is more a set of guidelines than strict rules.

1. Is the specification unclear? (We need to be able to understand what you are asking for.)
2. Is the feature duplicative? (Maybe we already have this feature and you aren’t aware of it, or maybe we know of a simpler alternative.)
3. Does the feature make the product harder to use or have a non-trivial chance to introduce bugs in existing features?

If the answer to all of those questions is “no,” then we will assess the requested feature. A developer will very quickly establish:

• What is the total development effort?
• What is the potential risk? (Which subsystems could be affected by changes in behavior?)
• What is the total documentation effort?
• How should this be tested?
• What level of product experience is required for the development?

When the assessment is completed, the feature may be scheduled and prioritized. Scheduling is a somewhat subjective process of translating an assessment. The following are the rough guidelines we use:

• Is effort and/or risk low/trivial?
  • Priority can remain low and may be scheduled for the next maintenance release
  • Is effort and/or risk moderate?
• Priority low; scheduled for next minor release
  • Is effort and/or risk high?
• Priority low; unscheduled
  • It may be assigned to a developer to work on in a separate branch at the lowest possible priority.
  • If unscheduled for a long time (subjective – how long is too long?), the request will be rejected.

We try to provide transparency to you during this process. This means that if we have classified your feature request as low-priority and unscheduled, we will try to explicitly inform you of this (and why).

REJECTING A FEATURE

We want people to request new features in our software. We believe this is a less intrusive and more accurate way of dealing with pain points than product telemetry. And it’s a good thing for us to have engaged users!

That said, we’re only human, and sometimes feature requests will be missed or forgotten. A primary goal of this formal process is to eliminate or minimize this type of “lost” ticket. Therefore, if we can’t quickly assess and schedule your feature, we will simply tell you “no” right away – to save your time as well as ours. Of course, we don’t want to be jerks about it, so we will always strive to do the following:

• Include the reason for the rejection and try to suggest a workaround or alternative
• Offer to add the feature to our backlog, but be very clear to you that it may never be implemented unless we hear from more users who want it
• Be as polite as possible about it 🙂 because we do appreciate that you are trying to help make our software better

NEED SOMETHING MORE?

This document is meant to address relatively minor individual feature requests. If you need something more significant (something that you think might take a great deal of engineering effort, for example), please use the contact form and tell us about it.

PAST FEATURE REQUESTS

We really do follow this process to create new features. For example, the Helm integration for ProGet came from a collaboration with Scott Cusson at Symbotic. And power-user Fabrice Mejean helped us created ProGet’s package consumers.