Taiga: A free and open-source project management tool
taiga.io
taiga.io
- The "Save" icon is tiny and hard to find in some layouts (right hand gutter, near the top and far away from your linear text entry flow). It's a floppy disk! Navigating away does not warn you that you have unsaved edits.
- Issues can be converted to Stories after review. Great. But there is no indication that the Issue has been converted, and reporters can continue to edit Issues, and the changes are not synced to the new Story item. This was very confusing for some people, and created way more friction than could be reasoned away.
- Information density was OK with a small quantity of items/comments/etc, but too sparse for a confident view with large quantities.
We moved this project over to test GitHub Projects, which is an improvement but also lacking in some important (different) areas.
...
All of these tools have always sucked on some or several dimensions. It's probably impossible to not suck.
JIRA can be made to work, though I will never do so again.
Pivotal Tracker is solid but overwhelming for reporters/casual users, and requires custom code to integrate with GitHub (but API is decent).
Sometimes I miss Trac and Redmine, if only because anything that bothered me enough could be fixed in our self-hosted instance.
But I think the real issue is that UX is more work than most developers expect, and especially to iterate over time.
UX mistakes (or imperfections) are visible for all to see, and correctness is sometimes subjective. Imagine if all of our users were able, qualified, and effectively required to evaluate source code! We do some lazy/misguided/opinionated stuff too, sometimes! :)
I didn't mean to dis Taiga above. It's thoroughly functional, if not quite right for the users I was testing with. I tried Taiga because I know the other options mostly suck, and my next-step-test is not definitively better!
I'm not sure, I still see this dismissiveness. Hell, open any HN thread about design and see how many will ask what designers even do all day, or talk about them as if they're "less than" developers.
I can proudly say that our team not only cares about design, but has put Design and User Experience at the center of the product development. We are designing an improved interface, with special accessible approach, and also having special care about the way space is used (information density like you said). Likewise, we know this is a critical point in terms of a project management tool.
I'm really looking forward to sharing more advances! For now, we are sharing some of them on Taiga community (https://community.taiga.io/), please feel free to post your thoughts, ideas, and feedback.
I'm a strong proponent of open source and highly usable tools for critical project infrastructure.
I really wanted Taiga to work for us, and I look forward to revisiting it in the new version.
https://www.youtube.com/watch?v=CU3BD-2ejE4
I guess it's time to do it again.
Thanks for the cool free software!
Your argument might be true, but angular would be an exception as it's is pretty backward compatible and even provides you with automated upgrade scripts (ng upgrade)
I never worked with Angular 1.x., but try running `npm install` on an Angular 9 project and watch the deprecation and security warnings scroll by.
I'm in the process of upgrading a complex mono-repo from Angular 9 to 15. The biggest issues are not Angular itself, but all of the other tooling built around it.
Are you sure you used the upgrade scripts or did you just yolo style increase the angular version in the package.json to latest?
The project I'm upgrading is a library used by other downstream projects. My goal was to release a working version of the library for each Angular release. However, I could never resolve this particular issue and just had to skip that version of Angular.
Another common problem I ran into - dependencies that support, for example, ng11 and ng14 but not ng12 or ng13. So your options are to skip that version of Angular, try to replace or remove the dependency, or beg the author to add support for a version of Angular that is years out of date.
And material components version 15 has a breaking change around custom themes that means either I cannot upgrade to that version, or I have to completely rewrite the entire theming functionality within my project. So yes, I can run ng update @angular/material@15 and migrate the code easily, but that doesn't mean "it just works".
To be clear, I'm not complaining about Angular, or anything else in particular here. In my case, the decisions of the original authors caused upgrading to be more difficult than it needed to be. My point is, without knowing the details of any particular project, it's easy to see how upgrading across several major versions can quickly turn into a nightmare of rewrites.
The problem are security bug fixes, which usually are only backported to supported versions, regardless of when they were introduced.
E.g. version 1.5 introduced a vulnerability, but it’s not found until after the release of 3.1. At this time only 3.1 and 2.5 are supported. If you’re using 1.5 you need to upgrade. Most probably at the least convenient time possible.
You probably know this already. I still wanted to address it, because at one time in my life I was young and naive and thought similar to you. There might be people out there who can learn from that.
I'd say the bigger problem is having a stack that a very limited amount of people want to work on. This is true for a company where you want to hire specific people to work on your outdated stack (hard and expensive), but even more for an open source project where you need contributors willing to work on an old stack in their free time.
My comment was more in the direction of "the project is done, deployed, and will not change anymore". Somehow software seem to be subject to weathering over time. And what seemed like a secure piece of software can become insecure over night, when someone is fuzzing it and publishes a PoC.
Please tell me in which scenario a frontend issue is a security issue because I'm more the backend architect, not a naive developer.
Your server can remain perfectly secure and uncompromised while your front end drags your company or project's reputation through the mud.
There's a recent update showing off new (upcoming) flows via mouse/keyboard/screen reader that emphasize their work on accessibility. I've never tried something like gitlab/github in a screen reader - so don't know how that would compare.
https://community.taiga.io/t/taiganext-update-livestream-acc...
There's also the "next" announcement and a follow-up:
https://community.taiga.io/t/announcing-taiganext-and-much-m...
https://community.taiga.io/t/important-update-on-taiganext-a...
Ed: I'm guessing this is "next" - I see the other front-end repo has a taiga 6.5.x tag in main branch:
At some point, we need to stop focusing on the next shiny thing. The web ran for decades without frameworks, then it ran well with jQuery, and now many websites use outdated frameworks. But who cares if you're not the developer working on the codebase? If the age of the framework doesn't break regular navigation and native browser behaviors there's no reason to switch to a new framework unless you are working on a big increment.
One feature in particular I learned a lot from was their permission system, which I had never built before. It helped me reason about how to build permissions into an api.
There is a self hosting option. But the recommended option is self hosted but managed by Taiga.
So to me it seems that this is more freemium.
Also, there seems to be version 7 just around the corner.
Technology used seem to include python, coffee script, postgres, django, redis among others
Is that including if you self-host?
As for "freemium": as others pointed out, I'd also put it that as long as you can self-host full-fledged instance it's "free".
Having possibility to use their "cloud" instance without charge with sole limitation of maximum 15 users is "more than free" from my point of view: they are basically paying your costs for running that. Sure, it might be negligible for them in scale, but still, as long as it saves you time and hosting costs (install and maintenance), it is a value *you* receive for free.
Haven't personally used Taiga, so can anyone comment on their impressions, maybe also compared to something like Redmine or Jira? What's good? What's annoying? What's missing?
Once experienced people joined the team we switched to jira.
What was the benefit and the positive outcome from doing so, outside of familiarity with Jira?
Conversely, what was problematic about the idea of sticking with Taiga or another solution, what would you miss out on?
I think that every software has some shortcomings, like some people swear by Jira, others hate it, personally I can see both sides: it works, but at the same time the REST API has stuff like createmeta which you need to use for getting issue field types programmatically, except that there were breakages in the REST library between versions 8 and 9 of Jira as no data is returned even when you run those two versions with same config in parallel, though that's only applicable to their self-hostable solution which is different from their cloud solution, without getting into the licensing changes in the following years.
I'm interested what you think about exact features or qualities that each has and how they compare.
Many Startups start with lot of other nicely designed, new, and good Sales CRM. Once they grow enough and becomes big (and successful), they all go to Salesforce. So, why not just start with it. I'm not against the other tools, they are good and they do their job. I personally love Hubspot for its UX amongst others.
For Project Management, it becomes extremely difficult to convince people to move and change to another provider once people began to settle in. This is extremely hard in larger companies. I have used Jira when it was pretty bad. Recently, I checked it and it has improved a lot. It is free for unto 10-people. If your company grows, you will need to upgrade. You should always ask, "How much am I paying when I'm paying?"
This is rather personal but I would start with the idea in mind that you will one day grow to 100+ people. And thus, which one will you use and work backwards and see if it has a cheap/free version to start with. So, why not start with something like Jira, or Basecamp (single pricing for n-users), etc. etc.
Why?
Last time I tried Taiga, it was pretty limiting. Everyone else have used Jira somehow, and I remember I could make Jira sing with its SQL-ish script.
https://github.com/dotproject/dotProject
It is certainly legacy... Yet the small footprint works well for standalone ticket resolution databases, task assignment, and budget tracking. Practically speaking, one needs to consider how many staff will be on the interface at a time.
A support database to cover user issue resolutions is part of product development. Having something you know will persist for a decade gets trickier.
When I first tested Taiga, I put my own personal schedule into it. With epics for things like Christmas, tasks for chores, going out for coffee with my mom, etc. It works amazingly well, so well that I still use this test project and prefer it to my regular schedule.
Do you just mean that you've used it in a profession setting, or do you mean something else?
It was also stable, we encountered no bugs and the solution did not get in our way in terms of user interface. It strikes a very good balance between features and simplicity.
No other software does this for very good reasons. What were they thinking?!
Also, it works for me...
> Why is 1 small UI mistake is enough to put you off an entire product?
Because removing the page-up/down functionality requires extra work. If the developer is performing extra work in order to make the UI worse, then their UI decisions in general are likely to be equally crap.
In this particular case, however, it works ...
100% this
Can someone PLEASE explain to me why front-end devs go out of their way to DISABLE features?
Scrolling works fine. Having multiple ways to scroll is user-friendly and adds accessibility. Someone please explain to me why a dev is going to go "You know, I don't use Page Down/Page Up to scroll, so I'm going to spend time hooking into the Page Down/Page Up key presses so they can be thrown out and disable scrolling through those keys".
EDIT: Page Up/Down work fine for me on that page btw. Using Chrome on a MacBook Pro.
> Why is 1 small UI mistake is enough to put you off an entire product?
Because that tool is accessed via a web browser, same as the landing page.Because marketing don't always make the tool on sale.