Adding explicit states for acceptance and verification sounds great at first, but in the overall context of issue tracking, they can actually muddy the waters and be counter-productive.
Adding explicit states for acceptance and verification sounds great at first, but in the overall context of issue tracking, they can actually muddy the waters and be counter-productive.
Accountability is one of the most important facets of issue tracking. Unfortunately, it's not always immediately clear who should be responsible so Sifter is designed to embrace the chaos and help minimize it.
When creating software, the value of setting aside time purely for testing and focusing entirely on locating and recording issues can drastically increase the number and quality of issues discovered.
Have you ever had a discussion about a feature or some business logic in an application, arrived a decision, and moved on only to look back a month later and ask why you made that choice?
Bug and issue tracking is just one small component of increasing the quality of your software. We’re going to take a look at the key tools and strategies available to improve the quality of your software and help you ship faster at the same time.
The most powerful and important habit for issue tracking is that of leaving detailed and informative comments. Just like with commit messages, skipping comments, or failing to write detailed comments is a terrible habit that we all need to break.
Kicking off projects and getting your clients to use a new tool isn’t easy under any circumstances, but with the right approach, you can get them on board and contributing in no time.
Prioritization is hard. There isn’t a single black and white formula for comparing and ordering everything that needs to get done. And as soon as you have everything prioritized, something changes. We’re going to analyze and simplify priority by breaking down the factors that influence it so we can see how simple prioritization can help minimize thrashing and make sure everyone still knows what’s most important.
We recently added GitHub integration to Sifter. So now you can quickly and easily update issues from commit messages in either GitHub or Beanstalk. Not only is the integration quick and easy to use, but it's also quick and easy to set up.
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.
You can now follow and unfollow issues with a single click. On the surface, this is a tiny change, but behind the scenes, we're paving the way for some huge improvements to Sifter's notifications.
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.
We call Sifter an “issue tracker” instead of a “bug tracker” for two reasons. The first is that even the most technical project always needs to track more than simple “bugs” or plain technical information. And the second is that any good issue tracking tool is, at its core, a fancy team to-do list—and bug tracking itself is only the tip of the iceberg.
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.
After our identity refresh we decided it was time we had something to hand out to people that we meet and are interested in Sifter. After more than 4 years, we finally made some cards for Sifter.
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 a handful of statuses that an issue can be set to. The list of possible statuses might seem a bit lean at first, but we intentionally chose to go with a limited number of options. This post talks in particular about the “Resolved” and “Closed” statuses, which are the second-to-last and last statuses for a typical issue.
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.
We've been slowly dipping our toes into email integration with Sifter. We recently took our next step by accepting issues via email and enabling people to change some attributes via email.
We've redesigned and rebuilt the Sifter public site to help customers, setup a better home for the API documentation, and get a dedicated Sifter blog up and running.
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.
After some time, we've rolled out the initial foundation for our API. It's read-only for now, but there's more on the way.
In the current version of Sifter, the status bar does a great job of communicating and reminding you of the status, but it overwhelms the other significant attributes.
We recently made the switch from our previous email provider to Postmark, and we couldn't be happier with the results. However, we have had to make some minor adjustments.
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.
When I set out to start this little software company, I swore to myself that Sifter was a marathon, not a sprint. While I've done a pretty good job at staying true to that oath, I'd be lying if I said that it was easy. Balancing time between customer-facing features and back-end refactoring and upgrades is difficult.
We're big believers in evolutionary design rather than revolutionary design. With milestones, this became especially true. I briefly shared our thinking behind designing and building milestones into Sifter, and this is a follow up to show how our thinking and the interface have evolved.
We made some significant hosting improvements, but during the transition we also had some unexpected downtime.
Just a quick note about how sometimes the most difficult part of building software is deciding when it's ready. If you're not careful, you can easily tweak and improve something indefinitely.
Sixteen months after leaving a comfortable full-time job to try and make a living off of a hosted web application, I'll be going full-time on Sifter. I put together a visualization showing how Sifter has grown over time and marked the significant milestones in our history.
Receiving feedback is a time-consuming process. Unfortunately, even the most eloquent and brilliant feature requests aren't guaranteed to make it into an application. Every developer or team has to choose their battles, and while customer requests carry weight, they aren't the only factors. We've put together a list of the four factors we use to decide if a feature makes it into production.
If there's anything about Sifter that I have a love-hate relationship with, it's managing feature requests. On one hand, feature requests and customer feedback are the most valuable ways of understanding where we should steer the ship, and the people that take the time to share are priceless. On the other hand, some people request features with the entitlement of spoiled children who have never heard the word "no" in their lives.
We've got a lot of things going on, and while there haven't been any major updates since the visual refresh and OpenID, the next few months should be big.
One of the most common questions and points of confusion about Sifter is comparing it to a help desk. While there is some overlap between help desks and bug tracking, they have some very important differences.
A post to help people who are completely new to search as well as providing a behind the scenes look to some who already have a deep understanding. As a result, parts of this will be very basic, some parts will be fairly technical, and other parts will even talk about some of the interface decisions.
This morning we rolled out search and cross-project issue filtering. There's not much more to it than that, but I wanted to give a quick overview of the highlights from the release.
For those of you who use Fluid to create site specific browsers for your web apps, we've finally created a high quality icon for you to use with Sifter. When we set out to create the original icon, we intentionally wanted the style to be something that would work well as a dock icon for a Fluid app, but somewhere along thew ay we forgot to think about the overall shape.
As we approach the end of our first full week of Sifter being live, I wanted to share how things are going and where Sifter is heading. Overall, everything is going great. The feedback has been overwhelmingly positive, and with the exception of a few small hiccups, the launch went very smoothly.
A detailed post explaining a somewhat invisible feature to illustrate the amount of complexity that can be involved in making something "just work".
I'm thrilled that we won't be having a status update this month because the status is simple. Sifter is live and now accepting customers.
Sifter now offers file uploading. We would have loved to have this in there from day one, but we're big believers in iteration. While this is the last major feature release planned before launch, it's just the tip of the iceberg for where we ultimately hope to take Sifter. For now though, here are the details for file uploading.
Another month. Another update. Unfortunately, I didn't get to spend near as much time on Sifter during October as I would have liked. However, we've still made some significant progress.
It's been almost 10 full months since leaving the day job to build a web application. As we start to sneak up on our launch date, I wanted to share some of the lessons learned over the course of bringing Sifter to life.
It doesn't matter how good of an interface designer we are, there's nothing more valuable than feedback from real people other than yourself using your application. The sooner that happens, the better off you'll be.
I know it's been quiet here on the blog, but that's a good thing. Sifter is beginning to really pick up steam as we're marching towards the beta and launch. I'm spending my days (and nights) heads down fixing bugs and putting on the finishing touches. We're effectively feature complete, and it's all downhill from here.
May was a fairly quiet month publicly with lots of behind-the-scenes progress, a little traveling, and lots of learning.
It's been a while since sharing about how I planned on creating links between issues, and things have progressed quite nicely. Recently, though, I got the idea to add a strikethrough when the target issue has already been closed. I later found out that Trac already does this.
When we initially launched NextUpdate.com, I alluded to the name having many possible interpretations, but after the recent post about launching, I started thinking about it again and thought it was worth expanding upon.
Things are chugging along, and April is almost behind us. It's been another solid month of progress, and May is setup to be our biggest month yet.
One of the most difficult aspects of creating a new product is deciding which features are necessary for launch. Leaving out features can make you uncomfortable. However, there's a point where you should be more scared of adding features than leaving them out.
After coming up with a new name and spending some quality time trading ideas with the wonderful Jared Christensen, we've made another big step towards launching the issue tracker. Everybody. Meet Sifter.
While we still don't have much outwardly visible progress, things are really starting to pick up steam on the issue tracker, and April looks like it will be one of the most exciting months yet.
We held a public chat about the issue tracker yesterday, and the results were fantastic. We've put together this quick list of questions that were hot topics during the chat.
We wanted to provide a little bit of insight into our philosophy and thinking behind services that try to lock you in. The short version is that we think it's lame.
A wise man once told me everything takes longer than it does. He was right. One month after striking out to build the issue tracker as a full-time business we've made significant progress, but we have very little to show for it. Yet.
We haven't made a lot of outwardly visible progress, but there's a whole lot going on behind the scenes. We're starting to pick up steam, and things are looking really good.
Having a clear vision and purpose for your application might seem like just a nice-to-have, but in reality, it's that vision and purpose that determines decisions at every crossroad. Any lack of clarity and strength of purpose will show through in the resulting application.
If there's anything I've learned about designing web applications in recent years, it's the fact that things change over the course of a project. Learning to embrace that fact and direct it towards a productive evolutionary process has made a significant impact on my work.
One of my favorite topics is the influence of business decisions on interface design. It's an unfortunate truth that the underlying business structure and decisions will invariably affect the interface. It's important to recognize this fact and work to improve both simultaneously.
One of the key requirements for creating any kind of issue tracker is making it easy to get data into the system. While the browser is the primary interface, I felt email also had to be a first class citizen for issue submission.
It's not uncommon to spend so much time on the big picture that we overlook the details. While I'm far from a typographical expert, my growing interest in typography has really helped draw my attention into more subtle details that add up to make a difference.
We've taken a look at the concepts behind the issue life-cycle and workflow, and next we're going to see how the dashboard is playing out so far. For me, the dashboard is about quickly assessing the state of projects, and diving right in to managing them.
I've seen countless elaborate ways to link related or duplicate issues. While most of them get the job done, it's generally way more confusing than it needs to be. I considered a lot of different solutions, but in the end, there was one that stood out.
For my issue tracker, I've wanted a more natural process for updating issues. I decided that all activity would have to go through the comment form associated with each issue. This way any change in status, priority, category, or assignee could quickly and easily be associated with a comment.
Last time, I went into my vision of a simpler bug and issue tracking life-cycle. This time, I want to focus on one of the manifestations of a simpler process—the status bar.
It's been quiet around here, but things are about to pick back up. I've been spending all of my free time designing and developing an issue tracker that I'll be releasing as open source early next year. Until then, I'll be exposing and sharing the design and development process.