Those of you who have potentially (open source) pet projects that nobody else cares about (at least yet), who do you get to bounce off you with design decisions?

Got a feature of #ScrumMD I'm designing and needed the kind of argument I get at work to refine it. Because it's all public, ChatGPT did a passable job checking consistency with the rest of my apparent design philosophy.

Feels like there should be a better option though.

#ScrumMD, the CLI tool for managing tickets, work or cards (and yeah, originally designed for #Scrum) as #markdown files, that absolutely nobody but me wanted (and even fewer people asked for) has been updated to v0.2.

Big feature is `swrite` allows you to modify cards without loading in an editor. Also - `scard` now has customizable Jinja 2 templates for output.

Get it for Python >=3.11 with `pip install scrummd`.

Doco (including examples) on https://scrummd.readthedocs.io/en/latest/

#obsidian #python

Sometimes, it's tough to tell if your code is elegant (and pure!), or if you've made things hard and complicated looking for the sake of it.

It's my project. It's staying, for now, and I'll no doubt get a chance to argue about it next time I run a session on neat maintainable code.

Look - I know that I could probably do this more tidily with a for loop. If I keep adding functions, I'll probably opt for something different.

(from https://github.com/lkingsford/scrummd/commit/a2e5318966ed0c0999b458c300e32a63589b73bf#diff-4479f9c6d1444d5645b885d39f15e1c0e201179ab65a520a3cb193761882588fR40-R117 )

#Python #ScrumMD

#scrum What if developers self-organised?
#jira What if leadership wanted to organise them instead?
#scrummd What if we stopped them again?

So anyway - it's a year later, and there's development happening on #ScrumMD again.

Once I've added editing fields, probably a basic command to add a new card with the next index in order (because that's currently manual) and maybe a file-date based filter to be available, it'll probably live on v0.2 for another year.

I ate my dog food with it, and stored my plans in it. Wouldn't recommend this workflow - but I actually have the cards for #ScrumMD _in_ the repo. There's nice bits about it - I can move a card to Done in the same commit as completing it, but it's probably not feasible for bigger teams.

The problem is, the more I used this joke, the more I actually liked using it.

#ScrumMD started as a joke - basically '#Agile was supposed to be developer lead, but #Jira has ruined it by inviting leadership in. What would it look like to have a tool that I'd want to use as a developer?' I knew that nobody else probably would want something like this - and that a '#scrum' tool that requires a cli/text editor to use, as well as having the cards be local files (so, you'd need to manage distribution yourself) wasn't going to be endorsed by any company.

So - why am I looking at #ScrumMD again?

Frankly - because I'm actually using it. In my new role, I'm losing track of the amount of work and things I need to track coming in from lots of directions.

Like in most big orgs that use Jira - our boards are associated with projects, managers, teams, cost centres; just making a board to track my own work wasn't feasible. Turns out I'd already written a great tool for doing it.

Sometimes, when coding your own thing, you do little things to make yourself happy even if it isn't _strictly in scope_ of the feature you're building.

I'm adding writing fields to #ScrumMD. I needed to rewrite the output code to make that work - which meant I'm moving (eventually) all output to Jinja2 templates rather.

And, to make me happy: I added ANSI color when using interactively to the new default template.

#Python #Programming

So, I wanted #ScrumMD to have a write function (so I could change fields of cards without a text editor). Which, after getting the physical order/casing on the fields, I thought 'well, that just seems like a special format of outputting the card with scard'. Well, I'll probably want a template for that.
Well, I could use Jinja.
Hey - I could use that for sboard as well.
Anyway, guess I'm rewriting all of the output code, and some of the config, for ScrumMD.

#python #scopecreep

The #terminal is the tool of the software engineer. Not as clumsy or random as an electron app.
An elegant tool of a more... civilized age.

(pssst: haaaaave... you checked out #ScrumMD yet? https://www.youtube.com/watch?v=xn7ZRUzN_Tc)

I made a video introducing #scrummd, my #cli #gpl #scrum tool that lets you manage scrum with markdown files, if you're in the tiny niche of folk into that.
https://youtu.be/xn7ZRUzN_Tc
(Sorry - YouTube. I'll repost with the PeerTube link when it's approved)

#python

New #scrummd feature.

Turned out to be less work than I thought.

You can now go [[!card_index]] to refer to a card_index to display (for instance, with scard) but not add it to the collections made by the card.

So - you can have your dependency collection, but refer to other cards in it, and still go something like

sbl card1.dependencies

without seeing the ! marked cards

I think at some point, I need to start sharing around the thing I made. So - I think I made the v0.1 milestone for #ScrumMD

Short version - I made some new very unopinionated command line tools to help you manage (nominally #Scrum ) cards stored locally in #markdown files

Doco on https://scrummd.readthedocs.io/
Source on https://github.com/lkingsford/scrummd
Install with `pip install scrummd`

#python #agile

Almost there with #scrummd to be willing to say 'ready for other people'!

Look at that nice visual #scrum board in the console. Can customize to group by anything.

I don't even know if it's really practical as a daily driver. It's been great for dogfooding #scrummd - I'm using a folder of cards in the repo itself and scrummd to manage it to keep track of what's left to add.

But - as an exploration of one way that developer-centric #agile could work, I'm really enjoying using it already.

That'll do for now.

(6/6)

A team can manage those cards however the hell they want; they can share them with git, shared folders or dropbox. They can import #scrummd to make scripts to play with it in Python; there's no server or API that you need to interface with. It's just there locally. You can work in the #scrum process without leaving the terminal, which might be good for flow state.

I've even thought about the ceremonies - you can stand up with vim `sbl sprint1 -b` if you want vim through the cards

(4/x)

The main tools show collections of cards and individual cards. They manage relationships between the cards and can enforce rules that you set.

But #scrummd doesn't come with any rules beyond making sure every card has a 'summary' field and that it has an index (which it defines by default from the filename)

You can collect them how you wish - it recognises folders, you can manually tag. You can require fields or limit their values, if you wish. It's up to a self-organising team.

(2/x)

So #ScrumMD - what is it?

Fundamentally, a tool nobody _really_ wants. It seemed like an awful idea. And the more I thought about it - the more I wanted it.

It's really the exploration of an idea: "What would it look like to tell Jira to sod off, and manage the #scrum or #agile process with markdown files and a command line?".

(1/x)

#ScrumMD is getting close to the point I'm willing to start telling people about it properly.

The code to do the arbitrary levels of group by with arbitrary levels (and directions) of sorting is more complicated then I would prefer (https://github.com/lkingsford/scrummd/blob/main/scrummd/collection.py#L228) - and I'm not 100% pleased with the interface if it was being used as a library.

But - tagged v0.0.10 yesterday. Can already install with `pip install scrummd` if you're using #python 3.11 or higher!