Inline

> On Feb 16, 2024, at 10:28 AM, Rich Bowen <rbo...@rcbowen.com> wrote:
> 
> Sorry, I managed to miss the second half of your email.
> 
>> On Feb 16, 2024, at 1:12 PM, Dave Fisher <w...@apache.org> wrote:
>> 
>>> https://github.com/rbowen/comdev-working-groups/blob/main/wg-sharpeners/escallation.md
>> 
>> It’s spelled “escalation”. In addition you use the term mentors here where 
>> there are already two other roles in the foundation that use this term.
>> 
> 
> Spelling fixed. Adjust URL accordingly.
> 
>> 1. In ComDev someone helping with GSoC is called a mentor.
>> 2. In the Incubator, Podlings have Mentors.
>> 
> 
> Is that a problem? Surely mentoring is the *primary* thing that ComDev does.

I’ve seen confusion over it, but if it is clearly defined that a sharpener is a 
type of mentor then that is very fine.

> 
> 
>> So, are “sharpeners” meant to be re-mentors? Who decides if a PMC needs 
>> “sharpening”?
> 
> Everyone needs mentors at different points in their lives. Incubation is a 
> process, with an end point. Projects do not cease needing mentoring once they 
> have graduated from the Incubator.
> 
> As to who decides,  well, this is a volunteer-driven process in a 
> volunteer-driven org, so I’d say it’s entirely voluntary. As discussed in the 
> conversation with Jarek earlier today, I think there are two possible entry 
> points. Either a PMC comes to ask for help, or an individual is interested in 
> a particular project community and shows up to learn about it, and sees 
> places where they could be strengthened. In this latter case, a very useful 
> data point would be reading board reports, and noticing the frequent times 
> that projects indicate that they need a little nudge on some issue or other.

Maybe we have sharpeners that have specialities like release policy, security, 
brand, vendor relations, etc and that could help PMCs decide whose mentorship 
would help.

Best,
Dave

> 
>> 
>>> 
>>> This is proposed advice around how and when an issue should be escalated. 
>>> In summary, the main advice is, don’t. The secondary advice is, if, and 
>>> only if, a project is *persistently unwilling* to acknowledge or address a 
>>> problem, and even then, only if you’ve got another Sharpener who agrees 
>>> with your assessment, would you *privately* tell the board about your 
>>> concern, and then *drop it.*
>> 
>> The above should be in the document somehow.
> 
> I thought I had. Please do feel free to improve my phrasing.
> 
>> 
>>> I’m sincerely hoping that this kind of explicit process/advice will help to 
>>> avoid the perception which I’m seeing from more than one place that this is 
>>> just a way for people to be policemen in our projects.
>> 
>> It does help.
>> 
>> I think that there should be a section that the sharpener’s advice and/or 
>> questions of the PMC should be consolidated into singular well thought out 
>> messages and not several disjoint emails where the threads lose context.
> 
> PRs welcome, although I’m not entirely sure what you mean here.
> 
>> 
>>> 
>>> Let me know what y’all think.
>> 
>> I may provide a PR over the weekend ….
> 
> Awesome. Thanks.
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Reply via email to