My #1 request is a priority drop-down. A simple “low normal high” would do.

Ratings for complexity: “Trivial”, “Simple”, or “Complex” would be a nice-to-have.

An option to select “Bug” or “Enhancement” would be nice too, but tags work ok for that.

I realize some of these things are a little specific to our company, but Priority seems like a pretty universal requirement. So much so that if we ever find Lighthouse+Priority, switching would be a no-brainer. Not a threat, Lighthouse is great. :) Just that Priority means that much to our routine that tags fall pretty flat in comparison.

Also, ordering the ticket-list by Priority, or breaking up the list into High, Normal, and Low priority tables that preserve the existing order (last modified) would be a natural change if Priority were added.

On the subject or a default ordering for tickets though: The current order seems less than ideal to me. I want to see my oldest/least-active tickets first, not last, or they’ll never get the attention they deserve.

The way I see it, low priority tickets are rarely assigned to a milestone, and high priority ones are taken care of on the spot.

I’ll probably be adding some ordering to the ticket search. Maybe even grouping, I haven’t decided yet.

So that’s a “No” on the Priority right?

Yup… for now anyway. We’ll see how it goes I guess. There are a couple threads on this already.

That’s a real shame – I’m cancelling my account and signing up to goplan because of the lack of this feature. I realise you don’t like it, but the tags just doesn’t work well for me and my team – old habits I guess

I get that if a milestone is Alpha then those items need to be done before milestone Beta. However, within Alpha I have lots of tasks, and my developers need to know which ones they need to do first so that the UI and design changes and the backend changes are in synch. As it works now we spend so much time on IM going over which ones we are doing that it’s a waste of time. I get the impression that you’ve built lighthouse for your workflow, and you’ve decided that’s the best way and that everyone should work in this manner. It really doesn’t work for me, which is a real shame as I loved everything else about ti and wanted to use it so badly.

I’d like to add to the voices asking for priorities. They don’t have to be there all the time, but sometimes you need to be able to give people an effective ordering for things that need to be built out or fixed. Although I love the Lighthouse interface, I’m facing a mutiny over this, and we may go back to using a hosted Trac :(

+1 for priority. For me to convince my company to fully switch to Lighthouse, we use it for the Mack Framework right now, we need to have priorities. We have show stoppers, blockers. major, minor, trivial, etc… Tags just are working for us.

Hmm, I can’t believe I didn’t realize it until now (after having signed up with an account for my team), but there’s no priority rating for a Ticket? I realize that tags can be used to specify priority, but, clever as this may seem, it’s insufficient. I need to be able sort tickets by priority and visually get a feeling for the workload.

Trac does a beautiful job of this:

http://trac.edgewall.org/report/1

I was really looking forward to using Lighthouse, and now I’m not sure I even want to continue without a priority rating for tickets. It’d probably be better to use another product than get the team started with Lighthouse and find later that we want to switch because of missing priorities.

you can have public bins setup for specific priority tags though…I’m not really sure how that is any different. You can view all tickets in a project, or divide with bins according to tags/milestones. Or you can separate via milestones/goals and then setup a bin for ‘milestone:next sort:priority’ based upon your milestone sort order. One is project wide while the other is specific upon the milestone/user.

Thanks, Will, I will examine using bins.

The distinction between a priority tag and a priority dropdown (like ticket status) may seem very trivial, but I can guarantee you, people will forget to specify a priority tag, people will misspell priority tags, and people will get plain sick of typing in priorities in the tags instead of selecting something from a dropdown.

For the typical code ninja/hacker or open source dev, this priority setting vs. priority tag would be no big deal. Especially for small teams.

But if you guys want to expand your market share to the majority of development professionals (i.e. the other 90% for which development is simply a 9-5 gig), making things stupidly simple is the way to go.

Just some unsolicited advice from my humble experience. :)

We do appreciate the input and take every request into consideration when we discuss upcoming goals for Lighthouse.

Typically, at least what we’ve gathered from users workflow that has developed and grown with Lighthouse users, a ticket is either important or it’s not. Levels of priority in trac feel rather more a label for when or how you want to handle your tickets need of importance. We honestly haven’t had much gripe with how Lighthouse allows you to handle this. It’s a bit more straight forward I would imagine, it’s kind of an either or based upon it’s importance, or sorted via milestone as to when it needs to be completed.