Allow Commission Decrease at Any Time

Well, the purpose of sections is documented for a reason in the template. Clearly stating the impact on each SIMD helps with prioritizing work on these features (which always involve a lot of testing, btw). Unless I'm mistaken, this seems like "nice to have" level of importance to the ecosystem.

Impact How will the implemented proposal impacts dapp developers, validators, and core contributors? The text included states how the change will impact validators. There is no impact to the other categories outside of the truism that "any change could affect anyone".

Do we know how many validators have the policy mentioned in the motivation section, or how common this problem is? Something like that would be nice to document as impact, because I agree with Richard that unless we understand that this change does seem "nice to have"

Is one good reason not enough?

I asked my colleagues to review and approve once I have a second opinion from my team. (It looks good to me). Thanks for submitting this.

Is one good reason not enough? @bji Yes -- Long story short, we should to scrutinize feature activations more, especially by triaging them by usefulness. The impact section would be the place to make an argument why the feature is important. The text included states how the change will impact validators. If most validators didn't notice activation of this feature, is it really impactful? But your point is valid, the template should be clearer about the purpose of this section. Considering this doesn't improve performance or reliability and it's unclear whether anyone else will use this feature, I would say it's barely enough justification. The risk of any feature flag is that it halts the ne

The original feature which prevented changes to the commission in the second half was an over-reach. It had a goal ("prevent rug pulls") and it created collateral damage by implementing a more restrictive than necessary policy. It doesn't seem like the best way to have technical discussions to have to provide justification for whether or not the reasons are "good enough". What you think is important, someone else might not. It's necessary to include importance in prioritization of effort, but when discussing technical merits of a proposal, I think justification just should be a minor factor, and having "one good reason" should be good enough. In this case, I've already given a justification

Green light from Firedancer side, but considering this low priority. Thank you; the implementation has already been provided to Solana Labs as a PR so from their perspective it should be an easy thing to take. Once it's reached consensus within the cluster Firedancer would have to implement it; but I think it's a very easy implementation.