Thanks for the feedback! I agree with the general sentiment. At the same time we want to target companies that are aware of their neurodiverse workforce.
It is a simple PHP application using Mysql as the database backend. We are using a domain driven design architecture across the application and decided to skip the slow ORMs in favor of a repository layer with hand written sql.
We are framework agnostic to not be locked into any flow but you will see classes from Symfony and Laravel. The goal has always been to make Leantime as lean as possible to allow hosting it on any shared host out there. That means we don't use any exotic extensions or OS features. You can run it safely on the smallest Godaddy instance if you wanted to.
We recently introduced htmx into the stack to offload some of the rendering back to the server and we love it.
PHP itself is really not a bottle neck anymore especially since PHP 8.0
We haven't had a chance to run a lot of large scale load tests yet so take the following with a grain of salt but a direct Task hit currently takes about 2.08 sec to load on our production site. (that includes javascript processing time as it loads in a modal)
I know we have instances with thousands of tasks and users in the wild and generally performance is not an issue we get reports on on our github repo.
We got Google Analytics and Clarity on the site. Not sure that is out of the ordinary. The site should still work with pihole though, so I'll take a look at that.
To each their own. HN users prefer light sites like HN itself so Leantime with material styles is not ideal for lightness. Pivotaltracker and Redmine are really nice with basic-looking UI.
Though I've just set up Leantime in my homelab for todo list/calendar.
I agree, there is a real challenging disconnect between messaging for PMs/Leaders vs individual contributors and it boils down to organization size. Small companies and startups tent to be a lot more democratic about their choice of tools where as large organizations tend to be more pm/leadership driven with input from ICs.
Right now we are targeting the smaller companies that don't have a lot of PM experience or resources available. The dream being the slack story of IC driven product adoption :D
Thank you for the feedback! Our table views as well as the list views allow grouping by status and will show the vertical groups as you described. Is that what you are looking for? There are a couple screenshots on the repo. (Though they show the group by milestone, status is possible the same way)
What I'm hoping for is beyond what I currently see on the repo - I want a dense view of story information. 'latchkey got what I meant in the other comments below my top comment. Definitely recommend you look at PT and see what it does. I'm not suggesting you make a carbon copy but there's a lot to learn from the PT model.
I really appreciate your feedback here and I see where you're coming from and can agree if you're looking at Jira as a purely bug tracking / development tool.
Unfortunately, and I think important to call out -- is that most companies are trying to use these tools as a "catch all" -- "a one in all solution that solves everyone's problems" and then ultimately, half of the company refuses to use the tools because it's too focused on one user group.
Our long term approach is really about making work and getting sh*t done as a relevant part of the PM process and less on time management. Time management is part of organization but people want to care about what they're building and why... something that can be absent in a lot of orgs and even in how we organize ourselves in small teams, startups or small businesses.
What I do hear and think would be interesting -- is incorporating a plugin more specific to your workflow mentioned here... because absolutely, tighter QA, etc, is vital and there are things not otherwise easily replicated as part of a dev's flow. We, otherwise, don't have any current intentions to use "bots" in a way that automates things that people should really still be overseeing.
Yeah, what they're asking for needs to be an app / integration / plugin that ties different solutions together. A kitchen sink approach will forever be mired in gigantic codebases that a single group or company can't coherently maintain [at a reasonable time or cost], and a marketplace of solutions is better able to evolve. We need more simple and specific tools that don't do much, but can be combined with other simple specific tools.
Take branching models for example. Why do we have different "branching models" that work certain ways? Firstly because somebody built a tool that works a certain way (Git) and people need to figure out how to use it. Secondly because how you use it has a direct effect on other things, so you need some coherent model for how your group will use it. And thirdly because there's a few specific ways of using the tool, so we write those down and give it a name. Nobody set out to design these branching models, they just evolved as people started using the tool in different ways.
The same should (and kinda does) happen with project management, time tracking, issue/bug/work tracking, documentation, incident response, budgeting, etc. But mostly it's within one ecosystem (Atlassian's) or another. It should really be more general, and it should be easier to integrate different solutions and build on top, and from there new standard patterns can emerge such that we don't have to be stuck into one ecosystem.
Well, if you are going in the direction of tighter QA integration, there are several interesting things that tools like JIRA are missing, and sometimes plugins try to complement, but not quite.
If we accept that bug tracker is to be a planning program, then QA usually needs a lot more than a free-form JIRA story can offer. QA really needs what they call "test plans".
Usually, to test a feature QA, beside writing tests, needs to organize it as an activity, which might be also relevant to release management, but in general may touch on other product life-cycle phases. This comes from the fact that some rare activities performed by QA are not worth automating, and sometimes are very hard to automate (eg. uploading the program to some kind of third-party store, where it needs to be approved by the store's moderators, sometimes requiring back-and-forth with developers / QA / release management). Other typical QA tasks would include producing reports, producing or studying release notes, studying feature definitions, and perhaps, scheduling meetings with people responsible for the said features.
Sometimes QA needs to run a proper scientific research, with all that entails: research planning and execution which are often also quite regimented, but would need to be built on top of tools like JIRA which don't offer any structure to the story, and the existing superstructures of stories (eg. epics or various links between issues) don't cover because they act more like arrays or trees, where what you want is structs / documents.
On the other side, project managers need a structured and formal way to deliver product requirements to R&D, from which QA will later have to produce tests. Again, free-form issues aren't enough here because the structure will have to be written down as free-form text, but will be very repetitive, unverifiable and lead to feature planning mistakes.
If a bug tracker offered a more structured approach to feature planning by formalizing the aspects of this process, this may lead to generation of program stubs as well as test stubs (the promise UML made but never really delivered).
We feel like the free cloud plan is the way to go -- by keeping our core features free, we think it's the "level up" PM features that start to bring value worth paying for.
