incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Fisher <>
Subject Re: [MENTORS] Mentor guidance document
Date Thu, 22 Aug 2019 05:12:45 GMT
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.


Sent from my iPhone

> On Aug 20, 2019, at 9:41 PM, Justin Mclean <> 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
>> 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:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message