trobonox
Heads-up: Running a large-ish extension here
Hey, thanks for the great offline-only Kanban board, especially one that is for once not Electron based and not using a database.
I'm currently migrating off of another one that has the properties mentioned above and is abandoned but has a nice feature set. I'm doing said extensions using strongly guided LLM usage. So far I have
- a working comment feature and
- an attachment feature as well as
- a testing suite & harness of varying quality, but probably good enough to review and extend.
- a working JS-based CLI based on the current single-JSON file data structure.
I will probably extend the UI more to achieve feature-parity with the tool that I'm migrating off of, at least where I was using a feature of said other board. I might rip out and replace the single-file json based data storage with some less monolithic but still file based one.
Currently I'm trying to get those changes as branch based and isolated as possible to enable review, however some features have dependencies upon each other making it not perfectly possible to always provide isolated branches from origin/master.
I'll try to upstream those as soon as a satisfying state is achieved and then we can see if/how those can be integrated.
Hi! Thanks for showing interest in contributing your changes.
At the moment, there's a big internal rewrite going on regarding the handling of board data (moving away from huge .vue files to a more structured approach with a pinia store + composable). This means that your features might require significant changes too, so keep that in mind.
Moreover, at the moment I only see the attachment feature as something potentially interesting to be upstreamed. I'm a little hesitant about the rest since I'm generally careful with adding big chunks of LLM-generated code into the codebase. At the moment, I pretty much know all the ins and outs of the codebase which makes fixing bugs a matter of minutes. I've noticed that with previous AI-assisted contributions this level of deep code knowledge has significantly decreased. In the end, it's just me doing the heavy lifting, so anything that makes maintenance more difficult is something I'm quite critical about.
That's my thoughts on this matter. It's great that you were able to extend the app to fit your own needs and I encourage anyone to do so (since it's the spirit of Open Source), but please keep in mind it might not match with the project's vision and also make maintenance more difficult for me. I hope this doesn't come off as too harsh, I just want to let you know my expectations openly so you don't waste time with upstreaming features that might never get merged.
Thanks for the reaction, it's all good & fine! I've tried to have the LLM make decent, well described commits that might make the review easier. The code knowledge issue is effectively something that arises with every larger contribution be it LLM or human created. Given my FOSS experience one gets used to it over time.
I'll see what I can put up, take from it what you like, and reject what makes no sense for you.
On your internal rewrite: Can you put up a summary of the rationale of it, a higher-level description of what happens during it and the goals to be achieved as well as possibly some links to the documentation of the features / tech used? I'll then feed that to the LLM and ask it to tendentially align with that in what it builds...here as a GitHub comment would fully suffice.
Usually giving the LLM some proper bullet points and ask it to find & fill in the docs&blanks and then review the result often works reasonable well for that too...or just make it the bullet points.