I wasn't aware the GitHub terms of service explicitly grant / require you to grant permission to fork [within GitHub].

GitHub ToS section License Grant to Other Users

By setting your repositories to be viewed publicly, you agree to allow others to view and "fork" your repositories (this means that others may make their own copies of Content from your repositories in repositories they control).

If you set your pages and repositories to be viewed publicly, you grant each User of GitHub a nonexclusive, worldwide license to use, display, and perform Your Content through the GitHub Service and to reproduce Your Content solely on GitHub as permitted through GitHub's functionality (for example, through forking). […] If you are uploading Content you did not create or own, you are responsible for ensuring that the Content you upload is licensed under terms that grant these permissions to other GitHub Users.

Yeah, I thought the same. Pretty bad name.

Slogan: "Code at the speed of thought"

How does it speed up my typing? /s

Are you saying "don't use a synthetic key, you ain't gonna need it"?

What makes it "anonymous"? You're uploading a file to a server, right? That's hardly anonymous.

If this is about the onion link in the repo metadata, then I think the description not making that obvious is at least misleading. There's a fundamental difference in what the repo/tool provides and what a specific hosted website provides.

I don't have multi-user library maintenance experience in particular, but

I think a library with multiple users has to have a particular consideration for them.

1. Make changes in a well-documented and obvious way
   1. Each release has a list of categorized changes (and if the lib has multiple concerns or sections, preferably sectioned by them too)
   2. Each release follows semantic versioning - break existing APIs (specifically obsoletion) only on major
   3. Preferably mark obsoletion one feature or major release before a removal release
   4. Consider timing of feature / major version releases so there's plannable time frames for users
2. For internal company use, I would consider users close and small-number enough to think about direct feedback channels of needs and concerns and upgrade support (and maybe even pushing for them [at times])

I think "keeping all users in sync" is a hard ask that will likely cause conflict and frustration (on both sides). I don't know your company or project landscape though. Just as a general, most common expectation.

So between your two alternatives, I guess it's more of point 1? I don't think it should be "rapidly develop" though. I'm more thinking doing mindful "isolated" lib development with feedback channels, somewhat predictable planning, and documented release/upgrade changes.

If you're not doing mindful thorough release management, the "saved" effort will likely land elsewhere, and may very well be much higher.

Ask your profs or other applicable personnel for offered final year projects, suggestions, and previous years projects. You can also check software dev companies which may offer such projects as job openings. That'll give you more of an overview of current common projects, and some ideas of what you could do.

of holding the hammer?

I know Julia. I used Julia. I moved away from Julia.

I'm on Nushell now for scripts, or C# for utils.

Mojo? Mojo games?

Mozilla has good introduction guides into web development https://developer.mozilla.org/en-US/docs/Learn

Is that limited to the kitty terminal? I don't see any compatibility notes on Kitty Graphics Protocol nor your TUI project - which given the TUI label I would expect to work on any terminal?

Whatever you do, don’t start down the path of […] Started messing with […] in December and it has been the bittersweet curse of a never ending things to do.

Sounds like… any and every project? 😅