4 ms·

Merging a PR is work too, assuming the maintainer cares enough to review the code. Why not sponsor the project by placing a $300 bounty on the PR merge? As an O

Merging a PR is work too, assuming the maintainer cares enough to review the code. Why not sponsor the project by placing a $300 bounty on the PR merge? As an OSS maintainer who's been on the other side of this in the past, that would have been quite a motivation for me.

rectang 6y ago
Most pull requests are crap. They are drive-by fixes that do not take maintainability into account, because they only solve the problem that the PR submitter needs solved right now. Transforming a sloppy drive-by patch into something which doesn't pile on technical debt is hard. For all but the most brilliantly architected projects, it requires someone who can keep the entire project in their head — a core maintainer. The expectation that unlimited PRs will be reviewed for free is corrosive and contributes to the core-maintainer burnout described in the article.
- throwawaywrench 6y ago
  >because they only solve the problem that the PR submitter needs solved right now. This is something that can lead to angry interactions between maintainers and pull request raisers. Never mind adding technical debt, pull requests can outright break uses cases they don't care about in order to implement the single use case they do care about. raiser: "Merge my PR. It fixes this issue." maintainer: "It fixes this single issue but you've broken this for everyone else." raiser: table flip
  - sergeykish 6y ago
    Why? Just use own fork for a while. PR is sharing fix with others, it is visible even if not merged.
  - rusticpenn 6y ago
    A good test strategy would fix the problem. "Your PR fails all these tests, so can you make them all work before submitting the request?"
    - throwawaywrench 6y ago
      Definitely. You just need to keep an eye out for people removing failing tests because they think they are irrelevant :|
- _greim_ 6y ago
  Some of this burden can be offloaded to robots though, via static types, unit tests, linting, and automatic code formatting. I even go so far as to envision my unit tests as a squad of soldiers laying in ambush around my use cases, waiting to pounce on transgressors.

rectang 6y ago

Most pull requests are crap. They are drive-by fixes that do not take maintainability into account, because they only solve the problem that the PR submitter needs solved right now. Transforming a sloppy drive-by patch into something which doesn't pile on technical debt is hard. For all but the most brilliantly architected projects, it requires someone who can keep the entire project in their head — a core maintainer. The expectation that unlimited PRs will be reviewed for free is corrosive and contributes to the core-maintainer burnout described in the article.

throwawaywrench 6y ago
>because they only solve the problem that the PR submitter needs solved right now. This is something that can lead to angry interactions between maintainers and pull request raisers. Never mind adding technical debt, pull requests can outright break uses cases they don't care about in order to implement the single use case they do care about. raiser: "Merge my PR. It fixes this issue." maintainer: "It fixes this single issue but you've broken this for everyone else." raiser: table flip
- sergeykish 6y ago
  Why? Just use own fork for a while. PR is sharing fix with others, it is visible even if not merged.
- rusticpenn 6y ago
  A good test strategy would fix the problem. "Your PR fails all these tests, so can you make them all work before submitting the request?"
  - throwawaywrench 6y ago
    Definitely. You just need to keep an eye out for people removing failing tests because they think they are irrelevant :|
_greim_ 6y ago
Some of this burden can be offloaded to robots though, via static types, unit tests, linting, and automatic code formatting. I even go so far as to envision my unit tests as a squad of soldiers laying in ambush around my use cases, waiting to pounce on transgressors.