@@ -9,13 +9,8 @@ if the added benefit is worth the effort of adapting existing code.
99
1010Because we are a visualization library, our primary output is the final
1111visualization the user sees; therefore, the appearance of the figure is part of
12- the API and any changes, either semantic or :ref: `aesthetic <color_changes >`,
13- are backwards-incompatible API changes.
14-
15- .. toctree ::
16- :hidden:
17-
18- color_changes.rst
12+ the API and any changes, either semantic or aesthetic, are backwards-incompatible
13+ API changes.
1914
2015
2116Add new API and features
@@ -37,6 +32,23 @@ take particular care when adding new API:
3732 __ https://emptysqua.re/blog/api-evolution-the-right-way/#adding-parameters
3833
3934
35+ Add or change colormaps, color sequences, and styles
36+ ----------------------------------------------------
37+ Visual changes are considered an API break. Therefore, we generally do not modify
38+ existing colormaps, color sequences, or styles.
39+
40+ We put a high bar on adding new colormaps and styles to prevent excessively growing
41+ them. While the decision is case-by-case, evaluation criteria include:
42+
43+ - novelty: Does it support a new use case? e.g. slight variations of existing maps,
44+ sequences and styles are likely not accepted.
45+ - usability and accessibility: Are colors of sequences sufficiently distinct? Has
46+ colorblindness been considered?
47+ - evidence of wide spread usage: for example academic papers, industry blogs and
48+ whitepapers, or inclusion in other visualization libraries or domain specific tools
49+ - open license: colormaps, sequences, and styles must have a BSD compatible license
50+ (see :ref: `license-discussion `)
51+
4052.. _deprecation-guidelines :
4153
4254Deprecate API
0 commit comments