Hi Robert, Thanks for starting this discussion.
I’m not sure we need strict or explicit guardrails at this stage. I believe the community already operates with good intent and that these considerations are typically addressed during our existing review process. Part of the value of our collaboration is how we naturally work together to uphold these best practices and expectations. While the points you shared are valuable and serve as a good reminder, I believe these guardrails are already implicitly in place. Regards, JB On Wed, May 6, 2026 at 6:41 PM Robert Stupp <[email protected]> wrote: > Dear Polaris community, > > I would like to ask for a discussion on whether we need clearer guardrails > for security-sensitive changes. > > The topic already came up in PMC discussion and the feedback there was to > discuss the guardrails question on dev@. > > I think the project would benefit from clearer guardrails for > security-sensitive changes, especially where changes touch authorization, > credential vending, storage boundaries, secret handling, or similar areas. > > For that reason, I think it makes sense for the community to agree on a > small set of guardrails for such changes. > > I would like the community to discuss and ideally adopt guardrails along > these lines: > > * if a PR expands capability in one of these areas, it should not merge > while the boundary/authz/validation part that makes it safe is still > deferred to follow-up work, > * off-list discussion may inform a design discussion, but it should not be > presented as if it already settled an on-list project decision, > * "beta", "experimental" and "off by default" do not lower the security or > design-review bar for shipped code, > * risky or immature features should not be described in release notes or > docs as production-ready before their actual limitations are resolved, > * risky changes in these areas should include a review that explicitly > checks the mandatory safety properties, and > * if a subsystem already has open security or boundary debt, additional > feature expansion there should be approached conservatively until the key > invariants are clarified and tested. > > My ask is simply about whether guardrails of this kind are needed, and if > so, which ones we want to adopt. > > If there is agreement on this, we can simply refer to it in future reviews > instead of arguing the same point repeatedly. > > I would appreciate your feedback on whether the project wants guardrails of > this kind, and if yes, which ones. > > Robert >
