Increase contributions to the project

[peso]

Since this project has some original and valuable ideas, I feel it deserves more attention than it currently gets. The original author is not completely gone, but has many other tasks with higher priority, so the PR process is rather sluggish.

I would like to propose moving the project towards a more independent status, where a group of contributors collaborate on maintaining and evolving the code base.

A start could be to write a CONTRIBUTING guideline, on how to add small corrections and what it takes to get commit and review permissions. More info here: https://docs.github.com/en/communities/setting-up-your-project-for-healthy-contributions/setting-guidelines-for-repository-contributors

This document has some more thoughts on governance: https://opensource.guide/leadership-and-governance/

This might also have relevance: https://ben.balter.com/2017/11/10/twelve-tips-for-growing-communities-around-your-open-source-project/

[mlange-42]

@peso Can we have a personal communication on this? You find me on Discord under the same user name, without the minus.

[peso]

Thank you for the discussion on discord. We agree that a separate github organization to handle git-graph (the library) and its spin-off projects git-graph (cli tool) and git-igitt (tui application) would be a good idea. Also splitting git-graph into two repositories will make issue tracking more clear.

I would like to ask the community for suggestions names for these for entities. Please comment below.

[alerque]

I would also like to be considered for involvement in helping with this if it is going to be split off into an org (I think that's a great idea). I have extensive background in contributing to and managing FOSS projects, both personal and in orgs. I hold a lot of trusted keys and can prove I'm not a particular risk to the supply chain. Would you like me to elaborate?

[peso]

That sounds good. Which parts would you like to contribute to?

[alerque]

Issue triage, PR review, helping split the library from the CLI, CI and release stuff, whatever is needed... I could for example fix the report I made on git-igitt earlier today before landing there and setup CI to verify it at or prior to releases.

After a discussion is had and names agreed on for the library vs. CLI I can probably help with filtering a repo or otherwise shaping it so so the library component and CLI repositories history (whichever way the split happens) that is relevant to the issues.

Subject to time constrains of course, but I can jump in on a lot of different things as needed.

[peso]

In that case, I think you should start by scratching your itch: A CI setup for git-igitt would raise the quality and is a good opportunity for fixing the build problem you mentioned. I guess you should also discuss the process for a release with @mlange-42.

Welcome onboard.

[alerque]

First itch scratched here and here.

[peso]

Name suggestion

git-graph (this cli) repository was started in 2021, but git-graph (vs code extension) can be found on the wayback machine before 2020. Therefore this repo should probably change name.

Suggesting a line theme:

• Project: git-lines
• git-graph lib: line-graph
• git-graph cli: line-map
• git-igitt tui: line-browser

This is one suggestion of names. Please feel free to add more. We can use the React-icon to vote up or down on suggestions.

[mlange-42]

I would suggest that both the CLI and TUI names should start with git-, as this allows to run them as git commands. So currently, with git-graph on the PATH, one can also use:

git graph

Further, if the CLI tool gets a rename, I would suggest to rename/move this repo, but let it stay the CLI tool. This is probably the most used part of the family, and it deserves to keep its GH stars.

[peso]

Here is another one, this time with a rail theme. As rails is pretty much taken by ruby, the German word "bahn" is used instead:

• Project: gitbahn
• git-graph lib: bahnlib
• git-graph cli: bahnmap
• git-igitt tui: bahnhof

[mlange-42]

Now that you are coming up with "German" names, just as a side note, git-igitt (which actually stands for Interactive GIT Terminal) also plays on the German language, spelling similar to "igitt!" or "igitt-igitt!", which means something like "Yuck!" or "Ugh!" for disgust.

[alerque]

I agree on the git- prefix for the tools, but neither "bahn" (I work both with cartography where railroad graphs are actual maps, and language lexers where railroads graphs to me are these things) nor lines really trigger any great vibes for me. Obviously both are apropos, but both are so overused in related categories they don't stand out.

Having peeped at a thesaurus, how about 'sketch', 'track', 'depict', 'sculpt', 'relate', or 'peruse' as a base word to play with?

Also having picked a base word, I would skip the extra 'map' moniker and just keep the plain CLI the same as the project name.

Additionally I would kind of suggest merging the CLI and TUI projects such that the default ivocation is the CLI, and adding an -i / --interactive flag. Of course it could still be separated with another name like below, but having both an interactive and non-interactive viewer in one package is more expected than the current lib+cli mix. This seems like it would be more useful grouping issues too. People would be much less likely to report on the wrong repo.

• Project: git-<baseword>
• Library crate: git-<baseword>/git-<baseword>-lib
• CLI: git-<baseword>/git-<baseword>
• TUI: git-<baseword>/git-i<baseword> (or just an -i flag on the CLI)

Of course whatever the name you could also keep all the code in one repo with a Cargo workspace to split the lib/cli too, or even without a workspace with just a bin/lib build target mix.

[mlange-42]

I fully agree regarding the grouping, i.e. separate library, and CLI+TUI in the same repo and executable.

Regarding the base words, I find the general idea of track or something similar, railway-related quite appropriate, as the graphs with their straight lines that avoid intersections somehow remind to railywards.

[alerque]

Both git-track and git-tracks are available as GH org names and CLI tooling names (git-tracker being taken for something unrelated). There is some overlap with the git idea of tracking branches, so that is a point against this name for sure. That would make it relatively hard to search for too, so two points against. But I'm game too, it isn't a bad name. The bahn baseword idea isn't actually that bad either for that matter.

[alerque]

git-rail might be another option, a bit more direct than track and more unique to search as well.