Closed joshgoebel closed 8 months ago
I do think our overall vision here has implications for how we handle some things like base16-schemes, etc... for example the path I'm suggesting would likely have us leaving base16-schemes alone (or the base16
folder if we go that route)... it would continue to serve as a convenient "aggregate" for all base16 schemes as long as it proved a helpful resources... and the next generation of schemes would be their own discrete thing...
So the talk would switch from "upgrading" all the schemes (or the entire repo) to instead creating new variations that support all the new features, and leaving the old base16 olds as they are...
I'm going to try and sum up what we've talked about in IRC before:
The short version is that base17 will be "our version of base16". I'd also imagine we will continue to develop Base17 and Base Next at the same time.
possible suggestion for the project name - base0x10
:)
My 2ยข about the whole story (seen through issues #51 and this one, additionally prompted through #36 and #44). I'm indifferent either way.
Think of all the freshmen in college, who will have to dive into obsure historical details, when they want to find out why is 17 in the name!
Isn't this why history is fun? ๐๐ค I'm no longer super invested in what the new name is... I see good arguments all around for many of the possibilities suggested. To avoid further "conflict" with Chris I do slightly prefer a name without "Base16" in it though.
I'm closing this for now, since it's not really actionable, but please feel free to open issues if you have any other questions or comments.
I want to be clear I'm not speaking for the whole organization, these are definitely my thoughts, and feedback is welcome. - hence my tagging this discussion and help wanted. Though at the end I suggest that it could be beneficial if the entire organization decided on clear messaging around this topic. It's possible the choice of Base17 as a name was poor. To me it only implies "the next version", not "base16 original flavor is dead"...
So I've seen concern around the various direction/directions we're talking about regarding Base17/BaseNext DRAFT. It's for sure a more featureful vision that allows for a lot of additional flexibility, better application support, higher fidelity porting of existing themes, better interop with other theming formats, etc... and with that yes, it adds a bit of complexity - though I don't think too much. (given all the benefits) But I wanted to address concerns...
Some portion of these concerns boil down to:
Base16 is simple, it works great, I like it as-is. Don't change it or take it away from me!
Chris still owns base16, so we actually can't change it - only Chris can. I'm also not sure anyone is trying to take Base16 away from anyone.
I've personally never wanted to replace base16 - and I personally don't think that should be a goal for the organization either. Base16 is great for many use cases, it has evidently existed since 2012 largely unchanged (esp the style spec, the schema spec)... In places where it's already shines it's possible it will still be shining 10 years from now.
Anyone who wishes to continue to author base16 schemas and templates - or use the resulting themes: If you like exactly what base16 has to offer, great. I have no plans to drop support from the Node builder - and there are plenty of other base16 builders besides. Ever since Chris chose to keep Base16 separate the vision I (personally) have is of lots of theming systems that can interact and co-exist together... base9, base16, base24, ansi16, baseNext, [pick almost any outside theming system with semantic meanings tied to colors, insert here]...
I don't think it's a zero sum game. Vim and VS Code both exist, both with vibrant communities. I'd like to hope our first "next thing" is compelling and gets many people truly excited and chomping at the bit to upgrade - but if you aren't one of those people, that's ok. I'd encourage us as an organization to consider making a clear statement to the effect of:
Yes, fixing our naming issues will help with some of this, but I think it's one piece of the puzzle, not the entire puzzle.
Thoughts?
Edit: Replaced many places of
base16
withbase16 0.2
to clarify I'm talking about the style/schema/templating spec largely - though I'm not sure it helps. ๐ Another reason that the current way the spec is split out is confusing for referring to "point in time" versions of a style system. It really feels likebase16 v0.2
should be sufficient but really I need to instead say :base16 0.2 style guide plus base16-builder 0.9 (schema/template details but not builder detail)
Ugh.