Get your own customer support community
 

Source control integration

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.
 
happy I’m happy
Inappropriate?
23 people like this idea

The company has this under consideration.


User_default_medium