And it's written in bash.
Which honestly makes it impressive, especially given that the whole project is only 354 LOC.
That's impressive. Last time I needed to write more than 50 LOC in bash I wished I had been told it was alright if I used Python instead. bash is not hard or anything, but it can feel painful since it's different to everything else I'm used to.
> I doubt a whole team would agree to use this tool though.
Definitively, but it could work if was just one of the possible frontends and create another, for example, web based frontend.
That naturally adds quite a bit of complexity as you either need a central server app that holds the source of truth or handle merging otherwise, be it by let the user take care (e.g., holding it as somewhat merge friendly text records in git) or do come up with some automatic conflict resolution.
IMO that shows why developing and using such CLI tools is somewhat popular; it's really simple to do but often then only works for a single person or a team with a very similar mindset in the usage/tooling regard.
It is possible to use calDAV, cardDAV etc to sync tasks, contacts and calenders independent of the client you use. I have been doing this exercise the past few days with one guy who does everything in the CLI (mutt, todoman etc) while I have been using Thunderbird. It kinda works, but you have to forgo some features that are not supported by booth clients to make it work.
It's rather basic feature set; no sub-task support for example. But I do not know of any other way to sync tasks and calenders across a team where preferences for different clients and tools vary.
This would be the ideal solution for collaboration. A shared *DAV server as a datastore where everyone can bring their own client.
Unfortunately this breaks down rather quickly as the various calDAV and cardDAV implementations vary wildly for features outside of simple task lists. About a year ago I tried configuring sync between Linux/Windows/MacOS/Android and failed. I documented my search here .
This comment reminded me of this sentiment I'd like to echo here. Central server of some open or semi-open standard where "everyone can bring their own client" is not realistic for most solutions, because most people just don't give a shit. It's great for nerds like us, but not so much... anyone else.
> Is there any need to have a back pressure system for a single user?
I don't think the fundamentals of the system change because of a single user. Life is logistics. If I have a lot of stuff in the HOLD state, it might indicate that my life is super busy, and give me some areas where I should perhaps set up automation for those tasks, or see if I can make behavioral changes to avoid those.
For example, there's a city trip plan in the author's screenshot. Assume there were 5 or 6 more. If you find yourself planning trips to a bunch of cities but never actually taking them (I have personally been in this situation a few times), then perhaps the Kanban board can reveal that bottleneck.
Some people use the word "agile" as a noun, supposedly taking inspiration from the "manifesto for agile software development". -- In this sense, 'kanban board' just means "todo list arranged in columns".
A description of kanban (as applied to software development) that I did like was what it wanted to emphasise:
1. Maximize flow. - If work flows, there's more assurance that work will get done.
2. Minimize work in progress. Either a worker is working on something, or they're idle. Either a task is being worked on, or it's not making progress.
3. Visualise work in progress. - If many tasks aren't seeing progress, then visualising the work in progress is a way to show the bottlenecks in a process, which might restrict flow. (e.g. do reviews take too long, or are blocked on some key person; some key stakeholder needed for some review or some deployment, etc.).
I think if no constraints are put on picking up work in progress, then a kanban board is just a todo list with columns.
It’s a bit like a linear Petri net.
Ignore all the jargon and analysis and just consider: is a todo list possibly more effective when divided up into states of completion/activity?
I’ve been doing it this way for a good 15 years now (albeit just with a markdown/notepad file) and it’s been ridiculously effective. Especially in school.
>Or has language shifted and kanban is now just the term for a specific variant of todo list?
For most people I see it as the language has shifted to be a fancy todo list variant, designed more for team communication, by middle management.
"A goal of the kanban system is to limit the buildup of excess inventory at any point in production"  I would also add that its goal is to switch all work from push to pull, which is a concept both odd to understand and hard to totally achieve.
Take the concept of a Kanban card(meaning signal card) . It is great in the physical world of production but not as easy to understand in the digital world of mental work. This physical card can be used to control a simple task such as ordering inventory, as well as a large task of producing a complicated piece of machinery.
Take the simple inventory idea and think of your pantry. You have two bags (two bin system) of coffee beans and you place a kanban card behind the first bag. Once you finish using the first bag you will see the card and set it in the pile of other cards (pulled) because this pile becomes your grocery list. Then when you go to the store you don't have to go through your pantry looking for what all you need to get(pushing), you know because its on the cards, past you did the work, and you still have enough from the second bag will which will last until you go to the store. You end up reducing your unused inventory with everything set to a low par(1 extra bag), and by not purchasing an extra bag because you forgot to look and cannot remember if you need it or not so you get it just in case. Now your pantry is too small and you plan your pantry expansion project because you NEED more storage space.
So when this idea got converted from physical to digital the goal of the board is really to reduce work in process and switch from push (developers writing useless features, writers writing the wrong docs, artists working on art for a canceled project, etc) to pull (planned releases, features based on customer requests, bug fixing over new features, etc).
> 1. Does software have logistics?
Absolutely, there is a limited supply of mental capacity in people. Their productive capacity is consumed via meetings, working on the wrong tasks, spreading their work over too many tasks, email, breaking flow via people asking useless questions such as what is the status of X, etc.
> 2. Is there any need to have a back pressure system for a single user?
How else do you know exactly what to do? What item do you get from the grocery store? If you have no way of the customer telling you what to work on? What to fix? What to build? At the end of the day we are building for the customer and need to build what they want most.
But back to the board itself I think it boils down to most people having to much WIP causing this board to be a fancy todo list that is organized but ultimately overwhelming and just as useless. But again at least it is organized.
Something like this "git-issue" would be perfect if it were supported either built-in to git, or if a service like github/gitlab supported it through a web interface. Sadly, the latter will never happen, because it's in direct conflict with the added value proposed by those services.
But, if it's not built-in to git, then you're going to have to convince everyone who might work on or contribute somehow to your project to buy in enough to your alternative system that they will be willing to install this extension, and also to ignore the github/gitlab issues interface. You can enforce it of course, but it's a difficult sell, similar to convincing people to use some alternative source control system just for your project.
Too bad, because I really like the idea of tracking issues in the same repository. For one thing it would make commit comments like, "fixes issue #36" a lot more internally consistent. (Those kind of comments are what lose their value immediately if you move from e.g. github to another system, unless you find some way to port the issues too.)
Yeah I really wish there was something built in for project tracking. I know it's kind of pretty huge scope push but it's something that basically every project needs- or could at least use- and having it siloed into other tooling is hard to sell.
Even just Git-the-project defining a spec would go a long way, people could use their own local tools and eventually Github would have to implement the bridge or suffer the egg as other tools built better integrations. Of course it's all too fraught with landmines and will never happen, for better and for worse.
Github could even end up making git-issues-msvc-edition and we'd get to relive the 90s.
I wonder, are there proprietary VCS's that embed issues, etc?