re: How to be an awesome open source maintainer? VIEW POST

VIEW FULL DISCUSSION
 

Based on my negative experience as a contributor, here's what I'd say:

  • You must have a chatting platform (Slack/Gitter/anything) set up in advance. I hate it when maintainers only provide their email or expect all the conversations to happen on issue threads.
  • Always have a contributing guide.
  • Never let your contributing guide read "Just send a pull request!" (drives me mad!). And to be honest, I can't believe people send pull requests all the time without discussing with the maintainer first, and then they are salty when those requests aren't merged. Ego?
  • Be (very) descriptive and encouraging in your Contributing guide. Tell people that it's okay if they don't have much experience, and that you're willing to mentor them. Means a LOT to a potential contributor.
  • Have a clear plan on what you're going to do next. I absolutely loathe it when people ask for contributors to "play around and provide feedback". Really? Why? I have better things to do with my time than provide feedback on random personal projects on GitHub.
  • And like the others said, create some simple issues on your own first, provide some details, and tag them so that newcomers can build confidence.

Hope this helps in creating one less shitty maintainer! πŸ™

(I'm sorry for spitting venom, but I'm extremely frustrated with how little attention maintainers give to presenting their own projects and then expect others to pitch in with their time and energies. 😑 😑)

 

Cool, will definitely try to implement these! It's a small project from a code perspective -- does a group still make sense?

Thank you so much!

 

If it's a really small project and new contributors understand exactly what needs to be done, you won't need a chat. But still, having a dedicated live forum helps one feel that they belong to a community and can chat with them when needed. For instance, if someone needs to discuss the approach (no matter how small the task), GitHub may not be the best place to do it. Maybe you can create a group for all of your projects, if all of them are small. I'm thinking of a Slack team with different channels for each project.

I guess, finally, you're better off consulting the contributors. Don't take anything for granted. What's crystal-clear to you may not be to them. πŸ™ƒ

 

And to be honest, I can't believe people send pull requests all the time without discussing with the maintainer first, and then they are salty when those requests aren't merged.Β 

Personnaly, I always create an issue to know if the community/maintainers are agree before I start to make changes.

code of conduct - report abuse