5

I've had some experiencing working on open-source software with many active users, our policy for the issue tracker was not to allow end-users to create feature-requests.

While this wasn't a popular choice among many users we did this because the scope of the application was already wide and we found it difficult to find the time to respond to regular bug reports.

Instead, there are solutions such as user-voice (and similar services), which we experimented with (and kept our issue tracker for software errors, or design-tasks assigned to design teams and developers).

This worked well for us, because every issue had a clear outcome:

  • Maintainers of an area are responsible for resolving.
  • Issues have a clear outcome.

Since then I've been spending some time on a project on github which is also and end-user application in the field of graphics/sound/animation (not middle-ware or server code), and many users are making random wouldn't-it-be-nice feature requests.

This would likely be the case for other productivity software (applications people use for their job, spend all day in and may be greatly impacted by available features - office/image/video-editor/animation/CAD/code-IDE's).

Since I'm not the owner of this project, I don't feel like setting policy on this topic.

And while there is some potential value in any given feature request, my impression is...

  • Users ask for fancy features from their favorite application.
  • Very few of the requests are likely to be implemented within the next few years.
  • Developers aren't engaging with users and the requests are mostly ignored.

Basically user expectations and developer capabilities differ so much, that many requests are wishful thinking, and only loosing someones time to have to categorize, reply to, de-duplicate... etc.

But maybe I'm reading the situation incorrectly here:

So my question is, for popular end user software with many more users than developers, what is a reasonable policy for defining what is/isn't acceptable to keep open as an issue on github/gitlab and similar services.

Do many projects on github for example disallow feature requests in their issue tracker?

(would be interested in answers from anyone who's been involved with large active projects who've had to make a decision on how to handle feature requests)

Improve this question
2
  • A good example to consider could be Font Awesome. It's now possible to sort by the most reactions (i.e., +1's), so that you can see which requests are most desired. But you do need to have people watching to clean up duplicate requests. Unfortunately there will always be some people who won't search.
    – curiousdannii
    Aug 27, 2016 at 12:52
  • @Glenn Randers-Pehrson, I'd consider these utilities/middle-ware, not to diminish their importance (I use these from time to time). But people don't spend all day in these tools for their work- as they might for full-featured applications - office/image/video-editor/animation/CAD/code-IDE's... for example.
    – ideasman42
    Aug 28, 2016 at 1:38

3 Answers 3

Reset to default
2

We allow anyone to open an issue and make feature requests. We try very hard to respond to actual issues quickly, but obviously can't always fix everything.

Bugs are bugs, but feature requests are the killer. We get a ton of really interesting feature requests. Unfortunately, most of them are either barely related to what our project does, or simply too difficult to implement in limited spare time.

That means that the core team has to play the benevolent dictator. Any one of the core team members have the right to deny a feature request, without question. One of us will simply make a polite reply that, "While this is a great idea, it's just not in the realm of what our software does."

I suppose our policy could be summed up as:

We trust the other members of the core team to approve or deny feature requests at will. Approval of a feature does not imply that it is a priority to implement, merely that we would like to implement it eventually.

Improve this answer
4
  • 1
    Could you cite the example project in your answer? Is it this one github.com/rubberduck-vba/Rubberduck/issues?
    – Zimm i48
    Sep 7, 2016 at 10:06
  • I'd rather not cite the specific project @Zimmi48. I try not to spam links to it all over. What does it matter which project it is anyway?
    – RubberDuck
    Sep 7, 2016 at 11:01
  • A reference to your own work is not spam if it makes the answer better by illustrating it with an example. Plus, you say "we" : it is not clear how many of you there are. And how big the project you talk about is.
    – Zimm i48
    Sep 7, 2016 at 11:36
  • 1
    @Zimmi48 for reference, core team is 3-4 developers (although I've not contributed code for about a year now, I still try to monitor the issue tracker). Another 10 or so occasional contributors. We have several thousand users. So, it's a successful, but not huge, project.
    – RubberDuck
    Sep 7, 2016 at 11:38
0

Firefox/Mozilla is an example. It has hundreds and hundreds of developers and hundreds of millions of users. There is no disallowing of feature requests through their issue tracker (bugzilla). In fact, one of the bug categories is "enhancement".

I didn't have a role in deciding how to handle feature requests in firefox, though.

Smaller projects with thousands to millions of users, but only a few (one or two, not more than five) active developers that I'm involved with include pngcrush, libpng, ImageMagick, and GraphicsMagick. None of those open-source projects forbid (or even discourage) requests for features. On the other hand, we don't always act on them right away; some have languished for a decade.

Improve this answer
0

The answer to this question is "it depends" ... on:

  • the scope of the project.
  • the ratio users to developers.
  • where the project fits in the software stack.

As a general rule of thumb:

  • The issue tracker is to help with the development of the project,
    if developers don't have time to respond to requests and users are ignored, then allowing the requests to begin with is just adding noise to the issue tracker and false-hope for users that their suggestions will considered.
  • When issues in a tracker are getting ignored this isn't good practice and may be off-putting to users and prospective developers.

The chances that feature requests can be handled on a single purpose command-line program (for example) is much higher compared to (for eg) a game-engine which has a huge potential scope (platform support, 3D-rendering-backends, ai, scripting languages, shaders, physics, networking, streaming data, image/mesh/audio formats... etc).

There is also some difference between an end-user application (where users are likely to request features from the application they're migrating from), compared to middle-ware - which is likely to only be used by developers who are aware of the scope of the library.

So this is up to each project to decide if they can effectively handle requests in their issue tracker or not.

There are some policy options besides all or nothing:

Enhancements may be acceptable:

  • only if a developer accepts the task and plans to work on it.
  • only if their is a bounty to develop the improvement.
  • for a fixed time-period, then closed if no action is taken.
  • on a separate site, where users can collaborate before proposing well planned tasks to developers.

This prevents the issue tracker overflowing with unhandled topics.

See further discussion on this topic for the OpenToonz project.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.