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 <wander4...@gmail.com> 于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 <a...@shanecurcuru.org> 于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 >> >>
