@liw I would start with a public repository right from day one. But I would recommend not to "advertise" it before you have at least some code. Doesn't need to be in alpha state already. But if you advertise it and people get interested they should be able to find something so that they can have a look at it, try it and start contributing.

@liw I think it's important to have a public repo, bug tracker, mailing list / forum to discuss, maybe irc channel. At some point a web page. Create a welcoming atmosphere. Response to bug reports, questions on the mailing list / forum. Review pull request and ask submitter to help reviewing other pull requests. Merge them as soon as possible (don't wait for the perfect one). Give people more permissions like the right to review/merge pull requests early to make them feel part of the project.

@bjoern@liw Your advice reminds me very much of Peter Hintjens's "Collective Code Construction Contract" (C4), which is a formal methodology to foster free software communities. It is worth a read:https://rfc.zeromq.org/spec:42/C4/