Dmitry,

I can add a little to what Adnan shared...

Helm tries to provide a semantic version guarantee to not break APIs on a major version. When the development from Helm v1 to Helm v2, which was mostly a re-write, there was a lot of development. After the 2.0.0 release there were new features until Helm v2 was in pretty good shape and Helm v2 was mostly seeing minor feature additions and bug fixes. Development slowed down naturally.

Open source projects, in general, go through different phases of activity. It can go up and down depending on what's going on. Helm had a peak during the Helm v2 major development and then it went into a valley. It's about to peak again at Helm v3 is being heavily invested in.

I can try to add some context to the issues brought up:

• #3506 fixed a problem some of us needed to get fixed. There was a little pressure to get that fixed. Looking at the timing of the 3506, there was a 20 day gap between feedback and response to it. The alternative, that merged, was proposed and merged right about the same time that 3506 was responded to and made ready to go. I think it was more of a race condition to get one in. A change of a L or greater in size needs two helm core to approve and that happened on the alternative to 3506 first. I hope that helps understanding the why around them. There was definitely no ill will.
• For #3481 the reason, I think, that bacongobbler tagged it was he supporting issue triaging. This is something core maintainers do. For me, I'm not sure how to quickly respond to it. I'd need to dig into the other work you linked off to as well as comparing what you want compared to the output with the `--debug` flag. Since I'm not working in that space I don't have the time to dig deeper and I'd hope for others to jump on this. A lack of response may mean others aren't working on the same problem space and otherwise busy. I know this can be frustrating. Have you reached out in slack or thought of coming to one of the helm developer calls to ask about it?
• Helm tries to have good docs and examples so people can know how to use it. The Kubernetes community has talked about how insufficient docs is a problem for kubernetes as a whole. On #3540, I think it's reasonable to ask for those and then have a discussion. I would hope that when I made a new feature addition to helm 2 that someone would ask this of me. To hold me accountable.

This is all my 2 cents and an effort to add clarity. Contributions are appreciated and navigating the community interactions isn't always clean. Sorry for where it's messy.

Matt Farina