Building AI coding tools, there are two common options.
The AI suggests code and you run it. Or the AI runs code on your actual machine. We decided to go with the third option: The AI gets its own computer.
Sandboxed Linux workspaces that CoChat LLMs spin up on demand.
It Write code, installs dependencies, runs tests and start servers.
We are now running an automation that gets triggered every time an error is logged in Grafana Labs, the agent then spins up the workspace to verify and fix the issue before creating a PR and Issue on GitHub. If it had already addressed the issue previously it will just track occurrences.
There is something to be said about that, I agree. For that reason you can turn off memory inside a chat thread and also create temporary ones that do not use memory.
Thank you and great question. Right now, feedback is qualitative only. (Surveys, feedback buttons, controlled user tests). We are trying to build AI evaluators but they suffer from the same problem
when trying to evaluate whether the “right” memory was pulled.
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.
This is something we thought about a lot as well; right now it's just an emoji rating. Once set the picker changes to a checked mark and is not visible to others. The data is stored in the db but not visible to others in the system.
Not just investors. I had long conversations with legal about that to better understand why it is necessary. Don't get me wrong, I don't like it either but here is the deal:
- I want this project to be a success (and open source)
- To make it a success I need to live
- To live I need to pay for food
Commercialization in OSS is pretty straight forward as there aren't many options:
- Support, managed hosting, paid plugins/features, sponsors.
With the exception of Sponsors, all of these require a number of changes to code and infrastructure that should not be public and this would not be possible without a CLA.
Ergo: CLA -> OSS Developer gets to live.
Yes, it does open the door to license changes and that is a whole other story. But what it boils down to is that funding an OSS project without a CLA is basically impossible.
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.
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
"You can even have and keep changes (unpublished) for you entire organization "
-- add to that that the organization should have access to the source code, yes.
That doesn't mean that you need to publish the code outside of your organization.
" Even if the instance isn't public, if you so much as have a contractor remotely accessing "
-- Correct, now you are distributing the software to the "public" external to your own needs.
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)
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.
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.