New Feature Request Process

Among the most significant advantages of working on a popular open codebase is the constant feedback stream in all forms, including GitHub issues and pull requests. Over the past 6 months, our team did a lot of work triaging over 4.5k issues across our 3 main repositories and merging hundreds of pull requests. Going through this process, we responded to long-standing tickets and solidified our understanding of the most frequent requests by the community.

It’s fantastic receiving such rich feedback, but at the same time, processing thousands of requests could be cumbersome. It could slow us down in responding in the discussion threads and could often distract us from developers’ top needs.

Many times we’ve talked about different processes for automation. A significant concern for most of them was the risk of losing valuable comments without being able to address them or incorporate them in our future vision for Angular.

Analyzing the issues in our three main repositories, we found that a large portion of them are feature requests:

Although tempting, it’s unrealistic and unhealthy to incorporate all the requests for features. If Angular takes this path, there are risks for the framework becoming unlearnable and unmaintainable. But clearly such feedback is precious — there are hundreds of bright ideas coming from the community that align well with Angular’s future vision and are worth exploring.

Automating feature request

At GitHub Universe, the VSCode team gave a fantastic talk on “How we make VS Code in the open.” Alex and Benjamin shared how their team automated the feature request process by including the community.

In the next couple of weeks, in the Angular project, we will introduce a similar approach to managing existing and incoming requests for features.

When we receive a ticket, an Angular team member will review it manually and categorize it as a feature request or an issue.

As the next step, we’ll verify whether feature requests align with any existing projects on the roadmap. If they do, we’ll prioritize them. If not, they will go through a 60-day voting process.

During this period, anyone could vote for the corresponding feature by giving it a thumbs-up reaction (👍). If at the end of the 60 days the request has collected a certain number of votes, our GitHub bot will automatically label it for consideration. Otherwise, it’ll close it. Following the process set by the VS Code team we’ll consider requests with 20 or more votes and iterate if a different number of votes will give better results.

If a request has a label for consideration, we’ll manually review it again and verify if it aligns with Angular’s future vision. If it does, we’ll move it to our prioritization queue. Alternatively, we’re going to close it with an explanation. We want to keep Angular coherent. Closing a feature request often means it’s a better fit for an external module which the community could distribute as an extension of the platform.

Historically, we’ve always been hesitant to close feature requests, even in cases when we don’t think we would realistically move forward with the feature. By actively closing more feature requests, we set better expectations and make it clear that we’re trying to focus on the work that impacts the largest number of developers.

You can preview the process in a higher level of details by looking at the activity diagram below:

Open source at scale

We value all the incoming feedback and for us it’s a top priority to be responsive and mindful of anyone’s requests.

To continue scaling sustainably, we’re looking forward to kicking this process off the ground to make us more efficient and fair in the feature request management process!