5 ms·

I wonder if we need a middle-class of open source contributor — I see a lot of over-worked maintainers, and I see a lot of drive-by contributors with interestin

I wonder if we need a middle-class of open source contributor — I see a lot of over-worked maintainers, and I see a lot of drive-by contributors with interesting half-baked ideas or PRs that fix one bug but fail CI tests — I wish somebody would do the time-consuming and boring-but-valuable work of polishing these contributions into something merge-worthy...

pc86 5y ago
Not trying to be tongue in cheek but isn't it easier for everyone just to reject the bad PRs like that?
- webmaven 5y ago
  > Not trying to be tongue in cheek but isn't it easier for everyone just to reject the bad PRs like that? Sure, especially if your (meta) goal is minimizing individual maintainer effort. But if you want instead to maximize maintainer and contributor return on effort (counting both the originator and the polisher as contributors), a different approach may be called for. Maintainers "just" need to figure out for themselves not just how much work they are willing to put in, but what sort of work, and what work (if any) they are able and willing to delegate or offload onto others. For a maintainer who isn't willing or able to do the work of polishing contributions or handholding potential contributors, and doesn't have anyone they trust that is willing or able to do that work, rejecting most PRs (and even issues, for that matter) outright can be an entirely valid approach. Open source success and sustainability don't look the same for every project or for every maintainer.
pbowyer 5y ago
> I wonder if we need a middle-class of open source contributor [...] I wish somebody would do the time-consuming and boring-but-valuable work of polishing these contributions into something merge-worthy... We need a valuing of non-coding contributions, and a way of welcoming them into projects. I like building community and dealing with people. I like project management, planning, and thinking about funding opportunities. I even like (but am not good at) writing documentaiton - but only if the author of the code is willing to explain _why_ they wrote the code this way rather than get me to write how it works. I haven't come across a project that is open to welcoming people who bring these skills. People do these things have got to that place through long-term involvement, or because the role fell to them. Or no one does it. A decade ago there was a drive to get designers and UX people involved in open source projects [0]. It came to little, to the detriment of the entire open source community. Writing code isn't the only skill important in a project, and if we embrace that the whole experience of using the framework, library or software improves. 0. https://markboulton.co.uk/journal/design-in-open-source/ https://markboulton.co.uk/journal/design-in-open-source/
- alice-i-cecile 5y ago
  I'm doing this role over at Bevy[0]. Docs, project management, and mentorship (plus my technical contributions). It's incredibly valuable for the project, and has allowed us to scale up to hundreds of active contributors in less than two years. We do our best to welcome and encourage other folks in the same sort of role; there's always more PR reviews, issue management and community building to be done. Incidentally, this work has led to an official role with the project, tons of professional experience and contacts, and some well-paid consulting gigs. I have a very strange and spotty resume due to health issues, so it's been frankly life-changing. [0]: https://github.com/bevyengine/bevy https://github.com/bevyengine/bevy

pc86 5y ago

Not trying to be tongue in cheek but isn't it easier for everyone just to reject the bad PRs like that?

webmaven 5y ago
> Not trying to be tongue in cheek but isn't it easier for everyone just to reject the bad PRs like that? Sure, especially if your (meta) goal is minimizing individual maintainer effort. But if you want instead to maximize maintainer and contributor return on effort (counting both the originator and the polisher as contributors), a different approach may be called for. Maintainers "just" need to figure out for themselves not just how much work they are willing to put in, but what sort of work, and what work (if any) they are able and willing to delegate or offload onto others. For a maintainer who isn't willing or able to do the work of polishing contributions or handholding potential contributors, and doesn't have anyone they trust that is willing or able to do that work, rejecting most PRs (and even issues, for that matter) outright can be an entirely valid approach. Open source success and sustainability don't look the same for every project or for every maintainer.

pbowyer 5y ago

> I wonder if we need a middle-class of open source contributor [...] I wish somebody would do the time-consuming and boring-but-valuable work of polishing these contributions into something merge-worthy... We need a valuing of non-coding contributions, and a way of welcoming them into projects. I like building community and dealing with people. I like project management, planning, and thinking about funding opportunities. I even like (but am not good at) writing documentaiton - but only if the author of the code is willing to explain _why_ they wrote the code this way rather than get me to write how it works. I haven't come across a project that is open to welcoming people who bring these skills. People do these things have got to that place through long-term involvement, or because the role fell to them. Or no one does it. A decade ago there was a drive to get designers and UX people involved in open source projects [0]. It came to little, to the detriment of the entire open source community. Writing code isn't the only skill important in a project, and if we embrace that the whole experience of using the framework, library or software improves. 0. https://markboulton.co.uk/journal/design-in-open-source/ https://markboulton.co.uk/journal/design-in-open-source/

alice-i-cecile 5y ago
I'm doing this role over at Bevy[0]. Docs, project management, and mentorship (plus my technical contributions). It's incredibly valuable for the project, and has allowed us to scale up to hundreds of active contributors in less than two years. We do our best to welcome and encourage other folks in the same sort of role; there's always more PR reviews, issue management and community building to be done. Incidentally, this work has led to an official role with the project, tons of professional experience and contacts, and some well-paid consulting gigs. I have a very strange and spotty resume due to health issues, so it's been frankly life-changing. [0]: https://github.com/bevyengine/bevy https://github.com/bevyengine/bevy