- What constitutes a great ticket for first-time contributors?
- How do you work towards creating positive environment for contributors on your own projects?
- What common practises in OS are counter-productive to finding new contributors?
- What makes a good CONTRIBUTE.md/“get started” documentation?
- Where do you look for new contributors?
- How do you manage the time-constraints of project releases while still supporting casual contributors?
- What if a contributor starts working on something that you think might be inappropriate for their skill level/interest?
- What if a contributor accidentally duplicates work or you accidentally resolve an issue when a contributor starts working on it?
- What if a contributor submits a patch but you forget to review it/they don’t respond to comments for a long time? What’s the right way to approach getting back on track?
- How important is it to respond quickly to issues/PRs? How do you manage this with not getting distracted from your other work responsibilities?
- Any tips for using Github issues (labels, etc) effectively to encourage contribution? What makes a good mailing list? A bad one?
- Can you talk a little about contributor engagement? What do your most engaged contributors have in common? What do you do to make them happy?
- Once a contributor lands a patch, what actions can you take to encourage them stick around?
- How should product cycles/process account for contributor engagement?
- How should contributors be involved in road-mapping/planning? Can you highlight instances where this has been effective?
- In your opinion, what are some of the reasons first-time contributors don’t come back?
- What value do contributors provide you, as a project owner? What value to you get as a contributor?
- How do you encourage diversity in your contributor base? How would you like to improve?
- What are you bad at? What do you want to do better?
- What is OS bad at in general? What do we all need to do better?