Recently active topics in Next Update

Other than email integration, Markdown is the other thing I'd need to buy Sifter.

I capture screenshots using Skitch, and upload them to another server - I just want an easy way to display that uploaded image, rather than uploading images using the web interface.

Thanks!

After winnowing down the ticket list, we get a header that says something like "25 matching issues." It would be great if it said something like "25 issues assigned to you in the 'Bravo' milestone." I understand I can look in the sidebar and "figure it out" based on the checkboxes, but a more-helpful title like this would make it easier.

Will there be an API?

In email notifications, pretty much without fail, I click the

> Turn off these notifications at http://vzaar.sifterapp.com/profile/

Instead of the

> View the full issue... http://xxxxx.sifterapp.com/issue/yyy

I'd imagine most users don't change their email notifications that often, whilst most users click to view the ticket online very often.

I think the targeting is wrong here. I'd find it far easier if the "turn this off" was at the very bottom of the email with several lines above it pushing it a little bit down.

I haven't even entered a ticket yet, but one idea occurs to me: Support access to the Basecamp API and the ability to selectively migrate an issue into a Basecamp To Do. I envision maintaining a separation between project tracking and bug tracking between the two apps, but sometimes the end-user doesn't know what's a big vs. something that should be tackled as part of the project.

I would absolutely love to see a Mylyn extension for Sifter. It would be a tremendous help.

Can we email issues into the system and receive notifications? Will we be able to reply to issue updates via email?

First, let me say that what you have going here is awesome. You've obviously spent a lot of time thinking things through. The flow of the app is great. The main thing missing for me is source control integration (svn, git, github).

I have used two ticket systems thus far--trac and lighthouse. Trac is dog ugly but I like the syntax they use better. Basically on any commit, you can put Fixes #123 where 123 is the ticket number that needs to be closed. You can also say Refs #123 and it will not close the ticket but instead just reference the commit in a comment on the ticket. The last thing that is handy about trac is you can specify multiple tickets to fix and ref like so: Fixes #123, #132 and #156. If you fix a few small bugs in one commit you can close all the related tickets at once. The multiple ticket support is not essential but it is handy.

Lighthouse has an aesthetically pleasing UI but I find parts of it very confusing functionally. That said, it is my current choice as there isn't anything better for what I need. They have a bit different syntax for updating tickets from a commit. As far as I can tell they do not support updating multiple tickets at once either (if they do I couldn't figure it out). To close a ticket, you simple add something like [#123 state:resolved] to the commit and lighthouse will do the rest. Syntax like this is powerful because it also allows adding tags and such but I find that I rarely use that power. I just want a simple way to close a ticket or reference it from my commit message.

SCM integration for me is all about referencing a ticket and closing a ticket from commits. I don't need to be able to see all the commits in Sifter as Lighthouse does. Simply making the commit message a comment and updating the state of the ticket is plenty.

So that covers syntax but not necessarily how to integrate it with sifter. You definitely don't want to start doing subversion and git commands to pull in updates for all the projects. I would just implement an API for sifter and allow developers to build the tools that use the post commit hooks that subversion and github already have, to post to the API (trust me they will).

Ideally, as a user, I could create multiple API keys for a project (and name each key). You could then use a unique key for each app that needs to integrate with a Sifter project. Then, if you stop using an app, you can kill access for that app by simply inactivating that key in Sifter. If the other app tried to do anything after you inactivated the key, they would just be denied.

Obviously you could go crazy with API features for this but I would start simple. For the first iteration of the API, I would implement a way to get all tickets, tickets filtered by one or more states and an individual ticket. The only other API call that would be essential in the first iteration is the ability to add a comment to a ticket that would function identically to the web interface. An API with only these calls would be enough to do some serious integration with source control systems and github.

Hope this helps.

Can you please set focus to the username textbox on the login page?

I'm looking for a bug tracker for some open source or otherwise "open" projects. Can I use Sifter for them?

I've seen milestones mentioned in a couple of threads. I like Sifter, but for my employer, not having milestones is probably a showstopper; we need the ability to group issues into the iterations in which they're being worked on. We could probably co-opt categories for this purpose in the short run, but it will be tough selling Sifter over here if milestones are not coming soon.

As for the implementation: I imagine that an additional field that functions much like category but has an associated date would suffice.

Nice product, thanks for your ear.