> * 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
>
>

Reply via email to