Define community guidelines for extending Jupyter design assets #65
Description
The issue from @jasongrout here: https://github.com/jupyter/trademark/issues/7 got me thinking that this is quite a common pattern that I've seen. It goes something like:
- Jupyter is inherently modular and extendible
- So people extend it to new kernels/use-cases/etc
- They want a logo for their project
- So they slightly modify the Jupyter logo to adapt it to their project-specific setup
In this case it was combining the Rust logo w/ the Jupyter logo, but I've seen it with domain-specific things, color changes, etc.
Since Jupyter is itself designed to be extensible, I think it would be valuable to the community if there were guidelines for how people could gracefully (and without violating Jupyter's trademarks) build on top of Jupyter design assets for their own logos and such. For example - what if somebody designs a new language-specific kernel and they'd like to make a logo for it. It would be nice if there a repeatable pattern they could follow to generate this logo (e.g. the Jupyter logo + a designated space where a new logo would go).
This is beyond my personal design skills, but I wanted to flag it as a thing to think about. How could Jupyter take its philosophy towards infrastructure, and also apply it to design?