Working on Open Source absolutely requires individual contributors to be self-starting. New contributors who lack drive require constant direction and/or hand-holding, undermining the time/effort commitment of existing contributors.
Most Open Source projects invest a lot of time/effort coaching new contributors. If a new contributor receives the coaching but doesn't produce anything useful; it's a net loss for the project, users, and community.
I always tell people who want to start contributing to OSS to start with simple/easy tasks like documentation updates. It minimizes the negative impact of poor quality contributions and allows existing devs to identify and correct workflow inconsistencies during peer review.
The other growing pain is new contributors who bring their 'ideas' but put zero effort toward contributing. 'Ideas' are like assholes, meaning everybody has one. They're not particularly useful unless there's a person ready/willing to implement them. Even then, a new idea may not follow the intent of the project and/or its culture.
Endlessly discussing the 'future possibilities' of a project is extremely counterproductive and distracting to existing developers.
I have somewhat different perspectives on "ideas". People discuss ideas first because if they do the implementation first, there is a large risk of wasted effort because it "may not follow the intent of the project". Discussion is in part effort to divine the intent of the project.
As a concrete example, I implemented break and continue for OCaml compiler because having for loop without break/continue seems to me obviously a bad idea. Although I learned a lot about OCaml compiler internals, this went nowhere. I learned my lesson, and now I will certainly "endlessly discuss" possibilities of break/continue first, without writing a single line of code. In my opinion, berating people for this is placing undue burden on contributors.
An idea followed by an implementation is awesome and exactly what OSS projects need from contributors.
"I learned my lesson..."
I read the mailing list and don't see how that was a negative experience. Only one of the contributors had an unfavorable response.
Even if they don't implement your code as-is, it looks like you had a good idea including a good implementation that led to a lot of productive discussion.
Only one of the contributors had a strong objection and despite that, the conversation continued.
Don't take it personal if your code isn't directly incorporated into a project. Despite that, your contribution led to further discussion and helped better focus the intent of the project.
Working on an OSS project is very much about collaboration. Code contributions may not always be incorporated into the codebase, especially on projects like ocaml that have a specific focus and changes have far-reaching impacts on the userbase.
:cringe: Apparently I, need to expand the comment text field and re-read my comments before posting. Hopefully, you could infer my meaning from the word vomit.
Working on Open Source absolutely requires individual contributors to be self-starting. New contributors who lack drive require constant direction and/or hand-holding, undermining the time/effort commitment of existing contributors.
Most Open Source projects invest a lot of time/effort coaching new contributors. If a new contributor receives the coaching but doesn't produce anything useful; it's a net loss for the project, users, and community.
I always tell people who want to start contributing to OSS to start with simple/easy tasks like documentation updates. It minimizes the negative impact of poor quality contributions and allows existing devs to identify and correct workflow inconsistencies during peer review.
The other growing pain is new contributors who bring their 'ideas' but put zero effort toward contributing. 'Ideas' are like assholes, meaning everybody has one. They're not particularly useful unless there's a person ready/willing to implement them. Even then, a new idea may not follow the intent of the project and/or its culture.
Endlessly discussing the 'future possibilities' of a project is extremely counterproductive and distracting to existing developers.