Create a single terminal-templates repository

[belak]

It seems like most terminal files end up being fairly similar - maybe it would make sense to have a base16-terminal-templates (or some other similar name) which has all the terminals which we support in different folders.

[joshgoebel]

I'd be for this, I wonder how the individual template maintainers would feel? It would make larger upgrades/maintenance a LOT more convenient.

[belak]

Pinging everyone currently listed as a terminal template maintainer:

@martinlindhe, @aarowill, @niklaas, @h404bi, @AFulgens, @philj56, @tomyun, @orhun, @kdrag0n, @cskeeters, @geoffstokes, @benjojo, @honza, @khamer, @karlding, @wuqs-net, @afq984, @binaryplease

[joshgoebel]

And now since you all got pinged anyways, perhaps also have a glance at #36 and #45 which are likely relevant for all of you.

[afq984]

It seems like most terminal files end up being fairly similar

Could you elaborate on how terminal templates are more similar to one another, than other non-terminal templates?

[joshgoebel]

I think we mean conceptually not literally that all terminal configs look alike.

Basically each terminal template (from what I've seen at a glance) is trying to map the Base16 palette into the terminal's 16 color ANSI palette space, which makes the actually mappings very conceptually similar in what is happening in each terminal template.

[belak]

In general terminal templates are a 1-time setup: they involve setting up a foreground/background, and the 16 ansi colors (as well as the alternate mapping for the 256 color scheme). They'll all have to do the same setup, but in different formats.

Editor templates end up changing a bit more - different things need to have colors added for, new features are added, that sort of thing.

[joshgoebel]

I think one issue here is often that the template repos have their own very nice individual READMEs and FAQs, etc... and there is a certain gravitas/individuality that comes with this... that just merging them all into one huge mono-repo takes away...

[afq984]

Thanks for the explanation, so the main difference is probably that terminal templates are probably 1:1 mappings and non-terminal ones are probably more complex and unstable.

It would make larger upgrades/maintenance a LOT more convenient.

@joshgoebel Is there something you're trying to push forward but found the distributed situation today to be an obstacle?

I think updates can be automated by GitHub actions set up on each repo; other larger scale changes that would require edits to the mustache templates would probably need review from terminal owners.

Also I'm a bit concerned about base16-terminal-templates hurting SEO and discover-ability, compared to terminal specific repositories. I think moving the repos to base16-project is a net win though.

[belak]

From my perspective, maintaining 10-20 (or more) separate repos is a lot of additional work:

• CI needs to be set up
• Permissions need to be set up - this currently additionally involves a new group on Github
• Branch restrictions need to be set up
• PRs and issues need to be monitored

Currently, none of those can be done automatically and they need to be done every time a new terminal repo is created. There's also been talk about adding additional types of schemes (like an ansi16 palate which lines up with the expected ansi colors) which would then involve an update to every single terminal repository, rather than 1 large one to the terminals repository.

I think one issue here is often that the template repos have their own very nice individual READMEs and FAQs, etc... and there is a certain gravitas/individuality that comes with this... that just merging them all into one huge mono-repo takes away...

This is true, but we can still have READMEs in subfolders. It would just be one folder removed.

I think updates can be automated by GitHub actions set up on each repo; other larger scale changes that would require edits to the mustache templates would probably need review from terminal owners.

Yes, that would work. We could also use GitHub's CODEOWNERS file to require updates to specific templates.

Also I'm a bit concerned about base16-terminal-templates hurting SEO and discover-ability, compared to terminal specific repositories. I think moving the repos to base16-project is a net win though.

As an effort to offset that, we could pin the base16-terminal-templates repo in the org. It could also be advantageous because then there's a single place people need to go in order to get a terminal color scheme, rather than going to the base16-project/base16 repo, figuring out who's maintaining their specific terminal (if anyone), and go there.

Plus, there's no guarantee people will be willing to transfer their terminal repos to us. There are a lot of them, and many have inactive maintainers.

[afq984]

maintaining 10-20 (or more) separate repos

Aw, the per-repo configuration sounds like a real pain.

If we want base16-project to take ownership of the maintenance/infrastructure, and given the points above https://github.com/base16-project/base16/issues/44#issuecomment-1175452375, a single centralized repository makes more sense to me.

My previous comments were still in a mindset of keeping the terminal templates community-owned (contrib), rather than base16-project-owned. So CI, branch restrictions, PRs, issues and updates are just up to the repository owners. In this case putting the repository into the org would just make it easier to transfer the ownership if the maintainer happens to be unresponsive.

Both options are good for base16-xfce4-terminal.

Permissions need to be set up - this currently additionally involves a new group on Github

Does outside collaborator solve this?

[joshgoebel]

community-owned (contrib), rather than base16-project-owned.

I'm don't see it as a strict dichotomy. I'd like to (in a perfect world) imagine co-ownership for base16-project repos (esp if they are transferring from outside the org)... Things in base16-projects might still be considered community owned, just the organization (and core team) would have a much stronger degree of responsibility/stewardship there than in contrib. I guess it all depends on what one imagines the word "owned" confers...

I haven't worked inside an org with this type of core/contrib split before, so I can only imagine how it's supposed to work in theory, not practice...

[niklaas]

Pinging everyone currently listed as a terminal template maintainer:

I assume you pinged me because of https://github.com/niklaas/base16-blink. :) I haven't touched/used this in a long, long while. I'm happy (a) to verify that it's still working and (b) to move this wherever it's best for the community.

Just ping me once you settled on a decision on what's best for the community and I'll take a look at (a) to see whether (b) would make sense.

[karlding]

I vaguely recall at the time when I created the template repo that I'm being tagged here for, base16 had no desire for a centralized org containing templates and builders and encouraged this decentralized approach that's being moved away from. It sounds like base16-project wants to take ownership of more things, which sounds fine with me.

[orhun]

FYI I'm fine with a central repo/organization for the base16 terminal theme that I created.

[honza]

+1

[cskeeters]

Has chriskempson stated an opinion on this? I don't want to speak for him, but it seems he set this up so that things would remain more static. This limits the amount of time a color scheme developer or template maintainer would have to spend because changes in one don't affect the other. Personally, I don't have a lot of time to be involved in a project where things change in the interest of improvement.

I wouldn't hold it against you if you took the base16 builders, color schemes, and templates and put them in a new repository that was designed to facilitate more change. I think all of the licenses allow for this.

[belak]

Has chriskempson stated an opinion on this?

No, he's ignored all our attempts to contact us, removed my commit access, removed the history on his base16 repo, blocked us on GitHub, and closed the issue trackers on all his repos. He hasn't explicitly stated anything.

I don't want to speak for him, but it seems he set this up so that things would remain more static. This limits the amount of time a color scheme developer or template maintainer would have to spend because changes in one don't affect the other.

We're still figuring this out, but I think we're going to work on our "next gen" base16 (which we're going to call base17). The goal is to be forwards compatible for both color schemes and templates, but we'll be adding additional features so if templates want to use them, they can.

Personally, I don't have a lot of time to be involved in a project where things change in the interest of improvement.

This is one of the reasons we're trying to transfer repos to this org - so if/when people get burned out or tired of maintaining a template, someone else can step up.

I wouldn't hold it against you if you took the base16 builders, color schemes, and templates and put them in a new repository that was designed to facilitate more change. I think all of the licenses allow for this.

The idea behind this issue is lessening the burden of maintaining a bunch of terminals which almost all do very similar things - provide mappings for the 16 terminal colors and possibly a 256 color template for use with base16-shell. I don't think we'd want to put everything in a single repo - that was what happened with the original base16 (and a few past forks) and it wasn't super maintainable.

I think doing this for only terminal color schemes is a small enough surface area where it could work.

[cskeeters]

I'm just now realizing that this issue is in the base16-project, which is not Chris' and you are already in the process of forking all of the repos. For anyone else who is unaware, the backstory has been documented here https://github.com/base16-project/home/issues/51

[AFulgens]

As described in https://github.com/base16-project/home/issues/65#issuecomment-1229408401 I welcome the idea of merging the repositories into a centralized one. Two ones "maintained" by me are really low maintanence anyways :)