I propose to wait for the feedback and do not modify the current vote already launched. After vote completes we have summary, discussion, send PR with updated guide propositions and discuss the PR to close the subject.
I have updated rule 14 with propositions gathered feedback. We stay with 2 reviewers and for breaking changes we require 4. Anyone can comment in response what text rule 14 should have. Then we compile the results. Thanks :-) Tomek On Sat, Feb 22, 2025 at 5:26 PM Tiago Medicci Serrano <tiago.medi...@gmail.com> wrote: > > Hi Tomek, thanks for all the effort ;) > > About proposal 19, I suggested it and dropped it in favor of Nathan's > approach (which Raiden might be favorable as well). Can we reflect it on > the forms? > > The current proposal 14 is about the necessary reviewers. The current text > would be 14.1 and Nathan's alternative proposal (based on areas), 14.2. > Then, we can choose one or other alternatives. > > Best regards, > > Em sex., 21 de fev. de 2025 às 23:30, Tomek CEDRO <to...@cedro.info> > escreveu: > > > Thank you Tiago! I have prepared a google form with all questions 1-19 > > updated based on our discussions, I will post it now as separate > > thread so it is not missed, hopefully this way will help in results > > gathering and presentation and there are optional fields where anyone > > can propose better texting and/or rules update if the do not agree :-) > > Tomek > > > > On Fri, Feb 21, 2025 at 5:56 PM Tiago Medicci Serrano > > <tiago.medi...@gmail.com> wrote: > > > > > > Hi all! > > > > > > About the pending proposals, can we proceed to another vote round? > > > > > > I think we should wrap up it subject and create the article in the docs > > as > > > soon as possible... > > > > > > Are we waiting for something else? > > > > > > Best regards, > > > > > > Em ter., 18 de fev. de 2025 às 09:45, Tiago Medicci Serrano < > > > tiago.medi...@gmail.com> escreveu: > > > > > > > Hi! > > > > > > > > So is it okay to keep 2 reviewers for version bumps and documentation > > > >> updates and 4 for the rest? Maybe its good to have two rules: 2 > > > >> reviews for trivial updates like version bumps and documentation > > > >> update (what else?) and 4 reviews for all other PRs? > > > > > > > > > > > > IMHO, It's still too restrictive. I liked the concept of having these 4 > > > > major areas: > > > > * Under Development: 1 reviewer > > > > * Experimental: 1 reviewer (eventually 2 if breaking changes) > > > > * Production Stable: 4 reviewers (in case of breaking changes, still > > valid > > > > the rule for discussing in the mailing list) > > > > * Periphery: 1 reviewer > > > > > > > > Best regards, > > > > > > > > Em seg., 17 de fev. de 2025 às 19:15, Tomek CEDRO <to...@cedro.info> > > > > escreveu: > > > > > > > >> On Mon, Feb 17, 2025 at 12:20 PM Tiago Medicci Serrano > > > >> <tiago.medi...@gmail.com> wrote: > > > >> > Hi! > > > >> > Thanks, Tomek, for summarizing it. > > > >> > > > > >> > I liked Nathan's proposal. Instead of simply increasing the number > > of > > > >> > reviewers from 2 to 4, we can adopt tags (we can even evaluate if > > the > > > >> bot > > > >> > can do it automatically), and, based on such categories, we have new > > > >> > requirements for the reviewers. > > > >> > > > > >> > Considering that, I'd drop the concept of *Lazy Consensus* (item 19) > > > >> > because it covers my main concern: > > > >> > > > > >> > We *should* try to keep NuttX as stable and backwards compatible as > > > >> > > feasible so that people can adopt NuttX and count on it to keep > > > >> > > working for them in the long run. > > > >> > > At the same time, > > > >> > > > > > >> > > *we need to be very careful not to make rules thatare too strict > > and > > > >> > > inflexible, because then we would risk turning awaycontributors > > and we > > > >> > > would end up with old cruft that is really brokenand generating a > > lot > > > >> of > > > >> > > complaints but can't be fixed because it wouldbreak the rules.* > > > >> > > So we need to strike a good balance. > > > >> > > > > >> > We don't need a general rule and 4 reviewers for Documentation and > > new > > > >> chip > > > >> > bring-ups. We need 4 (or even more) reviewers for changes that break > > > >> > production-ready interfaces. > > > >> > > > >> Yeah I just wanted rules to be as simple as possible and generic that > > > >> would avoid exceptions. If exceptions are required then maybe another > > > >> simple rule should be added? The problem is we don't really know what > > > >> change will break what and lots of PRs had testing section as short as > > > >> "CI" nothing more :-P > > > >> > > > >> So is it okay to keep 2 reviewers for version bumps and documentation > > > >> updates and 4 for the rest? Maybe its good to have two rules: 2 > > > >> reviews for trivial updates like version bumps and documentation > > > >> update (what else?) and 4 reviews for all other PRs? > > > >> > > > >> Thanks! :-) > > > >> Tomek > > > >> > > > >> -- > > > >> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > > > >> > > > > > > > > > > > > -- > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > > -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
