kawa-kitsuragi / whichtool Goto Github PK

There's 26 files right now in /src/. That's a lot.

At minimum, surfacing main.twee - perhaps renaming it to __main.twee or something - will help make it not get lost in the noise.

Subfolders seem like a smart move, but how should those be organized? I could base it on the Intro passage - basically /discord/, /website/, /api/, /other/, though whether or not that website side also gets further broken down depends on #21 .

What I should check before doing anything -

• will Git complain about reorganizing, and how badly?
• does Twee check subfolders, or will I have to do more build.yaml shenanigans?

So the WobSites passage - the one you click when you ask for a website, as opposed to a Discord bot or an API - is really long. There's 24 links on it as of right now, split into 3 categories, 8/11/5.

On the one hand, creating more things to click feels bad. On the other hand, this could quickly get as unwieldy as the actual Projects Airtable, which this is explicitly trying to avoid.

I should get a gutcheck with folks who use whichtool on how they feel about it.

because I was terribly, wonderfully spoiled by doing so the last time I was writing piles of Twee, even though there's much fewer macros here.

it's new porble

This is mostly to stow away sources:

SIBR Project Airtable
Full data flowchart
Dargo's 'content creator' Carrd

Not really sure how to describe https://before.sibr.dev but it should probably be in here.

Maybe "Blaseball.com as it looked in the past" under "Current and historical data"?

This is weird technical nonsense about how variables are handled.

The general hope is to have only one, simple place in a passage where the $discussion_channel for a tool lives (and for bots the $automata_channel, though with the streamlining of bot channels that may be less necessary, no matter how you get there, and have the boilerplate always work to get you in the right place.

Look into PassageDone, custom tagging, and possibly this FAQ.

The general idea: instead of the <<include>> and all the clunkiness of the dozen places to put setters:

• add the PassageDone tag to the boilerplate passages
• wrap passage text in a <<if tags().includes("TagNameHere")>> block
• reset the $discussion_channel to the default at the end of the passage
• each passage gets tags they need, and <<set>> is invoked at the very end

This might required a rewrite of the bot boilerplate, but that's going to be true given the channel reorg anyway

• do the move
• change the link to the repo that lives in whichtool itself
• check if any pinned messages mention the repo link, swap those
• check that the whichtool redirect still works
• check that the embed_clark still works
• personal bonus: use this as an excuse to change up my personal wobsite

After a push, the "custom domain" setting resets and I have to readd it manually. Doable, but annoying. Probably a Github Pages thing.

I'll focus on the branch leading to datablase stuff.

On "What are you searching for?"

• I'd be more specific than "the firehose" - maybe "the firehose of data" or something

On "Welcome to the firehose"

• I'm again a little unsure if the playful tone is too confusing...
• "Direct from the tap" might benefit from the implication that this is TGB data
• I like the other two and the "by the way I'm using Python"

I guess I'll maybe put together a PR for what some of the further pages would have?

Might take some weird Twee hacking, but could be nice to have something that pops up on Discord and/or Twitter.

I have never tried to extend Tweego beyond "turn this individual .twee file into this single .html", but I think it's possible.

The main advantage here would be that I could get it to the point that individual tool makers could 'own' their bit of the flow and add to it/change it when needed, without feeling like they're disrupting anyone else's work or the overall flowchart. I also just generally like the idea of it being more modular and less brittle than a single source file...

There is a chance this might break Pages integration, which would be a shame. If it doesn't, it absolutely would make the build.yml file much more complex because it's a less simple command to Tweego.

links to

• wiki
• one line per season: https://faculty.sibr.dev/~kawa/one_line_blaseball.html
• anchor

Right now, I'm writing "out of character" - as if I, Kawa, am asking you questions in SIBR's help desk.

I could see a version with a layer of Data Witches kayfabe, to be more in line with things like onomancer. Not sure how I'd do it, not sure if I'd want to - it's intriguing, but I primarily want this tool to be helpful.

(Then of course there is my girlfriend's insistence on making it into a dial-in helpline, complete with text-to-speech character by character readouts of URLs, but uh. That's something else.)

i won't do this in earnest until off season but it seems like chronicler is back, and/or that api2.sibr on the 20 min delay (that might already be depreciated at time of this writing)

There's really no reason why this shouldn't be a thing that's user-toggleable, but not sure how to have that work within Twine itself. Hm.

• get listing of what's available (in off season)
• update userstyles.twee
• don't forget the new role

I want to make it so that whenever you access the WhereToDiscuss include it always matches the project to the category, but there seems to be some funkiness. Hm.

• how to use the 'WhereToDiscuss' passage
• maybe a template passage for others to use?

Low priority. But cool.

once we start having data in the new Era, some tools will work for gamma and others will be, over time, confirmed to be sunset as their developers decide not to pursue updating them and/or other tools supplant them.

noting that as we go is an ongoing thing.

It thinks things are part of... lists???? This is probably CSS being CSS but Kawa needs a siesta to figure that out.

I probably need to muck around in the build.yml a bit.

Documentation.

Guessing specifically on: push: paths-ignore: and put the readme in there, and decide if anything else should be included.