Garrett Dimon's dashboard

We need to get our own API working first. :)

Long-term, though, it's much more likely that we would add a help desk piece to Sifter so that it's all one product and seamlessly integrated. We see public projects and help desk functionality as being a very reasonable and likely extension for Sifter.

That doesn't preclude Tender integration at some point, but it's likely that we'd focus on building or own or extending Sifter before integrating with another tool.

This is fixed now. Let me know if there's anything else that we can help with.

I'll take a look at that and get it fixed here shortly.

We don't have a date or even a specific timeline. All we can really tell you at this point is that it will be out when it's out. – Garrett Dimon, on October 29, 2009 14:48

We're all over it. The API is the gating factor, and that's where we're focusing 110% of our development time right now. – Garrett Dimon, on October 29, 2009 13:06

I completely understand, and nobody would love to have an API out tomorrow more than me. I assure you that I'm 100% focused on the API at this point and giving it every ounce of time that I have.

Hopefully it will have been worth the wait when it arrives. – Garrett Dimon, on October 25, 2009 07:16

We're working on it, but it's not going to be here in a matter of weeks. In general, I would advise anyone who is unhappy with any product not to use it. Naturally, we hate to see people go, but I'd sincerely rather that people be happy, even if it means that Sifter isn't the right product for them.

The last few months have been incredibly busy for me personally, and the reality is that Sifter can't support me full-time. It's getting closer, but it's not there yet. So sometimes, the bills have to be paid.

We've been working on making some important changes to make sure that the we can spend a more consistent amount of time on Sifter. Unfortunately, it's a significant transition, and it takes time. It's not as if we said we were working on the API and then released dozens of other features instead. We simply haven't had the development hours to spend on it. That's changing, but it takes time.

We are investing all of our development time on the API. In order to do it well, and have a clean RESTful implementation, we're also going to make some other changes to the interface to help simplify and tie everything together neatly. That also takes time.

We could rush something out the door, but we wouldn't be happy with it, and neither would anyone else. I'm sincerely sorry that our rate of development is fast enough for your expectations. We're not very happy with how long it's taken either, but we want to do this the way that we feel is right.

We're working on it. If you need it immediately, then I'm sorry, but we're going to disappoint you. I assure you that we're trying to make the best long-term decisions for the application and for our customers. We believe that focusing on speed of delivery is a mistake, and we're not ever going to do that.

We're working on it, but we're not making any promises about dates. It will be the next big release. – Garrett Dimon, on October 24, 2009 03:28

This is still a decision that we're perfectly happy with right now. We have some ideas on how to do this well, but they won't be easy.

Adding preferences might be a quick fix, but we feel very strongly that it's not the best solution. It's certainly not a good long-term solution as it would force us to make compromises and have to support it in the future.

I'm sorry if you're disappointed, but this simply isn't something that is a high priority for Sifter, right now. – Garrett Dimon, on October 23, 2009 16:03

The next major release will be for the API. However, we're also regularly doing smaller releases as we lay the groundwork for some other features and prepare for the API release. However, that's primarily changes behind the scenes, the occasional bug fix, etc.

Sorry for the slow response, this somehow slipped through the cracks. I completely understand your concerns, and the simple answer is that we're actively working to address all of them. That said, if you're not comfortable using or recommending it, just check back in from time to time.

With regards to "travelling through bugs" and not being able to return, it should automatically be returning you to the page you originated from in the same state that you left it. There's also a "Return" link on the right side of the issue detail page for every issue that adjusts and always returns you to where you originated from.

Regarding the view settings not sticking, they're not designed to at this point. While we want to address this long-term, the best way to handle that is with a simple bookmark in your browser. All of the state information is stored in the address bar, and bookmarks should work seamlessly.

The overview/activity/issues links issue is one that we're already designing an update for. The problem is that Sifter has grown and adapted organically, and with those changes, it's been difficult to create a structure and navigation that ties it all together. This is something that we're working on, and I'm pretty happy with progress we're making behind the scenes.

The issue about turning issue references in parentheses to links is one that we can and should address. However, in the short-term, since it will create the link with spaces, it shouldn't be a big loss to not use parentheses.

The API is going slowly, but it is going. In the last 6 months we've been way too concerned about rushing features out the door, and we're starting to get back to designing and creating at a pace that we're comfortable with. It will take some time.

And yes, we are a small business without any full-time employees at this point. I completely understand and can't say that I blame you for not wanting to recommend it. That said, we're profitable and continuing to reinvest our profits in improving Sifter. Growth has slowed a bit, but we are still growing and completely invested in making Sifter a great product.

Thanks for the feedback, and don't count us out.

Thanks for the suggestion. This definitely something that we're looking to address in the future with updates to the issue listing page.

Unfortunately, it's been very difficult to provide additional power and flexibility without complicating the filter process to the point where it's overwhelming. We're still actively exploring ideas about how to do it well.

Unfortunately, you can only add categories one project at a time. We've thought about providing a way to setup default categories, but we honestly haven't had any requests for it. And yes, the categories are unlimited, but I'd suggest paring it back as much as possible. Too many categories can make the drop downs and other interface elements cluttered and overwhelming.