Hi - Sorry for my top post, but I have some observations about your “guide”.
(1) It is more a mentoring FAQ than a guide. (2) You are listing symptoms / policy violations. (3) It would be better to discuss what community problem is causing the particular issue instead of putting the blame on poor mentoring. I’m overstating a little but I think this FAQ should tie back to solution using the Apache Way of Governance. (A) Consensus Decision Making on a public dev@/general@ Mailing List. (B) Community Growth is Recognizing all people providing value to the project as being committed to the project. Trust these people. (C) Release Open Source Software following Apache Release and Distribution Policies. (D) Brand compliance. If a project does those things then things are good. Regards, Dave Sent from my iPhone > 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
