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:

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:

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:

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.