3 ms·

> We believe in open source because it encourages innovation Sorry, but I was not amused when Dendrite decided to stop accepting PRs because they are a small t

> We believe in open source because it encourages innovation Sorry, but I was not amused when Dendrite decided to stop accepting PRs because they are a small team. That is far from encouraging innovation. To me, it seemed like lacking in sustainable FOSS management. PRs I sent were rewritten, squashed and merged by the Dendrite team, instead of them just doing reviews and asking me to fix what they considered unfitting(substandard/wrong. I never thought I'd say that a FOSS team is doing too much work, but it seems to me they burned out for some reason. I can only speculate as to the cause. Changing the license is not going to fix that problem. Anyway, I'm still an active Matrix user, and am grateful for all the work they do put into the projects. I just thought it was more fun to be able to contribute.

zzzeek 3y ago
> PRs I sent were rewritten, squashed and merged by the Dendrite team, instead of them just doing reviews and asking me to fix what they considered unfitting(substandard/wrong. Core devs rewriting and fixing up PRs typically saves a ton of development effort. We field lots of PRs and while I make my best effort to hold their hand to get tests written and such, at some point it's intensely wasteful of everyone's time to have five, six back and forths trying to get the person to write the test case you are telling them to, which you could write yourself in 90 seconds. never mind then getting contributors to write good docs, good changelog notes in the format your project uses, etc. I'll give them one shot for that stuff then I just do it, I really don't have time to "train a new employee" (who doesnt even want to be trained, they just want their one-line fix) for every single one line change.
- pabs3 3y ago
  A lot of folks will just walk away from the project after such an experience. Its in the long term interests of a community to bring new contributors up to speed rather than alienating them.
- YoshiRulz 3y ago
  I second this. As a maintainer, I have a very good understanding of how long it would take (someone familiar with the codebase) to make certain changes. It's far from disrespectful to push before merging when the alternative is to waste both the contributor's time and my own on at least 1 round of purely code style feedback. As a drive-by contributor, I always leave the box checked—the parent commenter seems to be unaware that GitHub gives you this option—in case I wasn't able to match the project's code style, or there's some other reason for the maintainer(s) to make minor changes. Keep in mind that the maintainers could always just squash and clean up afterwards if you were to uncheck it. The idea of maintainers doing what they want to your changeset is really inseparable from PRs as a concept; while I'm in favour of teaching/knowledge-sharing via code reviews, it's not expected and certainly not owed. (Tangentially, I'm finding that with Nix it's now feasible to apply fixes and customisations to packages even if they have "hostile maintainers".)
  - tommiegannert 3y ago
    You mean PR edits? Yes, for small touchups, certainly. Anything that makes the life of maintainers easier. I'm talking about changes that requires maintainers to check out code. You shouldn't feel you have to do that, and if there are many PRs, you shouldn't feel you have the time to do so. > Tangentially, I'm finding that with Nix it's now feasible to apply fixes and customisations to packages even if they have "hostile maintainers" I have that same feeling with Docker/K8S. I don't know how many images I've modified to make them runnable as non-root, but quite a few.
  - zzzeek 3y ago
    > As a drive-by contributor, I always leave the box checked—the parent commenter seems to be unaware that GitHub gives you this option I have no idea what this is. Can you share specifics?
    - YoshiRulz 3y ago
      When you open a PR, look for the "Allow edits by maintainers" checkbox beside the "Create pull request" button. For PRs you've made earlier, you can find it in the sidebar under the participants list. [1]: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/allowing-changes-to-a-pull-request-branch-created-from-a-fork https://docs.github.com/en/pull-requests/collaborating-with-...
- tommiegannert 3y ago
  You're absolutely right that sometimes holding hands takes longer, and as a project maintainer it's up to you to decide where the right tradeoff point is. However, the alternative side is to simply ignore the PR until the contributor is actually helping you. As a maintainer, you shouldn't feel you have to drive the PR. You should guide it, and spend most of your time on whatever else makes sense. (Again with the caveat that I don't know what caused the Dendrite devs in particular to make the decision to close down contributions.)

zzzeek 3y ago

> PRs I sent were rewritten, squashed and merged by the Dendrite team, instead of them just doing reviews and asking me to fix what they considered unfitting(substandard/wrong. Core devs rewriting and fixing up PRs typically saves a ton of development effort. We field lots of PRs and while I make my best effort to hold their hand to get tests written and such, at some point it's intensely wasteful of everyone's time to have five, six back and forths trying to get the person to write the test case you are telling them to, which you could write yourself in 90 seconds. never mind then getting contributors to write good docs, good changelog notes in the format your project uses, etc. I'll give them one shot for that stuff then I just do it, I really don't have time to "train a new employee" (who doesnt even want to be trained, they just want their one-line fix) for every single one line change.

pabs3 3y ago
A lot of folks will just walk away from the project after such an experience. Its in the long term interests of a community to bring new contributors up to speed rather than alienating them.
YoshiRulz 3y ago
I second this. As a maintainer, I have a very good understanding of how long it would take (someone familiar with the codebase) to make certain changes. It's far from disrespectful to push before merging when the alternative is to waste both the contributor's time and my own on at least 1 round of purely code style feedback. As a drive-by contributor, I always leave the box checked—the parent commenter seems to be unaware that GitHub gives you this option—in case I wasn't able to match the project's code style, or there's some other reason for the maintainer(s) to make minor changes. Keep in mind that the maintainers could always just squash and clean up afterwards if you were to uncheck it. The idea of maintainers doing what they want to your changeset is really inseparable from PRs as a concept; while I'm in favour of teaching/knowledge-sharing via code reviews, it's not expected and certainly not owed. (Tangentially, I'm finding that with Nix it's now feasible to apply fixes and customisations to packages even if they have "hostile maintainers".)
- tommiegannert 3y ago
  You mean PR edits? Yes, for small touchups, certainly. Anything that makes the life of maintainers easier. I'm talking about changes that requires maintainers to check out code. You shouldn't feel you have to do that, and if there are many PRs, you shouldn't feel you have the time to do so. > Tangentially, I'm finding that with Nix it's now feasible to apply fixes and customisations to packages even if they have "hostile maintainers" I have that same feeling with Docker/K8S. I don't know how many images I've modified to make them runnable as non-root, but quite a few.
- zzzeek 3y ago
  > As a drive-by contributor, I always leave the box checked—the parent commenter seems to be unaware that GitHub gives you this option I have no idea what this is. Can you share specifics?
  - YoshiRulz 3y ago
    When you open a PR, look for the "Allow edits by maintainers" checkbox beside the "Create pull request" button. For PRs you've made earlier, you can find it in the sidebar under the participants list. [1]: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/allowing-changes-to-a-pull-request-branch-created-from-a-fork https://docs.github.com/en/pull-requests/collaborating-with-...
tommiegannert 3y ago
You're absolutely right that sometimes holding hands takes longer, and as a project maintainer it's up to you to decide where the right tradeoff point is. However, the alternative side is to simply ignore the PR until the contributor is actually helping you. As a maintainer, you shouldn't feel you have to drive the PR. You should guide it, and spend most of your time on whatever else makes sense. (Again with the caveat that I don't know what caused the Dendrite devs in particular to make the decision to close down contributions.)