Policy: New themes going into core?

[joshgoebel]

#2151

What is our policy with new themes? Are there any guidelines on what is required to merge them, or would we prefer all themes be in external repositories (like languages) and no longer accepting new themes to core?

And since themes are much simpler might it be preferable to have a highlightjs-additional-themes repository to direct people too and just always accept PRs there? Kind of like a smorgasbord of themes for anyone who wants something not in the default set?

[marcoscaceres]

Should use same policy as languages: i.e., external repo.

[joshgoebel]

@marcoscaceres @egor-rogov

And since themes are much simpler might it be preferable to have a highlightjs-additional-themes repository to direct people too and just always accept PRs there?

And what about this idea? I don't think we want to setup individual STYLE repos at the core organization for people, but what about the "discoverability" (which we do seem to care about for languages)? Wouldn't having one big style repo that was pretty much "open to contribution" solve both problems and give us a central place for styles?

If we needed to "disclaim" it a little we'd have the name and README that could be used to say "these are unsupported styles from the community, etc"...

Thoughts?

---

Creating a GitHub repo on your own that no one is ever going to find doesn't feel much like "contributing" to the project... It feels little bit like we're telling them "frack off, we don't really care you and your style contribution".

[marcoscaceres]

I don't mind to be honest... problem is just having people to maintain things. The intention is to build separate communities and maintainers of this project are also part of the new repo (why we put them in our own organization - so it's not so much "frack off", but more "own your stuff, and we are here to help you... but own your stuff.")

[joshgoebel]

Well, are you saying we want 1000 CSS repos in the highlight.js organization also? That seems like a LOT of work vs having one large one... Are we perhaps confusing ownership with "maintenance"? I'm not sure just having separate repos really encourages regular "maintenance" of said repos. Look at all the dead repos on Github. :-)

Does themes really require maintenance?

If we did add a new class... "burgers"... for tasty new morsels of code... would it be easier to coordinate that with 1000 separate repos or one large style repo? (ie, if someone wanted to pitch in and say add support to all themes - say a burger was really close to a keyword and by default we'd just copy that styling for older themes...)

[joshgoebel]

I think we're both worried about long-term maintenance, we're just thinking about it differently. Not sure what the right answer is.

[marcoscaceres]

We get very few themes (vs languages), so happy to keep them here.

[joshgoebel]

We get very few themes (vs languages)

True. Ok, why don't you handle a response to #2151 then and then I'll follow your lead on how I respond to themes in the future.

[joshgoebel]

We get very few themes (vs languages), so happy to keep them here.

Closing this with this as the answer if you have no issues, @egor-rogov.