Re: Getting a project back on track
Hi Rich That's a fair comment. We can also take the example of Livy that we were able to "restart" thanks to new contributors. Call For Action can also work (as we did for a few projects), especially when the project is in use. Regards JB On Fri, Mar 29, 2024 at 2:35 PM Rich Bowen wrote: > > This week, I’ve been approached by someone concerned about one of our > projects, and looking for a “how to get back on track” document, with > concrete, actionable steps that a project can take when it is struggling to > find contributors. This seems like a great doc that we should write. What > comes to mind is: > > * Clearly tell the dev@ and user@ list that the project is at risk if they > don’t step up > * Publish a list of open issues to the Dev list > * Contact companies that you know rely on your outputs, and tell them that > the project is at risk > * Clearly document the path/requirements for getting committer. Consider > lowering your wall a little > * What else? > > Another question that I have is where to put this doc. I’m thinking it goes > in https://github.com/apache/comdev-site/tree/main/source/pmc somewhere, but > I’m not sure that to name it. > > > > — > Rich Bowen > rbo...@rcbowen.com > > > > - To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
Re: Getting a project back on track
Thanks, folks. I’ve opened a PR with the feedback from this thread - https://github.com/apache/comdev-site/pull/174 - and would appreciate a review, and if you think it passes muster, a merge. Thanks. > On Mar 29, 2024, at 9:35 AM, Rich Bowen wrote: > > This week, I’ve been approached by someone concerned about one of our > projects, and looking for a “how to get back on track” document, with > concrete, actionable steps that a project can take when it is struggling to > find contributors. This seems like a great doc that we should write. What > comes to mind is: > > * Clearly tell the dev@ and user@ list that the project is at risk if they > don’t step up > * Publish a list of open issues to the Dev list > * Contact companies that you know rely on your outputs, and tell them that > the project is at risk > * Clearly document the path/requirements for getting committer. Consider > lowering your wall a little > * What else? > > Another question that I have is where to put this doc. I’m thinking it goes > in https://github.com/apache/comdev-site/tree/main/source/pmc somewhere, but > I’m not sure that to name it. > > > > — > Rich Bowen > rbo...@rcbowen.com > > > >
Re: Getting a project back on track
A common mistake for leveraging the power of community is to make it complicated ”what is suitable for newcomers". Working in many OSS projects, I practice and encourage other maintainers to practice: Do not think "community" as an external resource and you need to feed them. We're part of the community and the evolution of the project is made by the community. So, your roadmap, your to-dos, no matter how hard or easy, but only if it's clear to do or investigate the next step, keep it open. Take over what you're motivated to do now, and leave the others you want to achieve (and thus valuable). With a few propagation actions, hackers/enthusiasts would help, as long as the project provides value and is implemented in a way they like. Best, tison. tison 于2024年3月29日周五 22:54写道： > > * Roadmap - > > a sense of new things that they could help build > > a sense the project is still going someplace > > +1 This is what I advise the StreamPark podling every time I meet its > "original author". He shares the challenges that he "cannot find many peers > to collaborate with." > > I told him, "Where this project would go is in your mind, and you seldom > speak it out. How can you expect others to spend much time on a project > "not theirs" and figure out what they can do?" > > So here is a roadmap this year [1] while I may doubt it's still too > abstract to catch up by other community members not dedicated as his level. > > Sorry, I may not be a theorist; just share stories that may help. > > Best, > tison. > > [1] https://lists.apache.org/thread/k9tk3jlq55ft4ovcgxjv2g6p8bo6qqgl > > > Shane Curcuru 于2024年3月29日周五 22:39写道： > >> Rich Bowen wrote on 3/29/24 9:35 AM: >> > This week, I’ve been approached by someone concerned about one of our >> projects, and looking for a “how to get back on track” document, with >> concrete, actionable steps that a project can take when it is struggling to >> find contributors. This seems like a great doc that we should write. What >> comes to mind is: >> > >> > * Clearly tell the dev@ and user@ list that the project is at risk if >> they don’t step up >> > * Publish a list of open issues to the Dev list >> > * Contact companies that you know rely on your outputs, and tell them >> that the project is at risk >> > * Clearly document the path/requirements for getting committer. >> Consider lowering your wall a little >> > * What else? >> >> * Roadmap - consider publishing a roadmap of what >> features/ideas/improvements to build/docs/etc the project wants to >> implement. Give contributors a sense of new things that they could help >> build, and a sense the project is still going someplace. >> >> * Double-check your "how to contribute / build / test / submit PR" >> documentation is super clear and easy to follow. Long-time committers >> on a project often forget all the institutional knowledge they just >> "know", so ensuring the "getting started" document actually works for >> newcomers is always worth looking at. >> >> > Another question that I have is where to put this doc. I’m thinking it >> goes in https://github.com/apache/comdev-site/tree/main/source/pmc >> somewhere, but I’m not sure that to name it. >> >> Yes - primarily advice to PMCs (or active committers). There are two >> potential primary audiences: >> >> - PMCs that can't find new committers, and ask for help. >> >> - PMCs who might want to regularly self-review how they're working, to >> see if they can improve things for new contributors. >> >> It's kinda "How to encourage new contributors to turn into committers"? >> >> -- >> - Shane >>Member >>The Apache Software Foundation >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org >> For additional commands, e-mail: dev-h...@community.apache.org >> >>
Re: Getting a project back on track
> * Roadmap - > a sense of new things that they could help build > a sense the project is still going someplace +1 This is what I advise the StreamPark podling every time I meet its "original author". He shares the challenges that he "cannot find many peers to collaborate with." I told him, "Where this project would go is in your mind, and you seldom speak it out. How can you expect others to spend much time on a project "not theirs" and figure out what they can do?" So here is a roadmap this year [1] while I may doubt it's still too abstract to catch up by other community members not dedicated as his level. Sorry, I may not be a theorist; just share stories that may help. Best, tison. [1] https://lists.apache.org/thread/k9tk3jlq55ft4ovcgxjv2g6p8bo6qqgl Shane Curcuru 于2024年3月29日周五 22:39写道： > Rich Bowen wrote on 3/29/24 9:35 AM: > > This week, I’ve been approached by someone concerned about one of our > projects, and looking for a “how to get back on track” document, with > concrete, actionable steps that a project can take when it is struggling to > find contributors. This seems like a great doc that we should write. What > comes to mind is: > > > > * Clearly tell the dev@ and user@ list that the project is at risk if > they don’t step up > > * Publish a list of open issues to the Dev list > > * Contact companies that you know rely on your outputs, and tell them > that the project is at risk > > * Clearly document the path/requirements for getting committer. Consider > lowering your wall a little > > * What else? > > * Roadmap - consider publishing a roadmap of what > features/ideas/improvements to build/docs/etc the project wants to > implement. Give contributors a sense of new things that they could help > build, and a sense the project is still going someplace. > > * Double-check your "how to contribute / build / test / submit PR" > documentation is super clear and easy to follow. Long-time committers > on a project often forget all the institutional knowledge they just > "know", so ensuring the "getting started" document actually works for > newcomers is always worth looking at. > > > Another question that I have is where to put this doc. I’m thinking it > goes in https://github.com/apache/comdev-site/tree/main/source/pmc > somewhere, but I’m not sure that to name it. > > Yes - primarily advice to PMCs (or active committers). There are two > potential primary audiences: > > - PMCs that can't find new committers, and ask for help. > > - PMCs who might want to regularly self-review how they're working, to > see if they can improve things for new contributors. > > It's kinda "How to encourage new contributors to turn into committers"? > > -- > - Shane >Member >The Apache Software Foundation > > > - > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org > For additional commands, e-mail: dev-h...@community.apache.org > >
Re: Getting a project back on track
Rich Bowen wrote on 3/29/24 9:35 AM: This week, I’ve been approached by someone concerned about one of our projects, and looking for a “how to get back on track” document, with concrete, actionable steps that a project can take when it is struggling to find contributors. This seems like a great doc that we should write. What comes to mind is: * Clearly tell the dev@ and user@ list that the project is at risk if they don’t step up * Publish a list of open issues to the Dev list * Contact companies that you know rely on your outputs, and tell them that the project is at risk * Clearly document the path/requirements for getting committer. Consider lowering your wall a little * What else? * Roadmap - consider publishing a roadmap of what features/ideas/improvements to build/docs/etc the project wants to implement. Give contributors a sense of new things that they could help build, and a sense the project is still going someplace. * Double-check your "how to contribute / build / test / submit PR" documentation is super clear and easy to follow. Long-time committers on a project often forget all the institutional knowledge they just "know", so ensuring the "getting started" document actually works for newcomers is always worth looking at. Another question that I have is where to put this doc. I’m thinking it goes in https://github.com/apache/comdev-site/tree/main/source/pmc somewhere, but I’m not sure that to name it. Yes - primarily advice to PMCs (or active committers). There are two potential primary audiences: - PMCs that can't find new committers, and ask for help. - PMCs who might want to regularly self-review how they're working, to see if they can improve things for new contributors. It's kinda "How to encourage new contributors to turn into committers"? -- - Shane Member The Apache Software Foundation - To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
Re: Getting a project back on track
This is why we emphasize community over code. And Kvrocks can be a valuable example that although quite a few of its "original authors" faded away due to many reasons, we keep invite new members and due to its product value (a well-known software's alternative, named Redis), so it can be maintained as long as a few of code reviewers are there. The latter is also why sometimes I bring back "code"'s value cause we build specific SOFTWARE/PROJECT communities. The product value holds to keep attracting new comers. > how to get back on track Back to the question. Another important distinction I'd like to make is * whether this question is asked by the current PMC; or, * by someone who may want to take over/contribute to the project and reactivate it. Best, tison. Rich Bowen 于2024年3月29日周五 22:24写道： > On Mar 29, 2024, at 10:20 AM, Michael Sokolov wrote: > > > > I guess it depends on what the problem with the project is. It seems > > implicit in your ideas that the project has lost momentum; nobody is > > contributing to it or maintaining it actively? But I just want to > > point out there can be other problems that might need correction with > > different solutions (too much chaos, fighting, legal issues, poor > > quality releases, etc) > > > > > Yes, those things seem useful to address also. > > The most common problem we see in ASF projects is that they just wind down > and lose steam, and end up being one or two people trying to keep the > lights on, with no time to go out and find helpers. > > > > > On Fri, Mar 29, 2024 at 9:36 AM Rich Bowen wrote: > >> > >> This week, I’ve been approached by someone concerned about one of our > projects, and looking for a “how to get back on track” document, with > concrete, actionable steps that a project can take when it is struggling to > find contributors. This seems like a great doc that we should write. What > comes to mind is: > >> > >> * Clearly tell the dev@ and user@ list that the project is at risk if > they don’t step up > >> * Publish a list of open issues to the Dev list > >> * Contact companies that you know rely on your outputs, and tell them > that the project is at risk > >> * Clearly document the path/requirements for getting committer. > Consider lowering your wall a little > >> * What else? > >> > >> Another question that I have is where to put this doc. I’m thinking it > goes in https://github.com/apache/comdev-site/tree/main/source/pmc > somewhere, but I’m not sure that to name it. > >> > >> > >> > >> — > >> Rich Bowen > >> rbo...@rcbowen.com > >> > >> > >> > >> > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org > > For additional commands, e-mail: dev-h...@community.apache.org > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org > For additional commands, e-mail: dev-h...@community.apache.org > >
Re: Getting a project back on track
I can share two examples: * Livy podling. Users take over the community. * Ambari. Vendors/Individual Devs revived the community. But both of them don't seem to be quite active (again). Best, tison. Michael Sokolov 于2024年3月29日周五 22:21写道： > I guess it depends on what the problem with the project is. It seems > implicit in your ideas that the project has lost momentum; nobody is > contributing to it or maintaining it actively? But I just want to > point out there can be other problems that might need correction with > different solutions (too much chaos, fighting, legal issues, poor > quality releases, etc) > > On Fri, Mar 29, 2024 at 9:36 AM Rich Bowen wrote: > > > > This week, I’ve been approached by someone concerned about one of our > projects, and looking for a “how to get back on track” document, with > concrete, actionable steps that a project can take when it is struggling to > find contributors. This seems like a great doc that we should write. What > comes to mind is: > > > > * Clearly tell the dev@ and user@ list that the project is at risk if > they don’t step up > > * Publish a list of open issues to the Dev list > > * Contact companies that you know rely on your outputs, and tell them > that the project is at risk > > * Clearly document the path/requirements for getting committer. Consider > lowering your wall a little > > * What else? > > > > Another question that I have is where to put this doc. I’m thinking it > goes in https://github.com/apache/comdev-site/tree/main/source/pmc > somewhere, but I’m not sure that to name it. > > > > > > > > — > > Rich Bowen > > rbo...@rcbowen.com > > > > > > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org > For additional commands, e-mail: dev-h...@community.apache.org > >
Re: Getting a project back on track
On Mar 29, 2024, at 10:20 AM, Michael Sokolov wrote: > > I guess it depends on what the problem with the project is. It seems > implicit in your ideas that the project has lost momentum; nobody is > contributing to it or maintaining it actively? But I just want to > point out there can be other problems that might need correction with > different solutions (too much chaos, fighting, legal issues, poor > quality releases, etc) > Yes, those things seem useful to address also. The most common problem we see in ASF projects is that they just wind down and lose steam, and end up being one or two people trying to keep the lights on, with no time to go out and find helpers. > On Fri, Mar 29, 2024 at 9:36 AM Rich Bowen wrote: >> >> This week, I’ve been approached by someone concerned about one of our >> projects, and looking for a “how to get back on track” document, with >> concrete, actionable steps that a project can take when it is struggling to >> find contributors. This seems like a great doc that we should write. What >> comes to mind is: >> >> * Clearly tell the dev@ and user@ list that the project is at risk if they >> don’t step up >> * Publish a list of open issues to the Dev list >> * Contact companies that you know rely on your outputs, and tell them that >> the project is at risk >> * Clearly document the path/requirements for getting committer. Consider >> lowering your wall a little >> * What else? >> >> Another question that I have is where to put this doc. I’m thinking it goes >> in https://github.com/apache/comdev-site/tree/main/source/pmc somewhere, but >> I’m not sure that to name it. >> >> >> >> — >> Rich Bowen >> rbo...@rcbowen.com >> >> >> >> > > - > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org > For additional commands, e-mail: dev-h...@community.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
Re: Getting a project back on track
I guess it depends on what the problem with the project is. It seems implicit in your ideas that the project has lost momentum; nobody is contributing to it or maintaining it actively? But I just want to point out there can be other problems that might need correction with different solutions (too much chaos, fighting, legal issues, poor quality releases, etc) On Fri, Mar 29, 2024 at 9:36 AM Rich Bowen wrote: > > This week, I’ve been approached by someone concerned about one of our > projects, and looking for a “how to get back on track” document, with > concrete, actionable steps that a project can take when it is struggling to > find contributors. This seems like a great doc that we should write. What > comes to mind is: > > * Clearly tell the dev@ and user@ list that the project is at risk if they > don’t step up > * Publish a list of open issues to the Dev list > * Contact companies that you know rely on your outputs, and tell them that > the project is at risk > * Clearly document the path/requirements for getting committer. Consider > lowering your wall a little > * What else? > > Another question that I have is where to put this doc. I’m thinking it goes > in https://github.com/apache/comdev-site/tree/main/source/pmc somewhere, but > I’m not sure that to name it. > > > > — > Rich Bowen > rbo...@rcbowen.com > > > > - To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
Getting a project back on track
This week, I’ve been approached by someone concerned about one of our projects, and looking for a “how to get back on track” document, with concrete, actionable steps that a project can take when it is struggling to find contributors. This seems like a great doc that we should write. What comes to mind is: * Clearly tell the dev@ and user@ list that the project is at risk if they don’t step up * Publish a list of open issues to the Dev list * Contact companies that you know rely on your outputs, and tell them that the project is at risk * Clearly document the path/requirements for getting committer. Consider lowering your wall a little * What else? Another question that I have is where to put this doc. I’m thinking it goes in https://github.com/apache/comdev-site/tree/main/source/pmc somewhere, but I’m not sure that to name it. — Rich Bowen rbo...@rcbowen.com
