Producing good code is a community effort. When it comes down to just the mentors fix that themselves, there is something wrong with the community of the podling.
This discussion is not about what participants do with their mentor hat on in the podling. I expect we all appreciate what mentors do within the podling and how they help out with explanation when a podling is discussed in this ML. The discussion is about people wearing two (or more) hats while mentoring a podling. And yes, the ASF should be wary of mentors pushing their podling toward graduation beyond their mentor role. Do the mentors fear podling failure (not graduating) so much, that they need a control on both the internal process of the podling (e.g. regarding graduation) and the process at IPMC level? Was the whole evalution process not intended to ensure that eyes of others than those with a vested interest (and yes graduation success can be regard as such) look and decide on the aspects of community diversity/project independence/code risk of the podling? Best regards, Pierre Smits *OFBiz Extensions Marketplace* http://oem.ofbizci.net/oci-2/ On Sun, Oct 11, 2015 at 11:48 AM, Mark Struberg <strub...@yahoo.de> wrote: > -1 > > Mentors who have no interest (financially or purely technical doesn’t > matter in the end) will not find enough time to _really_ look into the > projects health. > > Be honest with yourself: how much do you look into the code if you are not > working on it yourself? How could you then detect that code is > bulk-imported from another project (I‚ve even seen LGPLed code slip in). > And this doesn’t happen because people want us something bad. They often > simply don’t know how much the ASF cares about code provenance and legal > things. That’s an important part in the mentor work. And you cannot do this > if you are only somehow loosely checking the project every other month. > > Or do you fear a mentor will push through his own ‚baby‘ with knowingly > ignoring ASF rules? > > > LieGrue, > strub > > > > > Am 09.10.2015 um 17:07 schrieb Daniel Gruno <humbed...@apache.org>: > > > > Hi Incubator folks, > > > > I would like to propose we adopt a mentor neutrality policy for > > incubating podlings: > > > > - A mentor must not be financially tied to the project or its incubation > > status. > > - A mentor must not have a vested interest in incubating, graduating or > > dismantling a podling that goes beyond the general Apache mission > > - A mentor must not be affiliated with the entity granting the code > > (company or original project community) > > > > Furthermore, I would like to see this extended to votes on graduating or > > retiring podlings, so that only people with no organizational (aparty > > from the ASF) or financial ties to the project (or the companies behind > > it) can cast a binding vote on graduation or retirement. > > > > This would essentially mean: > > > > - If you work for a company (or are hired as consultant/advisor) that is > > entering a project into incubation, you cannot mentor it nor vote > > for/against its incubation, graduation or retirement. > > - If you are a in the original community behind the project, you cannot > > mentor it nor vote for/against it. > > > > I believe this would create a neutral mentorship whose sole mission is > > to guide podlings with the interests of the ASF in mind. > > > > > > Please do discuss this. If there is (mostly) positive feedback, I would > > like to, at some point, have a vote on including this in the Incubator > > policy. I realize this would cut down on the number of potential > > mentors, and I would ask that more people step up to the challenge of > > mentoring if adopted. > > > > With regards, > > Daniel > > > > --------------------------------------------------------------------- > > 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 > >
