Thanks for the feedback, Adam! I'd also appreciate more active engagement from Polaris committers, since they are the ones who are affected by this change in guidelines :) All opinions are welcome.
Thanks, Dmitri. On Fri, Nov 21, 2025 at 11:03 AM Adam Christian < [email protected]> wrote: > 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. > > > > > >
