+1 to flagging mentor absence; and I like making it automated otherwise it's not going to happen (or rather, it'll be up to a podling to flag it and they're unlikely to feel comfortable doing so).
Justin's two metrics are interesting to me as I (kinda) don't view either of those as mentor responsibilities. For me a mentor is: 1) Someone who prods the podling to move along to the next step in its path in the incubator. 2) Someone who monitors the list for general 'flow'. Is dev happening, does it seem to be moving along nicely etc. 3) Someone who joins in on exceptional/abnormal threads (ie: when #2 hits bumps). 4) Someone who deep dives early on in the podlings life to get things moving. 5) Someone who is reviewing the podling's board report. For me a mentor is not required to be: 1) Someone who is a coder on the project, or deep in the technology in question. 2) Someone who votes on how the project chooses to develop, or 3) Someone who votes on the technical choices in the project, 4) Or, someone who is deep diving into release votes once a general cadence has been set (beyond that need for IPMC +1s). When a project is ready to graduate, the mentors of the project should be doing practically nothing with their mentor hat on. -- Given all that, I would definitely lean towards automated flagging for mentors when not reviewing the podling's board report. I'd also have an urge for us to define more specific milestones within incubation, with more expectation on mentor activity for podlings at earlier milestones. Hen On Sat, Mar 31, 2018 at 4:24 PM, Justin Mclean <jus...@classsoftware.com> wrote: > Hi, > > > As for the metric -- I really think that using mentor turnout on release > > voting threads will serve us well. > > My concern with using that as a metric is people will just vote +1 without > doing a thorough check and we may end up with more releases with issues. > > Possibly a better metric is how many mentors voted something other than +1 > on a RC, most releases (other than very simple ones) go through a couple of > RCs before coming to the IPMC. > > Another metric is which project releases get a -1 in the IPMC as those > issue should of been caught by the projects mentors. > > Thanks, > Justin > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
