Personally, I like having guidelines for the implicit rules that we already
know about and, then, growing as the project grows and as we learn from
users/contributors.

For example, one of my favorite community learnings has been around
authorization. Polaris came with native RBAC, but we have seen several
contributors want to extend this functionality - I'm thinking of the OPA
work as one recent example. Eventually, I would expect that this would
morph into an explicit SPI with explicit guidelines around contribution &
evolution.

So, I think the PR guidelines you have written are good and we can iterate
as we learn. This way, we aren't trying to solve all of our problems at
once, but remain flexible to how the project grows.

Go community,

Adam

On Fri, Nov 21, 2025 at 9:18 AM Dmitri Bourlatchkov <[email protected]>
wrote:

> Hi All,
>
> It looks like this PR attracted somewhat different opinions in terms of
> what is a significant change, what is not and when to wait. Let's discuss
> this on this thread before revisioning the PR.
>
> From my POV, having strict rules is not practical at this stage of the
> project because:
>
> * API/SPI is not well-defined
> * The codebase evolves quickly, so it is hard to predict downstream ripple
> effects.
> * Contributor interests are not equally distributed across the codebase
>
> I'd propose a common sense approach where the author and reviewers assess
> the impact to the best of their knowledge and then decide:
>
> 1) If the change is small and relatively isolated, the change can be merged
> immediately.
> 2) If the change can reasonably be expected to have non-trivial effects in
> runtime or in downstream projects, wait 3 working days for other reviewers
> to start discussions if necessary.
> 3) REST API changes are to be discussed on `dev` in all cases.
> 4) If a concern is missed during review, let's fix forward on `main`. We'll
> learn from this and take it into account in subsequent reviews (common
> sense).
>
> As the project matures and java API/SPI modules are more formally defined,
> we can add more specific guidelines for them.
>
> WDYT?
>
> Thanks,
> Dmitri.
>
> On Mon, Nov 17, 2025 at 10:05 AM Dmitri Bourlatchkov <[email protected]>
> wrote:
>
> > Hi All,
> >
> > I opened PR [3067] proposing a bit of clarification and more review time
> > for more intrusive PRs. Please refer to GH for the example language.
> >
> > Please comment about grammar / spelling in GH, but if you have comments
> > about the subject matter, it might be best to use this email thread for
> > discussing those.
> >
> > [3067] https://github.com/apache/polaris/pull/3067
> >
> > Thanks,
> > Dmitri.
> >
>

Reply via email to