On 24/07/16 16:10, Joe Witt wrote: > For sure. Members of the PMC are not necessarily committers, Suneel and I are proof positive. However, I agree that in established projects the PMC is drawn from the technical community, and it would be unusual for someone to be invited to the PMC (to give technical direction and project management overview) without them also being committers.
> Code can always evolve and if a commit happens that needs some refinement > all is fine. In essence ctr is always available. For us adopting RTC it > means, in my opinion, that you should obtain an independent opinion that it > is good to go. As new folks contribute it stokes engagement and even > mentoring and as veterans of the project contribute it encourages shared > understanding. Agreed. Without debating the criteria for committership, I'm still "acquiring my merit" in the project, and when the PMC deem fit, I hope to be invited to become a committer. In the meantime, I will continue to comment on PRs etc from all authors, but don't consider my +1 to be a sufficient review until it is backed by the merit of my committership. > I see it as a sort of rTCtr (case intentional). Does your case notation mean the reviews are not so important as the commits? I'm curious. Presuming RTC only really makes sense of the reviewer groks the code base sufficiently well to understand the implications of the proposed change. Where on the scale of "some passing dude we never heard of before" to "grizzled old committer" do you place 'reviewer'? ;-) As I wrote before, and you state here, we can be quite relaxed about it -- it's all in version control, mistakes can be fixed or rolled-back. Different projects acquire a personality about how they operate, and it is healthy for Pirk to be thinking about these and choosing a model that reflects the community best. Regards, Tim > Provably worth documenting the approach either way on a wiki. > > Thanks > Joe > > On Jul 24, 2016 10:59 AM, "Ellison Anne Williams" <eawilliamsp...@gmail.com> > wrote: > >> This was raised on a recent PR commit; bringing it here for discussion: >> >> It's my understanding the members of the PMC (Tim, Suneel, etc) are also >> committers and able to perform a review in a RTC scenario. >> >> Thoughts? >> >> On Fri, Jul 22, 2016 at 10:05 PM, Josh Elser <josh.el...@gmail.com> wrote: >> >>> I lean towards just needing a +1 to commit and still doing that myself. >>> >>> Just need to be clear however is decided. >>> >>> >>> Ellison Anne Williams wrote: >>> >>>> I don't see point in having to get a +1 from another committer for >> fixing >>>> trivial items such as merge conflicts, build breaks, etc. I also would >>>> through trivial updates to the website like fixing typos, broken >>>> hyperlinks, adding hyperlinks, etc. >>>> >>>> My interpretation of RTC is that the author can commit their own changes >>>> after receiving +1 from a reviewer (another committer). >>>> >>>> On Fri, Jul 22, 2016 at 4:15 AM, Tim Ellison<t.p.elli...@gmail.com> >>>> wrote: >>>> >>>> On 22/07/16 05:50, Andy LoPresto wrote: >>>>> >>>>>> One of the nice effects of RTC is that the community gets an >>>>>> opportunity to gently enforce code convention and prevent rapid build >>>>>> up of technical debt. Something else I've witnessed is that as the >>>>>> community grows, non-committers feel more comfortable submitting PRs >>>>>> because they've seen the same review process applied regardless of >>>>>> the submitter's status. >>>>>> >>>>>> Apologies if I missed these points on an earlier thread. >>>>>> >>>>> Sure, I don't feel strongly either way -- though I would expect a >>>>> committer to be able to fix trivial items like a simple merge conflict, >>>>> or backout a build breaking change without always having to get a >>>>> backing +1 from elsewhere. >>>>> >>>>> Out of curiosity, does folks' interpretation of RTC mean that the >> author >>>>> never commits their own changes? i.e. the reviewer always commits (as >>>>> the original author)? >>>>> >>>>> Regards, >>>>> Tim >>>>> >>>>> >>>> >> >
