re: How we use "ship small" to rapidly build new features at GitHub VIEW POST

re: Great article! What about improvements to existing features? Do you also use feature flags the same way? And regarding Pull requests, if you work...

What about improvements to existing features? Do you also use feature flags the same way?

Yes, we often do. It really depends on the risk and is a judgement call for the team.

A recent example, we added this "filter bar" to the Actions tab.

We feature flagged this one because it can generate complex queries and the risk is it could cause performance problems when used against huge data sets. We also wanted to be able to flag in specific people and have them test the functionality before rolling out to everyone.

Can you talk a bit about how is your code review process is organized so that the amount of PRs waiting for review doesn't become a bottleneck?

Yup! A tip I learned from @andreasklinger a few years ago. When you work on a remote team you need everyone to dedicate time to doing code reviews. Unblocking each other is a priority, so most people will dedicate time in the AM (or whenever works for them) each day and they'll go through all the PRs and review them.

I find that when starting these projects, usually the first few PRs are a little more high effort to review because we're setting the foundation for the feature. But after that, things are small incremental improvements to the base. Since people are familiar with the area of code, they get pretty quick to review.

We rarely see anything go unreviewed for more than 24 hours. It helps that we are all on the same project and are motivated to get it done. If someone started a PR, but is now outside of their working ours, we'll often have someone else push commits to it to finish it up and ship it. Seeing multiple peoples commits on a single PR is pretty common.

One more thought on being "unblocking". We almost never block a PR unless we see something in the code that would cause a huge problem. We'll approve it, and leave "non-blocking notes" for things to improve. Then it's up to the submitter to take that feedback and apply it if they want. This reduces the amount of back and forth (critically important when in different timezones).


Thanks for the response. Perfectly clear ;)

Just one more question about feature flags.

How do you manage the cleanup process of older feature flags that are no longer needed, for example after the feature is generally available in production?

We're not great at that :). We often leave them in code for a couple months. Then we file issues to remove them and people will pick those up when they're looking for a quick/easy task to do.

Code of Conduct Report abuse