> Our goal as a foundation is not to > be large, it is to be high quality.
+100 !!!!!1111oneoneone :) The problem is that sub-par technical contributions quickly lead to community issues as well. Please all ask yourself: would YOU like to contribute to a project where you have to look at every single commit someone does because they often are not of the quality you would expect from an ASF project? And imagine what the community effect is if you need to clean up after every other commit someone does. Sometimes it gets better over time, sometimes it doesn't. In any case it's very time consuming and to be a proper mentor we imo cannot just glimpse over the project but we need to dig under the skin of it. It might not be needed to know all the subtle details of the project you are mentoring. But you must at least get a feeling if something technically and community wise has a bad taste. Often this can be fixed by real mentoring (not in the ASF but in the literal sense) and sometimes we probably also need to use the emergency exit. LieGrue, strub > On Friday, 19 December 2014, 20:01, Ross Gardler (MS OPEN TECH) > <ross.gard...@microsoft.com> wrote: > > Strawman: > > What if a mentor is *required* to be an active participant of the project. > That > is contributing code, voting on releases and generally engaging with the > community, they would be a better mentor since they have a vested interest in > the project itself. Sure, we might reduce the number of projects coming into > the > foundation but (IMHO) that is not a problem. Our goal as a foundation is not > to > be large, it is to be high quality. > > Maybe we should simply scrap the idea of "mentors" and change the role > of the "champion" to one of an initial committer who will help build > an Apache project as it incubates and into being a TLP. > > We could scrap the role of shepherd and change the role of mentors. A team of > 9 > mentors would meet monthly to review *all* podlings reports (as submitted by > the > champion). Their responsibility is not to engage with the projects but to > review > the reports crafted by the champion. Any follow up actions would be taken by > a > single mentor and podlings (especially the champion) are expected to address > the > issues raised. > > If a champion's priorities change during the course of incubation then the > project must find another champion (potentially from within their own ranks) > who > is sufficiently qualified and committed to take on the responsibility. The > important thing is that the Champion is personally invested in seeing the > podling succeed and acts as a true mentor (as opposed to someone with a title > and an entry on a web page). The champion is still answerable to the podling > community. Where conflict arises within the community they can call upon the > IPMC mentoring team to ask for independent guidance. > > This model is almost identical to the way the board and TLPs work (where > Champions are roughly equivalent to PMC Chairs and mentors (nee shepherds) > are > roughly equivalent to Directors and he monthly meeting is roughly equivalent > to > the monthly board meeting to review TLP reports). I've designed it this way > (and proposed the same solution before) because it is proven to work for TLPs > and we have tooling to assist with the process. > > I look forward to the PMC tearing this strawman proposal apart and (most > importantly) suggesting alternatives and/or tweaks of value. We've been > skirting this issue for far too long. Things have improved (thanks to all who > have worked hard on this), but we have not yet solved the problem. > > Ross > > Microsoft Open Technologies, Inc. > A subsidiary of Microsoft Corporation > > -----Original Message----- > From: shaposh...@gmail.com [mailto:shaposh...@gmail.com] On Behalf Of Roman > Shaposhnik > Sent: Friday, December 19, 2014 10:11 AM > To: general@incubator.apache.org > Subject: Re: Incubator report sign-off > > Hi Rich! > > Thanks for raising this point and giving us a bit more of a forcing function > to > tackle an old problem: accountability for mentors. > > On Fri, Dec 19, 2014 at 9:10 AM, Rich Bowen <rbo...@rcbowen.com> wrote: >> I certainly don't expect that every mentor has their full attention on >> a podling every month, but I do expect that a podling that cares about >> its incubation will seek out that mentor sign-off, and that the >> mentors who have committed to help a podling into the family will have >> a few moments every few months to look in and approve a report. > > I've been thinking about this for quite some time (and trying to seek a > solution by various means) and it seems to be that we have to start from a > very > basic expectation setting. > > First of all, *my* expectation is that multiple mentors on the project are > more > of redundancy or HA consideration. IOW, my expectation that a project needs > to > have at least one active mentor at all times, but it doesn't have to be the > same person. Thus, I expect at least a signle sign-off on the report and I > don't mind if it ends up being a single one too much. > > Second biggest expectation that I have is that mentors are extension of the > IPMC, not part of the poddling. They are akin to professors or faculty > members > -- they are not part of the student body. As such we, as IPMC are accountable > to > make sure that mentors perform their duties. My expectation is that it is as > unfair to ask poddling to actively pursue mentors who are missing in action > as > it would be unfair to ask students to hire detectives to hunt down professors > who don't show up for class. What is fair, is to provide poddlings with a > semi-format feedback channel for IPMC to monitor things like mentors MIA. > > I would like to pause here and ask everybody to chime in with what they thing > are the right expectations on the above two points. > >> But I wonder if we might, as the Board does, reject reports that have >> no sign-off, and force projects to report again the following month, >> in an attempt to require them to engage with their mentor(s) a little more? > > As was pointed by John, we're already rejecting reports with no mentor > sign-off. Before we potentially take it one step further I'd like to get > clarity on the expectations first (and then I can volunteer to document that > as > well!). > > Thanks, > Roman. > > --------------------------------------------------------------------- > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
