There are in other helm chart many nice example documentation in comments of values.yaml, we don't have much of that. See for example GitLabs' Helm charts for GitLab itself or GitLab runners and note how they use ## and # differently. Also read about the Helm best practices.
We have so far opted to put things in schema.yaml, which renders to the z2jh.jupyter.org's configuration reference. I'm not at all sure about what makes the most sense, but I think if we choose one it may be the schema.yaml, and I'm cautious to going for both.
As I'm not sure myself about this makes sufficient sense to go for, I'll remove the labels @betatim. I'd like to hear what others think, but I'm leaning towards sticking solely with schema.yaml atm. Relevant to know is that we can also use such schema file to validate our chart with Helm3 I think, but it needs to be more complete then.
Definitely avoid maintaining the same documentation in two places, it's guaranteed to get out of sync! It's hard enough keeping one set of docs up to date 馃榾. One option (a fair bit of work) is to have a script that parses one of the files and outputs the other with added docs, e.g. if schema.yaml contains everything include the defaults we could maybe parse it and autogenerate values.yaml.
That would be neat, but I don't think it's a high priority given all the other issues.
Just had a thought, could we have a label for closed issues that indicates good idea but too difficult for now so we can still track them down in future?