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 <rbo...@rcbowen.com> 于2024年3月29日周五 22:24写道： > On Mar 29, 2024, at 10:20 AM, Michael Sokolov <msoko...@gmail.com> 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 <rbo...@rcbowen.com> 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 > >
