Hi Dmitri, Even though I am not a big fan of strict rules or guidelines (I trust people :)), your proposal seems reasonable to me.
I would suggest one addition: requiring a minimum of two approvals for a PR to be merged. This would also serve as a mechanism to naturally introduce a waiting period for reviews (and thus, the suggested "x days"). Regards, JB On Thu, Nov 27, 2025 at 6:27 PM Dmitri Bourlatchkov <[email protected]> wrote: > > 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. > > > > > > > > >
