First of all, we’d love to send a warm thank you to all of you. Your feedback on how to improve hourly rates in mite was super-helpful to us. We never ever could have expected such an amazing support—merci!
In the meantime, we decided on which scenarios to implement, we finalized the concept and wrote the first chunk of code. In the future, you’ll not only be able to specify one hourly rate per service, but also:
- one hourly rate per customer
- one hourly rate per project
- customizable service hourly rates per customer
- customizable service hourly rates per project
You’ll be able to combine those options as you see fit. Hourly rates will be handed down in most cases: e.g. if you define one hourly rate for a customer, this hourly rate will be the default for all projects for this customer. This way, you won’t have to specify hourly rates over and over again.
We decided not to implement hourly rates per user. One, only ~9% voted for those scenarios, two, this layer doesn’t integrate unambiguously with the principle to hand down hourly rates from one layer to the next.
Our most important goal is not to overburden mite with complexity. If you don’t make use of hourly rates at all or if you only use the current solution, the new features shouldn’t stand in your way or distract you even a little bit. The sophisticated options will be there—but only when you really need them.
We do not want to rush this feature but rather take the time we need to design a smooth and smart solution. Please have a little patience with us. We’ll update with drum rolls!
At the moment, you can specify one hourly rate for each service in mite. The service is the only factor that determines the revenue of a time entry. Customer, project, and user don’t matter here. This approach to hourly rates is simple and easy to use—which is a huge pro in our opinion. But, it does not seem to work good enough for many users.
So please tell us: What do hourly rates depend on, in your case? We’d love to improve mite to better meet your workflow.
In my case,
Please leave a comment if none of these scenarios work for you, or if you’d like to describe your requirements in detail. Thanks for your input!
Update, May 26: The poll is closed now, 766 users voted. Thanks so much for your awesome input, simply great! We’ll dive into conception right away.
[Update, 2nd August] Survey closed. Thanks for your input! The results are: Trac, Mantis and Redmine.
My name is Thomas Klein and I’m currently studying Computer Science & Media at the BHT Berlin (Beuth Hochschule für Technik Berlin). For my final exam, lasting for three months, I’m dealing with the connection of open source issue tracking systems and mite via plugins.
The term »issue tracking system« has many synonyms and covers therefore a wide variety of software. In my perception, an issue tracking system should at least support the processes
- Create a ticket and assign it to a person
- Edit the ticket and give feedback
- Mark the ticket as solved
Due to the limited time I will focus only on web-based open source issue tracking systems, having each:
- a good documentation
- an API
- a repository of plugins for my reference
- a programming language not to difficult to learn for me in the limited time
Now it’s up to you: Take part on this survey with only 3 questions to affect my implementation ranking of the remaining issue tracking systems. Additionally you can provide some feature requests for the mite.plugins. Based on the results and your recommendations I will implement a mite.plugin for the first 2-3 issue tracking systems.
If you have any questions or comments regarding my thesis or the survey feel free to contact me on Twitter or email me at .