Yes. We had discussion (and slack conversation) with Rich and I shared some of the same questions and possible clarifications in the docs (which I will also propose PRs for in a few days as I am pursuing Biathlon World Championships this weekend with my wife - in Czech Republic most of the time :) .
My main points (and PRs to propose) as I understand it (note that this is my interpretation and further thinkin on how I understand / would like to see Sharpener program now and likely will turn into proposals of PRs to the concept): 1) clarify that the escalation and reports are nothing exclusive to Sharpeners. The escalation described in the document linked to by Rich should happen is basically anything, any ASF member notices as a clear violation of ASF rules - and they should feel obliged to do so if they see, make comments about to the PMC and get rejected or ignored, nothing "sharpener specific". This should not be seen as a prerogative, special privilege, super-power of or anything expected from Sharpeners specifically. This is what any ASF member should do (and introducing the Sharpener concept might be a good opportunity to remind members about BTW). 2) I think one of the Goal of Sharpeners (not stated explicitly) is to make sure that all the conversation initiated around the "ASF way" should happen in the "devlist" - i.e. the place where for example Board Members looking at the project will be sure to find. This covers the cases where it's not clear. My goal here is to make sure that when Sharpener is involved in the PMC, it does not lessen the Board overlook over the project. It's still there and if Sharpener will not realise or will not interpret a behaviour as "wrong" it is still in the hands of Board members to assess the project. I think the fact that Sharpener is looking at particular PMC should be noted somewhere - so that - for example - Board member who wants to review the project at regular review could see at the history of devlist conversations which Sharpener started or took part in (simple filter in ponymail) and will be able to assess on their own if the PMC needs any action and discussion at the Board level Why the above? [I think the 2 points above combined are a great way to make the Board Member's work way easier when reviewing projects, without delegating the responsibility to the Sharpener to do such a review]. IMHO the job of Sharpeners is to help and disseminate Apache Way, but not to take responsibility for the project's conformance and deciding on thresholds where board action is required (except some obvious cases as outlined in the escalation document - but this is a regular Member obligation anyway, not Sharpener in particular, so this is mostly a different bucket altogether). 3) I also think that indeed - there are those two modes the relationship PMC <> Sharpener starts (and yes I also plan to do PR on that, because I do think it needs to be very explicit to explain in the program, how the relationship starts): * PMC asks for help when they struggle (or when the board encourages them to do so). This requires likely to recruit a number of "potential sharpeners" with listing their interest and willingness to help but IMHO it also needs a lot of advertising of the whole concept. Very similar case was with https://whimsy.apache.org/members/mentors - which had a very similar goal but no-one knows about. And we should learn from that program - i..e. we as a working group should have a goal to make the program known to PMCs and idea how to do it if we want this part to be successful. I have few ideas about it, but it very much depends on the final shape of the whole program, because there might be different incentives we might think of and different communication mechanisms that can be used to both - market this among the PMCs. * Sharpener asks if they can join the project as Sharpener - which might be driven by personal interest, existing relationships with the people in the project or just a genuine need to do "good thing" and spread the things you believe in in projects that you think might need it (there might be other reasons as well - I can imagine Sharpeners might do it for example because they think it's good to learn something about the project and this might be a cool opportunity to start getting involved), or because they want to share things they've done to follow "Apache Way" and they see that experience might be replicated in another project (AKA "lead by example"). Here again I think a lot depends on the final shape of the program (including the potential incentives and target group of Sharpeners the program should have). I think we should also be quite explicit how those relations are NOT set. For example it should never be that the Board should ask a potential Sharpener to become one for a specific project because they need someone there (or at least I think it's not and should never be the purpose of the program). Maybe that's implicit, but I think it's worth spelling out that it's either the PMC asking the sharpener for help or the Sharpener does it because they feel a genuine need to do it. But I think we should put a guardrail in place to make sure that this program will not turn into a way to delegate the "project oversight" by the Board to Sharpeners (unless of course it is the purpose of the program and then it should be explicitly stated in it - to make sure that Sharpeners know what they are signing up for). I think even if it does not start this way, there is a potential risk that Sharpeners might be treated as potential solution to the problem "Hey we have a problem with this project, let's put a Sharpener on it" - I think it's worth spelling out, that this is not the intention of the program. J On Fri, Feb 16, 2024 at 8:06 PM Dave Fisher <w...@apache.org> wrote: > 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 > >
