Thanks for this question. We 've been visiting it already lately. We haven't gone through a process of documenting it as a policy (as we are still experimenting) but I 'll do my best to summarize what my understanding of that recent discussion was (feel free to correct me)

* applications/services that are developed internally and are supporting end-user applications should always use the scaffolding we provide. As a helping point, these all are under the helmfile.d/*services hierarchy in the deployment-charts repo. They all also invariably use the "services images" as described in https://wikitech.wikimedia.org/wiki/Kubernetes/Images. And finally, there are a lot in numbers (I count 33), always increasing.

For these charts, upstream helm charts can be used as an inspiration, but the ending helm chart should be WMF owned. That way they 'll have a helm chart that we will be able to keep up to date with our standards, allowing for consistent behavior across the various sidecars, labels, tolerations, canaries, affinities and other functionalities that we 've been implementing. We 've already gone down the road of allowing some helm charts to diverge from that consistent path and it was painful every time we needed to do some operation on the services they powered. Needless to say we have backtracked from it and don't want to ever go down that path again.

* apps/services that are deployed as a part of a cluster. These are few and additions happen rarely. They are always deployed by an SRE as part of functionality added to a cluster. Their distinguishing point is that they all are under the helmfile.d/admin_ng directory of the helm charts repo. They also all use images that are defined under the badly named "production images" part of https://wikitech.wikimedia.org/wiki/Kubernetes/Images. They are few in number (I count 8) respectively. For those, **for now** the agreement is to experiment with upstream charts and figure out if indeed they make sense or not and how heavy modifications we 'll need to do to them for our purposes. 

Flink-operator is such an example. spark-operator was a chart however the needed heavy modifications by Ben in the RBAC rules it shipped with as it came with overly broad rules and thus access. 

Specifically for Jaeger, I think it fits the second category, so it probably is ok to experiment with the upstream chart and figure out if it is good enough or not.