I thought I'd comment from Groovy's point of view, being on the "receiving" end of the audit.
I felt that the structure the audit provided to discussions about "Are we there yet?" was very valuable. It didn't feel to me like the audit was imposing any new requirement or policy that I hadn't heard about before - just presenting a structured checklist to make sure we hadn't forgotten anything and to avoid going over ground multiple times for things which had been decided/discussed previously. It was also presented to us as a guideline. I think this is a very healthy way to view it. Most of our mentors seemed to have had a "gut feel" for when projects are ready for graduation. A guideline doesn't preclude that human aspect but does assist with focusing the discussion around the important points and making it less subjective in many areas. Also, as a guideline it would leave open the ability for us to make a case for why a particular audit item may not apply or might apply differently to us. We didn't end up having any such requirement but if we did and we found an acceptable compromise, then it would be recorded for future reference. So, I'd certainly recommend any project adopting the maturity model as a guideline. Cheers, Paul. On Fri, Oct 16, 2015 at 12:40 AM, Jim Jagielski <j...@jagunet.com> wrote: > >> On Oct 15, 2015, at 10:03 AM, Rich Bowen <rbo...@rcbowen.com> wrote: >> >> >> >> On 10/15/2015 08:21 AM, Jim Jagielski wrote: >>> If we are to use the maturity model as the guideline regarding podling >>> graduation, then certainly the model should be voted on and approved >>> by the membership as *the* model for the ASF, right? >>> >>> Basically, it looks to me that the model is proposing and creating policy, >>> and this is something that needs to be done 'correctly', if you get my >>> meaning. >> >> +1 >> >> This is why, in that other thread, I suggested that mentors voluntarily >> evaluate their podlings based on these guidelines, but didn't suggest any >> kind of actual policy change or requirement. >> > > My only concern is that if it becomes a de-facto 'standard' w/o > being vetted and approved by the membership/board/incubator/etc... > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org