Skip to content

Define community guidelines for extending Jupyter design assets #65

Open
@choldgraf

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?

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions