+1 I like this document. I expect the way one reaches a point where they don't need the proposed document is by doing a lot of mentoring. So you can't wait until they've already done a lot of mentoring before you start them mentoring :-). It is true that the starter examples are the ones that many people have encountered and dealt with.
Personally, I think I'm at the point where I "get" many of the problem statements. I can explain the reasoning well for some, less well for others. I still often need help with approaches to improving things. So, personally, I'll benefit from it. Specific feedback: I don't think the "Values" lists are needed. I would prefer these incorporated into the prose in the "Reasoning" section. Kenn On Wed, Aug 21, 2019 at 12:08 AM Julian Hyde <jh...@apache.org> wrote: > +1 This guidance document is worth pursuing. There is plenty of criticism > of mentors on this list, it helps to have some guidelines. Thanks Justin. > > > On Aug 20, 2019, at 9:41 PM, Justin Mclean <jus...@classsoftware.com> > wrote: > > > > Hi, > > > > Sone thoughts inline. > > > >> Documentation does not solve the problem. > > > > I agree it doesn’t solve the whole problem. But it may give time poor > mentors more time to do other things if they can easily reference > collective knowledge on these issues. > > > >> If someone doesn't already "get" this stuff then they should not be > mentoring. > > > > We have had on occasion people who are mentoring who may not get this > stuff but were passionate supports of their projects, should we exclude > them? Some of this is down to inexperience, and mentoring is one of the > good ways to improve this knowledge and become a better mentor. Even if > you have gone though incubation and mentored a project before you may of > not come across the same situation and it’s not always obvious how to apply > the values, especially in case where there’s conflict between those values > (or ASF policies). > > > >> Having a document does not replace for selecting good mentors who have > the time to do the job right. > > > > 1-2 years (or more in some cases) a long commitment and life sometime > changes things, replacement mentors can’t in all cases be found, so even if > the initial condition is true, it may not be a year into teh project. > > > > I had thought of making up a mentor capability / score card to help > podlings elect mentors if they don’t already have one. But haven't > suggested it previously as it would probably be unpopular and could be used > unproductively. > > > >> It's a good effort in the broader context, but doesn't solve the > problem I see in the IPMC (insufficient high quality mentoring coupled with > too much application of rules in the process). > > > > Is that because you think don’t we have enough high quality mentors? Or > the ones we do have are spread a little too thin? Or that we have these > people but they are not mentoring projects? > > > >> How would I solve the problem? If I were championing another project > into the ASF I would carefully select mentors, just as I have in the past. > > > > Being here along time and your previous / current positions would make > it easy for to be able to get the best mentors we have that are a good fit > for the project. I’m not sure that all new incubating projects are able to > do that. > > > >> I don't mean to say the effort you are putting in is wasted effort. > Clarity in what is expected can help the podlings, > > > > Do any other mentors want to contribute to this or think it’s an idea > worth perusing? If not I’ll drop it and focus on something else. > > > >> I don't see how this can really help those people I would already trust > to be good mentors i.e. People who have a vested interest in the success of > the project and already know how to apply the Apache Way to new communities > so that they might flourish in their own way. > > > > I not sure we actually have enough mentors with those abilities and > knowledge for all of the 50 odd podlings we have or a pool of idle mentors > than new projects can select from. > > > > Thanks,. > > Justin > > --------------------------------------------------------------------- > > 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 > >
