Managing features in Bootstrap

Several months ago someone asked me how we manage and develop features in Bootstrap. Overall it’s rather ad hoc, but there are some specific guidelines we follow here and there.

It’s a product

The first thing to keep in mind is that we consider Bootstrap to be a real product. It has features, a development team, releases, and users. It has a mission of sorts—to make web design and development easier for folks. When we add or remove features, we’re attempting to balance that goal with our own experiences and interests, and those of our users.

That mentality governs a lot of how we approach things with Bootstrap. We care a lot about it, we’re impacting real people’s lives, and we’re a small team having fun doing it. Feature wise, we figure out what we could do, and then figure out what we want to do and how best to do it.

In more practical terms, that means we don’t do something unless we believe we can do it well. And we say no to a lot of feature requests—focus and quality means more to us than implementing x, y, or z.

General feature requests

Tracking what to work on mostly happens on GitHub. The Bootstrap issue tracker is our primary means of managing new features and updating existing ones. Anyone can ask us to implement something brand new or to extend an existing feature with an issue or pull request. Those we agree with or would like to get to are left open to implement and assigned a milestone for when to release. Others are commented on, cross referenced, and closed.

Opening an issue or pull request doesn’t inherently mean we will do something though. We’re actually quite selfish about things. We build features we ourselves would like to see in other products and sites. There are tons of components we think make for bad experiences, shitty interactions, or are simply a pain for us to build and maintain (shoutout to datepickers).

A side effect of that has also been that there’s an immensely large community out there doing all the things we can’t or don’t want to do. That’s huge for the folks that need and want those things, and I couldn’t be happier at the impact we’ve had there.

Major releases

During the development of a major release (e.g., the forever upcoming v4), we don’t share much publicly until we’re ready for outside help and testing. This keeps us focused and involves the fewest decision makers as possible—just like any other product.

We track features we want to build and overhaul in the next major release in private. We have two private repositories on GitHub for that—twbs/team and twbs/derpstrap. Our team compiled a list of things we all wanted to see added, removed, or changed in v4 based on the trends we saw in the Bootstrap issues on GitHub. That list become our own master feature issue and have since used it to guide all our v4 work.

Major releases are a chance for us to rewrite everything. We adopted this approach really early on to keep us interested in it over time. When you can experiment, have fun, and try new ideas on a longstanding proejct, it’s obviously more encouraging to continue working on it. So we change things up every now and then. Again, that’s selfish, but much more enjoyable long term.

Development

Regular development (minor and patch releases) happens in our issues and pull requests, either from us or contributors. New features usually end up becoming pull requests before making their way into the project.

Overall our development flow looks like this:

• After we figure out what to build, we cut a branch and start adding the CSS, JS, and docs.
• Open a pull request and /cc the team and original issue opener.
• Include any relevant information, screenshots, and a current state of affairs to tell folks where you’re at in the process.
• Once tests pass and the feature is complete, we merge to master.
• We make a note in our ship list, an issue we open right after shipping the previous release to serve as a changelog.
• When an upcoming version is almost ready to ship, we create the release on GitHub and share it with the world.

Not every feature that sees a PR gets merged though. Sometimes we start to code a change and it just turns out bad. The code could suck, it could be too much code, or the feature could just not align with n number of other things. We’re not shy when it comes to turning down large pull requests—we’ve got the entire project to think about first.

Smaller contributions are also better than larger ones. Once a specific pull request passes a certain point—be it number of lines changed or sheer scope of changes—it’s neary impossible to review properly.

Honestly though, sometimes I skip a lot of those steps. In major releases, I cut a private branch or fork and just get down to it in the development branch. No branches, no pulls—just coding for days. With minor feature releases I sometimes just push right to master as well, but that’s less ideal for history’s sake and should be discouraged.

Simple and focused

In short, we keep things simple and focused. Since Bootstrap is a side gig for most of us, a lightweight and approachable development process is very useful. We love helping folks build awesome stuff by building our own awesome stuff. It involves saying no a lot, and most importantly, thinking of Bootstrap as more than just an open source project.