I don't think anybody is pining to make compliance with Bertrand's very nice document into a policy document. Rather, some people are finding it a useful guide to gauging project maturity, which is great and should be encouraged.
On Thu, Nov 5, 2015 at 1:35 PM, larry mccay <lmc...@apache.org> wrote: > Hi Caleb - > > I am glad that it is useful for your projects. > > I think that the use of it that you describe is valuable. > It should be used as guidance and interpreted by the mentors for each > podling. > > "These sort of metrics can be used to indicate health in this way or that" > - this is different from "these specific metrics must be met". > > We can certainly articulate requirements but they should be more specific > to behaving in accordance to "the apache way" then dictating very specific > community decisions or milestones. > > As mentor training, guidelines, etc - this is quite valuable and should > help in guiding podlings to graduation rather than deciding whether they > graduate or not. > > thanks, > > --larry > > On Thu, Nov 5, 2015 at 1:12 PM, Caleb Welton <cwel...@pivotal.io> wrote: > > > I am not in favor of bureaucracy, However... > > > > Having reviewed the maturity model and speaking as a member of a newly > > incubating podling I would like to chime in to say that I find it very > > useful. It helps frame discussions around what we can be doing as a > > community to embrace the apache way, move towards more inclusive > > development and communication models, and gives a sense of direction we > > need to be moving towards. > > > > Especially starting with an established team working on close source > > project and bringing it into Apache requires some cultural change and > > entering into a newly incubating podling can feel a bit like diving into > > the unknown. Having some structured recommendations on what we can do to > > help move things in the right direction is useful and helps provide > > guidance. For the communities that I'm engaged with I'm actively > > encouraging us to voluntarily use this tool because I think it provides > > useful guidance. > > > > If you think the tool as expressed enforces "rote learning" how would you > > suggest improving it to account for differences in communities? Are > there > > particular points within the tool that you find less useful, or things > that > > are missing? > > > > Regards, > > Caleb > > > > On Thu, Nov 5, 2015 at 9:49 AM, larry mccay <lmc...@apache.org> wrote: > > > > > +1 - I am concerned by the trend that I see developing here. > > > > > > A set of interview questions for evaluation is one thing but criteria > > > checkboxes that will encourage behaviors by rote will not actually > > develop > > > more healthy communities just communities that can get the boxes > checked. > > > > > > While certain metrics like adding PMC members may be indicators of > > natural > > > growth they should not be required otherwise they will be done > > > artificially. > > > > > > On Thu, Nov 5, 2015 at 7:30 AM, Justin Erenkrantz < > jus...@erenkrantz.com > > > > > > wrote: > > > > > > > On Wed, Nov 4, 2015 at 12:50 PM, Roman Shaposhnik < > > ro...@shaposhnik.org> > > > > wrote: > > > > > Correct. It is a tool, but not a requirement (at least not yet). > > > > > And since I repeatedly suggested this tool on this thread let me > > > explain > > > > why. > > > > > > > > And, this is the root of my concern expressed in the other general@ > > > > thread: I fear that this is going to quickly evolve to yet another > > > > bureaucratic form that the IPMC is going to quickly require all > > > > projects to complete. > > > > > > > > We should not be trying to force rote learning. Every community is > > > > different. > > > > > > > > Trust the mentors or don't - but, I am very much opposed to more > > > > overhead. Forcing projects to feel like they have to report monthly > > > > is against what we should be about. I believe that the IPMC should > be > > > > imposing the barest amount of overhead to what the Board requires > from > > > > the full projects. To that end, having mentors explicitly sign-off > is > > > > fair - but, additional paperwork is not. -- justin > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > > > > > > > > > > >
