As you might expect, we rely heavily on Sifter on our own process. In fact, we route virtually everything we do through Sifter. Whenever we begin a significant new feature or change to Sifter, it goes through a pretty consistent process. This process has evolved organically as we've grown, and it's slowly becoming second nature to help us ship faster and better.
We maintain multiple projects within our own Sifter account. Some of these are related to Sifter itself while others are simply areas of other ongoing work. Some of these projects are further organized by milestones or categories if their scope warrants it.
While bug and issue trackers can certainly help provide structure to your team's workflow, it still depends heavily on how individuals use that workflow. If it's too structured, and people feel boxed in, your team probably won't receive the full benefit, but if it's not structured enough, the lack of organization can be just as detrimental.
Lately, we've been receiving reports of some Sifter notifications being caught in Google's spam filters. So, if you use Gmail or Google Apps, and feel like you've been missing notifications, that's likely to be the source of the problem. This should help provide some insight as well as next steps to prevent the problem.
We've always believed that notifications are best when kept to a minimum. Send too many notifications and they start to lose their meaning. However, a side effect of that is that it was difficult to pull additional people into a conversation. With our latest update, we've corrected that problem.
Traditionally, Sifter has had a very simple policy of no markup allowed in descriptions or comments. While I always realized that it wasn't a perfect solution, I felt that it was the best solution for Sifter for a variety of reasons. Over time, my opinion on this has evolved, and Sifter will now escape markup instead of stripping it.
File uploading in Sifter has always been rather basic to say the least. Today, that changes. We've drastically improved the file uploading interaction in several important ways to make it easier and more pleasant to add files to your issues.
We want to maintain a presence on Twitter for communicating with our customers. However, as a support channel, it's atrocious. We do our best, but asking for help or answers via Twitter makes it difficult for us to help.
Tagging can work very well for personal sites like bookmarking or photos, but when you introduce it into a group setting for software that tracks issues, things can get ugly. Typos, different people using different words for the same thing, somebody forgetting to add the right tag to a specific issue. It all adds up to issues slipping through the cracks, and that's not good.
Accountability is a significant component of bug and issue tracking. From an assignment standpoint, having a single responsible party ensures that there's a clear line of responsibility in resolving an issue. However, it's just about resolving issues. We believe all team members should be directly accountable for any actions that can affect the team.
Reporting bugs and issues is all about clear communication. It's difficult to always know exactly what information will help get to the bottom of things, but there are some basic guidelines to keep in mind. Investing up front in providing high quality information will help ensure that the issue is resolved quickly and effectively.
Over the years we've heard more than a few requests for custom statuses. Sifter currently offers three fixed statuses: open, resolved, and closed. No renaming them. No adding new statuses. It's simple, but surprisingly flexible. On the surface this decision may appear crippling to some, but rest assured, that's far from the case.
Sometimes, it's easy to overlook the fact that a software project, or any project for that matter, is about more than just tracking technical information. There are inevitably many other types of data that are useful to track and discuss. In our case, Sifter was explicitly designed to be flexible enough for all of it.
In the name of simplicity, when we setup new projects, we don't automatically create categories or milestones. Not all projects or teams need them, so we didn't want to be be presumptuous. Unfortunately, that created some confusion and misunderstanding.
Over the weekend, we'll be releasing some really nice updates to Sifter that will first and foremost make it more pleasant to use, but also make way for the real notification improvements. We've also made some performance improvements over the last couple of weeks as well.
Sifter has traditionally had a very simple and inflexible system for notifications. We're working to improve this, but there are some underlying truths that can help provide context to our solutions and the reasoning behind them.
By itself, this is a pretty straightforward release, but it's another one where we're doing a lot behind the scenes to make way for some more exciting stuff. The best way to sum up this release is that we're making it much easier and more efficient to move around within Sifter.
Let's be honest. Bug tracking isn't sexy. It's a tedious but necessary part of ensuring high quality software. When you're working at the scale of companies like Apple, Microsoft, Oracle, or one of the other huge software companies, it can go to another level entirely. Regardless of the context, there's a human side of the process that is frequently taken for granted.
Priorities are tricky. They can be subtly complex or wildly simple. They can factor in severity, effort, value, or any variety of facets. They can be expressed in words, due dates, or relative values. The approaches are countless, and the advantages and disadvantages of each are just as plentiful.
Have you ever looked at something later in a project and thought "Why did we do it that way?" or "What did we do to fix that problem?" By ensuring you and your team always enter detailed resolutions, you can make it easier on yourselves down the road.
While only available to admins, one of the great features of Sifter is the ability to move issues between projects if they are mis-filed or otherwise simply need to be associated with a different project.
Anytime you setup a filter in Sifter, you can use your favorite bookmarking tool or your browser to add it to a list for later. Whether it's a keyword search, a certain sort and filter combination, or just a list of the issues you want to work on this week, it's only a bookmark away from being easily accessible in the future.
Sifter's identity is changing. Until recently, it's generally been an afterhought, but that's starting to change an evolve as we get a clearer picture of what we want to be when we grow up. Combined with the increasing number contexts within which an identity lives these days, we decided it was time to update our identity.
We've spent the last few months working on infrastructure, and, on the surface, it probably looks like we haven't done much at all with Sifter. Really, we've been investing in key parts of Sifter that are necessary but more or less invisible to customers. Rest assured, we're wrapping that up, and we're wildly excited about what's next.
Bug and issue tracking is different for every team. It depends on the size of your team, the structure of your organization, division of responsibilities, and priorities. We see lots of common myths, assumptions, and hangups in feature requests. Like anything else, even a great tool can't help if you focus on the wrong things.
Software development has come a long ways. It's no longer just the realm of programmers. We have usability experts, visual designers, interaction designers, information architects, business people, and more. With today's smaller and more integrated teams, non-technical people can't be treated as second-class citizens that aren't knowledgeable enough to join the conversation.
In the coming weeks, we will be removing support for OpenID login to Sifter. We know that this will be inconvenient for some, but after careful consideration and analysis of current usage trends for logging into Sifter, we believe it's the right long-term decision.
Saturday night we moved Sifter into its new hosting environment at Rackspace. Our goals were to improve our backups, upgrade performance, and make Sifter more modular to make it easier and safer to quickly scale the application as we grow. This means faster response times, better backups, and less downtime, scheduled or otherwise.
Sifter has fixed set of statuses that might seem to be too rigid at first glance, but upon closer inspection, there's a surprising amount of flexibility in our explicitly simple statuses. Design is as much about language as it is about visual communication. Here's the explanation of how we arrived at "Resolved" and "Closed" as the names for the latter steps of the Sifter workflow.
We receive a fair amount of requests for a way to put issues on hold. The justification is that if someone can't work on an issue for a reason outside of their control, they'd like to move it off their radar so they can focus on the things that they can control. That seems pretty scary to us.
At the end of March, we released our integration with Beanstalk. We also announced a promotion to reward the three accounts with the most Beanstalk/Sifter integration activity with free months of service on both Sifter and Beanstalk.
We've officially opened up the Beanstalk and Sifter integration to everyone. This integration has also laid the groundwork for write-access to our API, but that's a story for another time. To celebrate the launch of the integration, we're also running a joint promotion where the three accounts that use the integration the most from 4/1-4/14 will receive a free month of service on both Beanstalk and Sifter.
On Friday morning we made a mistake that led to data loss for everything created during an eight and a half hour window. Naturally, this isn't something that we take lightly, and we want to be entirely transparent about how it happened and what our response is. Note: Updated the length of the window to be more accurate.
Over the weekend, we made several upgrades to Sifter's security. The short version is that every page and account is now served over SSL and all cookies are now secure as well. The only thing about the change that won't be transparent is that everyone will be forced to login again even if you had previously opted to have Sifter remember you.
It's time for a status update. Recently, the redesign and the API have been the focus of all of our attention. There's still plenty more work to do on both, but we wanted to start marching towards the new design and getting some of the improvements out the door even if the entire design isn't ready just yet.
One of the most frustrating things about software development is receiving condescending or otherwise rude emails about your software. I suppose that It comes with the territory, but I felt like there had to be a way to minimize it.
There are a handful of "features" that we have strong philosophical objections to. We receive a not insignificant amount of questions about some of these, and I think it helps to explain our thoughts on the decisions that we've made.
Tables are great for purely numerical data. However, when records are a mix of numeric and text data where each column has varying length, significance, and relationships with the other columns, it doesn't make as much sense.
After some reliability issues with a service provider, we're temporarily disabling email replies until we can be confident that your replies will work without any problems. We wanted to explain what went wrong and what we're doing to improve.
Now that we've been using Sifter in the wild for well over a year in addition to receiving tons of feedback during that time, we've really been able to develop a clearer vision for what Sifter should look like and how it should work. As a result, we've been able to be much more thoughtful about how it all fits together.
The devil is in the details. It's a bit overused and certainly clichéd, but it summarizes a valuable truth when designing. Now that we've sorted through some of our information architecture challenges, I wanted to really look at our new designs and question the value of every pixel to edit the interface down to it's simplest necessary elements.
It's time to return to our regularly scheduled status updates. We're multitasking pretty heavily, but most importantly, we're catching up and beginning to have tangible things to share. Naturally, not all of this is exciting, but we feel it's important to share what we're up to.
It's been almost exactly a year since we shared any information about Sifter here on the blog. It's time we returned to our roots and brought everyone back in the loop. Also, I'll be full-time on Sifter from here on out.