4 ms·

This is all pretty ideal and I think these outcomes are more likely if the project has a substantial base. Comparatively I was trying to contribute to another

This is all pretty ideal and I think these outcomes are more likely if the project has a substantial base. Comparatively I was trying to contribute to another FOSS project only to get push back. I started contributing to the docs to build the package which were way out of date. The project switched from qmake to cmake. The project did not have a correctly working cmake setup so I assisted with that. Every time I contributed the maintainers would check my PR then ping another maintainer who was supposedly working on the specific issues. Eventually I managed to get some docs and code merged but after that the maintainers returned harder to blocking my PR’s with their own work which they happily merged in. They would not update my PR that they had already gone in and solved the problem, I had to repull and figure it out myself, which left me with open PRs/tickets just lingering in the space. They would happily clarify my questions with obscure non-revealing conversation about their project. Eventually I gave up. Similarly I have tried to contribute to things like KDE in the past as well and been met with similar walls on contributing. Some developer somewhere is in charge of a FOSS project as a hobby and only really cares about their use cases or providing a simple demo app or rewriting an old app for their needs because the old app was too complicated or probably run by another hobbyist maintainer. This leads to opening tickets and looking for ways to contribute or discuss implementation with little to no response. Or in the case of KDE, having your ticket closed and shifted over to their bug system which requires rediscussion and retriaging. At some point you just lose momentum and interest trying to push a project along due to the sheer uneventfulness and refocusing of it all. I think we need fewer hobbyist project owners and more hobbyist project managers.

CoastalCoder 3y ago
I had similar frustrations with a well-known deep-learning framework. I'd get well-vetted PR's for the build system, CI system, etc. committed. Only to have them later undone, without discussion, by people in the inner circle. It doesn't take many experiences like that to lose all motivation. I think some open-source projects deceive themselves (and therefore, outsiders) about their contribution processes.
- ozim 3y ago
  Not wondering people rather start their own thing rather than contribute to someone else projects. Cambrian explosion of JavaScript frameworks explained. For me at least as I never really tried to contribute to any open project.
- righthand 3y ago
  Nothing stifles progress and contribution more than having a maintainer take your effort and implement it themselves or carelessly merge your work in without review only to have it reverted for not contributing code correctly. For a lot of FOSS the review process is that the maintainer does it themselves when they feel like it. And you just know the discussion by that inner circle that could have happened during code review is happening in some private email or chat app somewhere away from public eyes.
serial_dev 3y ago
Not to be mean, just to provide a different perspective: having an open source repo doesn't automatically mean I want to deal with every pull request in a timely manner, merge docs cleanups that I don't even like, and especially reviewing and merging features that I don't want. It's true for personal and probably for professional projects, too. Open source means what's in the license, everything else is just us setting expectations for others that they don't want to our can't meet. For example, I make my projects open source because I don't care if anyone else uses my code, so why not.
- righthand 3y ago
  Okay well I never indicated any sort of urgency for my contributions, just that they be considered at all, not ignored then reimplemented because the maintainer has trust issues. Projects I have contributed to in the past aren’t personal projects. They are public facing software that is expecting to be used by the public. The first one I mentioned was a UI library that made me sign a contributors agreement, others have been desktop applications and desktop vpn management code. If you have no intent of accepting contributions you should put that in your README.md or CONTRIBUTING.md. Or even indicate the frequency at which you’re able to consider contributions.
  - m000 3y ago
    > Or even indicate the frequency at which you’re able to consider contributions. Since most things are on GitHub these days, implementing some PR-related analytics for each repo would be nice. This would give you an rough estimate on what to expect and make an informed decision on how much time you are willing to spend.
    - righthand 3y ago
      I believe the repo commit frequency will tell you this (sort of) combined with reviewing pr closed history. However that doesn’t account for the inner circle issue. The main intent of the information though is to indicate process for good natured contributions, however basic as to minimize time waste for the maintainer.

CoastalCoder 3y ago

I had similar frustrations with a well-known deep-learning framework. I'd get well-vetted PR's for the build system, CI system, etc. committed. Only to have them later undone, without discussion, by people in the inner circle. It doesn't take many experiences like that to lose all motivation. I think some open-source projects deceive themselves (and therefore, outsiders) about their contribution processes.

ozim 3y ago
Not wondering people rather start their own thing rather than contribute to someone else projects. Cambrian explosion of JavaScript frameworks explained. For me at least as I never really tried to contribute to any open project.
righthand 3y ago
Nothing stifles progress and contribution more than having a maintainer take your effort and implement it themselves or carelessly merge your work in without review only to have it reverted for not contributing code correctly. For a lot of FOSS the review process is that the maintainer does it themselves when they feel like it. And you just know the discussion by that inner circle that could have happened during code review is happening in some private email or chat app somewhere away from public eyes.

serial_dev 3y ago

Not to be mean, just to provide a different perspective: having an open source repo doesn't automatically mean I want to deal with every pull request in a timely manner, merge docs cleanups that I don't even like, and especially reviewing and merging features that I don't want. It's true for personal and probably for professional projects, too. Open source means what's in the license, everything else is just us setting expectations for others that they don't want to our can't meet. For example, I make my projects open source because I don't care if anyone else uses my code, so why not.

righthand 3y ago
Okay well I never indicated any sort of urgency for my contributions, just that they be considered at all, not ignored then reimplemented because the maintainer has trust issues. Projects I have contributed to in the past aren’t personal projects. They are public facing software that is expecting to be used by the public. The first one I mentioned was a UI library that made me sign a contributors agreement, others have been desktop applications and desktop vpn management code. If you have no intent of accepting contributions you should put that in your README.md or CONTRIBUTING.md. Or even indicate the frequency at which you’re able to consider contributions.
- m000 3y ago
  > Or even indicate the frequency at which you’re able to consider contributions. Since most things are on GitHub these days, implementing some PR-related analytics for each repo would be nice. This would give you an rough estimate on what to expect and make an informed decision on how much time you are willing to spend.
  - righthand 3y ago
    I believe the repo commit frequency will tell you this (sort of) combined with reviewing pr closed history. However that doesn’t account for the inner circle issue. The main intent of the information though is to indicate process for good natured contributions, however basic as to minimize time waste for the maintainer.