I will just note that I disagree with adding bureaucracy like this. We already require podlings to submit reports as frequently as monthly. (Geode somehow had to report monthly for no discernible reason.)
This further adds to the burden on being a mentor - probably to something like being a teacher enforcing a pedagogical structure on the podlings. I don't think that is what we should be striving for. For the two podlings I currently mentor (Geode and HAWQ), I keep an eye on the mailing lists and try to ensure that any process questions that are raised are addressed. In the early days of Geode, there was a bit of that - less so now as the community is finding its way. HAWQ seems to be doing well - nothing surprising that I can tell so far. I believe in a "big tent" foundation - we should welcome new projects of any stripe. If they fail within the Incubator to graduate, so be it. But, that is separate from asking the mentors to somehow be "responsible" for the podlings. I have an interest to see them succeed, but if it doesn't, *shrug* and we move on. I don't see any value in adding more bureaucracy as it will further sap any motivation to truly "mentor" projects. I view the mentor as someone that can be called upon, but doesn't necessarily require active involvement on a daily basis. If I wanted that, I would be a committer to the project. Let's not confuse the two. My $.02. -- justin On Mon, Oct 12, 2015 at 7:18 AM, Rich Bowen <rbo...@rcbowen.com> wrote: > Fellow mentors, > > There was a conversation at ApacheCon about the Incubator. I'll leave it to > the other participants to champion the particular parts that they are > passionate about, but I was particularly concerned with mentor > disengagement, and suggestions for improving it. > > A mentor's role is to help a project learn the ropes at the ASF, and that > mentor might not necessarily be deeply versed in the particular technology > that the podling works with. As such, it can frequently be the case that the > mentor becomes disengaged from the daily conversation of the lists, and > eventually with the entire process. > > As a means of refocusing the mentors' efforts, and keeping them engaged, I'd > like to encourage each mentor (or group of mentors) to consider writing a > running report (ie, evolving, updated every quarter) based on > https://community.apache.org/apache-way/apache-project-maturity-model.html > where they evaluate each point on the maturity model, as a path towards > graduation. This gives a concrete target, and a lens through which to view > the podling's progress towards that target. > > This could be kept in the incubator wiki, and linked from the official > project report, or it could be maintained just for your own benefit. I think > it would be particularly useful to attach to a graduation recommendation, as > a sign that the recommendation is more than just checking the various boxes, > but is a glowing endorsement of the project's readiness to be TLP. > > As a side-note, I'd also encourage mentors who are mentors in name only, and > not reality, to consider cleaning up the paperwork by removing themselves > from the roster. It doesn't look great when a podling can't get mentor > signoff on their reports. > > -- > Rich Bowen - rbo...@rcbowen.com - @rbowen > http://apachecon.com/ - @apachecon > > --------------------------------------------------------------------- > 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
