I have a new project cooking. Free software, AGPL3+, Python3. What can I do to make it more accessible to would-be contributors?

· · Web · 0 · 2 · 0

Follow-up question: when should I got public with the new project? When I have an empty git repo? Or when I have a first alpha version that does anything useful at all?

@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.


Having an alpha version will provide a project core to which contributors may feel inclined to add.

At a minimum, there should be a solid description of the project's purpose, perhaps with a fundamental feature list and possible timeline.

@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:

Sign in to participate in the conversation
Mastodon @ SUNET

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!