Re: [WG: Sharpeners] Proposed: Escalation advice
Inline > On Feb 16, 2024, at 10:28 AM, Rich Bowen wrote: > > Sorry, I managed to miss the second half of your email. > >> On Feb 16, 2024, at 1:12 PM, Dave Fisher 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
Re: [WG: Sharpeners] Proposed: Escalation advice
Sorry, I managed to miss the second half of your email. > On Feb 16, 2024, at 1:12 PM, Dave Fisher 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. > 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. > >> >> 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.
Re: [WG: Sharpeners] Proposed: Escalation advice
> On Feb 16, 2024, at 1:12 PM, Dave Fisher wrote: > > I have a couple of overarching comments. > > A. Why “Sharpener”? I don’t really want to bike shed the name, but here are > definitions: > > 1. a device or tool for making something sharper, esp. pencils or knives: > 2. (Slang) An alcoholic drink taken at the start of the day, or just before > a meal. I’ve never heard #2, but, ok. This question is directly addressed in the README: - ### Why "Sharpener" Because I wanted an "sh" word, to go along with Shepherds and Shadows, which I'll be writing about elsewhere. "As iron sharpens iron, so one person sharpens another.” —— We already have Shepherds. I will be proposing a Shadow concept soon - still writing that up. Alliteration is cool. > > I see you like the “sh” which can reinforce “shhh” as in confidential. Well, ok, but, no, I hadn’t thought of that. > > B. Is this process within the remit given to ComDev by the board? The board explicitly asked us to develop this concept, back in June: https://lists.apache.org/thread/4fswg0t0q5vthztc7gpfj4snc1ol2jxn Granted, I was the one that wrote that proposal, but it was at the direction of the whole board, and was approved by the whole board. So, yes.
Re: [WG: Sharpeners] Proposed: Escalation advice
I have a couple of overarching comments. A. Why “Sharpener”? I don’t really want to bike shed the name, but here are definitions: 1. a device or tool for making something sharper, esp. pencils or knives: 2. (Slang) An alcoholic drink taken at the start of the day, or just before a meal. I see you like the “sh” which can reinforce “shhh” as in confidential. B. Is this process within the remit given to ComDev by the board? > On Feb 16, 2024, at 8:50 AM, Rich Bowen wrote: > > I wrote a (proposed) thing: > > 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. 1. In ComDev someone helping with GSoC is called a mentor. 2. In the Incubator, Podlings have Mentors. So, are “sharpeners” meant to be re-mentors? Who decides if a PMC needs “sharpening”? > > 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’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. > > Let me know what y’all think. I may provide a PR over the weekend …. Thanks, Dave > > — > Rich Bowen > rbo...@rcbowen.com > - To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
[WG: Sharpeners] Proposed: Escalation advice
I wrote a (proposed) thing: https://github.com/rbowen/comdev-working-groups/blob/main/wg-sharpeners/escallation.md 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.* 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. Let me know what y’all think. — Rich Bowen rbo...@rcbowen.com
[PR] Add some specific recommendations of how we might address these situa… [comdev-working-groups]
rbowen opened a new pull request, #7: URL: https://github.com/apache/comdev-working-groups/pull/7 …tions. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
Re: [PR] Fixed the formate issues of the wg members [comdev-working-groups]
rbowen merged PR #6: URL: https://github.com/apache/comdev-working-groups/pull/6 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
Re: [jira] [Commented] (COMDEV-543) Sharpeners use cases
Bit of a long message here, but that’s because I’m trying to address your many disparate points. Jarek, I am sensing TWO things in your message. 1) You are concerned that we are instituting a police state 2) You have a subtly different understanding of what it is that I’m trying to do here than I do. I’d like you to notice, explicitly, that every single one of the working groups I have proposed has this in common: It is not creating a new activity. It is, rather, putting structure around something that we are already doing, specifically so that it will encourage more people to do it. Structure helps some people have the courage to get involved. Sharpening, for example - you are already doing it. I am already doing it, very intentionally, in several different projects, although we don’t call it that. This working group intends to create consistency and best practice, so that more people will do it. That’s all. > On Feb 15, 2024, at 6:39 PM, Jarek Potiuk wrote: > > So far - I think, maybe I missed it as I was focused on some > security/Airflow issues I had been deeply involved with - there was no > discussion on how and when and initiated by whom a Sharpener chooses to > join the PMC and what is the relation of PMC - Sharpener - Board and > whether and how Board is involved in the process. Who and when originates > sharpener joins the project is not (or I could not find.it) defined. I am > not sure what was the intention (both to start with and what it might turn > into in the future for that part of the relation, but here is what I think > about it. People who are interested in a project, and helping it out, can go become part of that project. That’s how it’s always been. Nobody is *ever* assigned a project to go get involved in, and this program would not create any such assignments. That would be contrary to how we do things at Apache. The Board is not involved in this at all, and would never be. > > Proposed solutions (at least this would be the Sharpeners I'd gladly join): > > * Sharpeners should be a group of people who should be ready to join PMCs > to help them but not proactively choose projects and not (God forbid) be > assigned by the Board to some projects Today, individuals choose project to go get involved in. That’s how you got involved in the projects that you work on. The Board has no say in what projects you or I are involved in. Nothing in this working group proposal changes that. It merely creates tools and structure around what we’re already doing. Again so that more people will feel empowered/permitted to do it. > > * Sharpeners **might** if they want, offer their help to the PMCs directly > if they happen to or stumble upon the notion that project might struggle > with something (various ways, but not directed, nor asked by the Board) - > especially when Sharpener has some relationship with the project / PMC / > people (but no corporate interest/ allegiance etc. ). But this should be > accidental, purely based on existing relations and serendipity of other > conversations happening. I am completely unclear what you’re proposing here. Accidental? People get involved in projects because they’re interested in the project. Nobody is assigned a project to work on. We are a volunteer organization. Maybe you can explain what risk you’re trying to avoid here? > > * The initiative to reach out to Sharpeners should come from the PMC - > almost exclusively. The board (with regular project review) might suggest > to the PMC that they consider choosing /asking for Sharpener to help them, > it should also be advertised and reminded regularly - possibly as part of > reminding about reports, that PMCs can reach out if they feel they need > help. And they should be able to choose the person from Sharpener's group > who is available to help and whom they can trust. Well, ok, sure, I could see a PMC approaching ComDev and saying “can someone help us?” That already happens. But, also, I can see an individual getting on a PMC mailing list because they see something that they think needs help. That’s how we do things today. It’s the nature of my involvement in every Apache project I’m currently involved in. Again, I’m unclear what risk you’re trying to avoid. Please remember that this working group is NOT a board project. It’s a working group of peers. > > * We should aim to have quite a significant number of Sharpeners from > various cultures and backgrounds. so that there is a high chance if PMC > struggles, they will find a sharpener they know about or had interacted > with in the past and they can trust they can cooperate and get useful > relationships there. Sure, ideally, we aim for that kind of diversity in everything we do. > > * most important - Sharpeners should **NEVER** report anything to the board > - it should be neither expected nor even hinted they could. Creating a > special place for them where they could do it is a BIG HAIRY NO for me.
Re: Update Website Template (WAS: Help to get the Wayang project website in shape)
+1 for providing some modern templates for the incubating projects. Cheers, Willem Jiang On Sun, Feb 11, 2024 at 1:26 PM tison wrote: > > I've pushed the code to 'docusarus' branch on this repo, and file a > ticket on INFRA [1] to ask for some privileges actions. > > Best, > tison. > > [1] https://issues.apache.org/jira/browse/INFRA-25486 > > tison 于2024年2月10日周六 18:32写道： > > > > It seems that the repo is foundation-wise that I have the permission to > > move forward this effort. > > > > I'll push the branch and update the README. And then ask for INFRA to make > > it the default branch, as well as setting the repo as a repo template. > > > > I believe comdev and the Incubator are related to these actions so I post > > here for visibility, and welcome any feedback if you second this or have > > suggestions. > > > > Best, > > tison. > > > > > > tison 于2024年2月4日 周日23:16写道： > >> > >> Hi, > >> > >> I finally find some time to prepare a demo for the new website template > >> [1]. > >> > >> It may still open to be improved including a download page template > >> and a community page template, as well as some guides as its docs. But > >> I'd like to first collecting feedback and finding which PMC is > >> responsible for this repository [2]. > >> > >> The background is that our current template is quite old and not > >> updated for the past six years. Few people understand those techniques > >> and have a hard time to build their own site. Also, new policy > >> compliance and new techniques benefits can be included in the template > >> to help new projects (podlings) build a wonderful site. > >> > >> I'm glad to maintain this repo but I find myself has no permission > >> over this repo. So again, which PMC is responsible for this > >> repository? > >> > >> Best, > >> tison. > >> > >> [1] https://github.com/tisonkun/apache-website-template/tree/docusaurus > >> [2] https://github.com/apache/apache-website-template/ > >> > >> Alex Porcelli 于2024年1月30日周二 04:53写道： > >> > > >> > Another shout-out for tison and the Apache Fury to provide such a nice > >> > starting point for new websites. > >> > > >> > I managed to put, for now, a simple placeholder website for Apache KIE > >> > (incubation). > >> > > >> > Thank you tison and the Apache Fury community! > >> > > >> > On Fri, Jan 26, 2024 at 4:10 AM Xuanwo wrote: > >> > > > >> > > > I managed to move our old website to Docusaurus in one day - using > >> > > > the template > >> > > > structure from Fury, if you don’t mind. > >> > > > >> > > Congrats! > >> > > > >> > > On Fri, Jan 26, 2024, at 17:07, Alexander Alten-Lorenz wrote: > >> > > > Hey tison, > >> > > > > >> > > > Thank you for the head-up. I managed to move our old website to > >> > > > Docusaurus in one day - using the template structure from Fury, if > >> > > > you > >> > > > don’t mind. Awesome stuff, would love when we’d had a template for > >> > > > the > >> > > > podlings to setup a good looking, SEO friendly project page. That’s > >> > > > needed to grow the community! > >> > > > > >> > > > Cheers, thanks again, > >> > > > —Alex > >> > > > > >> > > >> On Jan 25, 2024, at 12:01, tison wrote: > >> > > >> > >> > > >> Hi Alexander, > >> > > >> > >> > > >> I use Docusaurus for Kvrocks and Fury. Their configuration should be > >> > > >> straightforward to follow already. The most simple one now is > >> > > >> https://github.com/apache/incubator-fury-site. > >> > > >> > >> > > >> Also, Docu is well-documented https://docusaurus.io/docs. > >> > > >> > >> > > >> I'm thinking of updating the website template [1] with Docu but have > >> > > >> not yet had time and understand which PMC manages this project. > >> > > >> > >> > > >> Best, > >> > > >> tison. > >> > > >> > >> > > >> [1] https://github.com/apache/apache-website-template > >> > > >> > >> > > >> Alexander Alten-Lorenz 于2024年1月25日周四 > >> > > >> 18:20写道： > >> > > >>> > >> > > >>> Hi Xuanwo, > >> > > >>> > >> > > >>> Thank you, highly appreciated! Do you have any how-to for setting > >> > > >>> Docusaurus up? > >> > > >>> > >> > > >>> —Alex > >> > > >>> > >> > > On Jan 25, 2024, at 11:01, Xuanwo wrote: > >> > > > >> > > Hi, alexander > >> > > > >> > > > We aren't web designers and we would love to find helping hands > >> > > > to get > >> > > > the page in order, including re-organizing and rewriting. > >> > > > >> > > I'm with the OpenDAL Community, and we also lack web designers. > >> > > Our community > >> > > opted for Docusaurus[1], which we found easy to start with and > >> > > set up. It > >> > > offers a decent theme suitable for open-source projects. For > >> > > reference, you > >> > > can check out OpenDAL's homepage[2]. We hope our experience > >> > > proves useful. > >> > > > >> > > [1] https://docusaurus.io/ > >> > > [2] https://opendal.apache.org/ > >> > > > >> > > On Thu, Jan 25, 2024, at 16:26, Alexander Alten wrote: > >
