GitLab plans its own product in public, in the gitlab-org/gitlab project on GitLab.com, and every feature issue there carries the type::feature label. All of them were read on 4 October 2026, 77,666 issues filed from 2014 to 2026, with their state, milestone, upvotes, comment count and the labels that record who asked and how each one ended.
GitLab also marks the issues its paying customers raise. In its own description, the customer label is for issues reported by subscribers to its paid edition, and 9,463 feature issues carry it. Of those, 23.3 percent were built, 2.1 percent were declined in so many words, and 48.3 percent are still open, almost half of those for more than five years. When a customer's request was built, the median wait from filing to closing was 305 days.
iid,type,created,closed,state,moved,upvotes,downvotes,comments,milestone,labels
14976,issue,2016-01-26,,opened,0,547,0,139,Backlog,auto updated;customer;devops::verify;feature::addition
16080,issue,2016-10-04,2026-05-27,closed,0,426,0,107,19.0,customer;devops::create;priority::4;workflow::complete
519965,issue,2025-02-17,2025-04-14,closed,0,0,0,37,17.11,devops::security risk management;feature::addition;workflow::complete
Download the file, one row per issue, compressed with gzip. It is free to copy, quote and use commercially. To cite it, link https://votefirst.app/en/data/gitlab-feature-requests and give the read date, 4 October 2026. Each row starts with the issue number, so https://gitlab.com/gitlab-org/gitlab/-/issues/14976 opens the first row above.
How do you request a feature from GitLab?
GitLab's contribution guide asks for three things. Search the issue tracker first, and if the request is already there, add an emoji reaction and your notes to that issue. If it is not, open a new issue in the gitlab-org/gitlab project with the Feature Proposal, detailed template. Keep the proposal small and simple, because a sprawling one may be edited down for clarity.
The reaction that counts is the thumbs up. GitLab records it as an upvote, and sorting issues by popularity orders them by that count. People outside the project cannot add labels from the interface, and the guide explains how to ask for them instead.
How many GitLab feature requests get built?
A little over a third of all feature issues, and under a quarter of those from paying customers. An issue counts as built when it was closed with a label saying the work merged or reached production, or closed in a release milestone such as 16.5.
| Outcome | All 77,666 feature issues | The 9,463 labelled customer |
|---|---|---|
| Built | 37.8% | 23.3% |
| Declined | 1.8% | 2.1% |
| Duplicate or moved | 1.2% | 1.5% |
| Closed with no reason recorded | 23.2% | 24.8% |
| Still open | 35.9% | 48.3% |
The two columns describe different kinds of issue. Feature issues without the customer label include the work GitLab's own teams file to plan and break down features they have already decided to build, which helps explain why they are built more often, and why 75.5 percent of them have no upvotes at all. The customer column is the closer picture of a request arriving from outside.
One closed issue in four carries no label that says why it was closed. The tracker does not record whether they were built under another issue, folded into an epic or dropped.
How long does a paying customer wait?
Of the 4,572 customer requests still open, the median was filed 1,808 days before the read, almost five years. 95.8 percent are more than a year old, 72.7 percent more than three years and 49.5 percent more than five. 3,413 of them sit in the milestone called Backlog.
Age alone does not close them. Of the 5,562 customer requests filed from 2016 to 2021, 42.4 percent are still open, and of the 521 filed in 2016, 36.3 percent are.
The ones that were built took a median 305 days, and 45.7 percent took more than a year. A request for a customisable default merge request title, with 426 upvotes, was filed on 4 October 2016 and closed as complete on 27 May 2026, nine years and seven months later.
Do upvotes get a GitLab feature request built?
Only past fifty. Among the customer requests, the share built barely moves from no upvotes to forty nine, then rises.
| Upvotes | Customer requests | Built | Declined | Closed with no reason | Still open |
|---|---|---|---|---|---|
| None | 2,593 | 24.1% | 2.1% | 26.1% | 45.8% |
| 1 to 4 | 3,585 | 19.7% | 2.2% | 24.7% | 52.1% |
| 5 to 9 | 1,119 | 22.5% | 1.9% | 23.1% | 50.8% |
| 10 to 49 | 1,610 | 26.3% | 1.9% | 24.8% | 45.4% |
| 50 or more | 556 | 35.6% | 2.3% | 22.1% | 38.8% |
The rest were duplicates or moved to another project. The median customer request has two upvotes, 27.4 percent have none and 22.9 percent have ten or more. 223 have passed a hundred, and 80 of those are still open.
What does Awaiting further demand mean on GitLab?
It is a milestone GitLab created in August 2018. Its description says an issue placed there has been triaged but is not yet on the backlog, because it is waiting for more demand from customers. 2,001 issues of every kind are in it, and 855 of them are open.
1,440 of them are feature issues, and 800 of those are still open. The median open one has a single upvote and was filed 2,106 days before the read, almost six years. 634 of the 800 have fewer than five upvotes, and 250 carry the customer label. The demand the milestone waits for has, for most of them, not arrived.
How often does GitLab say no?
Rarely in words. 1,414 feature issues, 1.8 percent, carry won't do, wontfix or closed::will not do. The won't do label's own description closes a request because the team's current focus lies elsewhere, grants that it may have merit, and invites more context.
The usual alternative to a no is an open issue. 27,920 feature issues are open, 81.7 percent of them more than a year old, with a median age of 1,290 days. 15,778 are in Backlog and 9,485 have no milestone at all.
Which customer requests have the most upvotes?
| Request | Upvotes | Filed | Where it stands |
|---|---|---|---|
| A dark theme for the interface | 724 | 2016 | Closed in 2020, no reason recorded |
| Wikis at the group level | 697 | 2015 | Built, milestone 13.5 |
| Lines of code per language in repository charts | 585 | 2017 | Closed in 2023, no reason recorded |
| Merge request pipelines for forks | 565 | 2016 | Closed in 2019, no reason recorded |
| Configurable runner priority | 547 | 2016 | Open, in Backlog |
| A different default target branch for merge requests | 469 | 2017 | Built, milestone 16.5 |
| Running after_script when a pipeline times out | 440 | 2016 | Built, milestone 17.10 |
| A customisable default merge request title | 426 | 2016 | Built, milestone 19.0 |
| Exporting Markdown pages to PDF | 390 | 2015 | Closed in 2023, no reason recorded |
| A list of every issue you subscribe to | 380 | 2016 | Open, in Backlog |
Four of the ten were built, each years after it was filed. Four were closed without a label saying why, and two are open after more than ten years.
How does GitLab compare with other public trackers?
None of the large trackers read so far builds most of what is asked. Atlassian built 17.1 percent of its feature requests and has 27.7 percent open. JetBrains built 32.2 percent with 36.7 percent open. VS Code built 28.5 percent and keeps 13.9 percent open, because a bot closes any request that does not reach 20 upvotes in 60 days. GitLab has 48.3 percent of its paying customers' requests open. Public idea boards for consumer and design software build less again: Autodesk has implemented 5.4 percent of 72,744 ideas and Mozilla Connect has delivered 2.4 percent.
Votes tell a similar story elsewhere. On Bitwarden's forum, 34.2 percent of requests past fifty votes were released, close to GitLab's 35.6 percent for customer requests past fifty upvotes.
What does that mean for your own feature request board?
A request left open for years tells the person who asked nothing, and a closed request with no reason tells them little more. On VoteFirst, Denied and Completed are columns on the board by default, so every request shows where it stands. Voting is anonymous by default, and when a release includes a request, every voter who was signed in when they voted is emailed that release. VoteFirst has no GitLab integration. Release notes on GitLab itself are covered step by step.
How was this read, and when does it change?
GitLab's GraphQL API, which needs no sign in for a public project, listed every issue in gitlab-org/gitlab with the type::feature label on 4 October 2026, oldest first. Tasks, incidents and test cases, 1,208 in all, were left out, leaving 77,666 issues. Upvotes and comment counts are as of the read date.
An issue counts as built when it is closed with workflow::complete, workflow::production, workflow::verification or closed::complete, or closed in a numbered release milestone. Declined means won't do, wontfix or closed::will not do. Duplicate or moved covers the duplicate labels, closed::moved, closed::promoted and issues GitLab marks as moved. A request counts as from a customer when it carries customer or customer+, the label for large enterprise customers, which 374 of the 9,463 carry. The public file keeps only the labels about outcome, customers, stage, priority and kind of feature, and holds no titles or authors.
The next read is due by 1 January 2027.
14 days, a card at signup, then $9 or $39 a month.