Front-end Engineer and Tester. I have a course at https://learn.webdriver.io and I do free coding tutorials at https://www.youtube.com/user/medigerati/
What usually stops me are experiences in the past of simple PRs sitting unreviewed for months on end. I don't have a ton of free-time, so I get anxious thinking about spending several hours creating a worthy PR, just to have it completely ignored by the package author.
I'm not entirely faulting the package author, as I'm certain they're busy with their own work, but it certainly is a frustrating experience. I don't know how to fix it either.
I understand this. I've been there too. I guess the only way out of this is to check if the project is still active before submitting pull request. Like checking the date of the last commit, commenting on the issue and starting a conversation going before putting in effort to make changes and submit pull request.
I'm a Senior DevOps Architect and publish most of my projects as open source. I have a wife, a son and a real life in Hamm, Germany. In my part-time I enjoy making games, music and acting. (He/him)
Although I think, that developing the source for a PR is also a good exercise in working with unknown code and worth the while (if it isn't tooooo time consuming). And if the code is presumably dead, you could adopt it, if you feel to.
Peter is the former President of the New Zealand Open Source Society. He is currently working on Business Workflow Automation, and is the core maintainer for Gravity Workflow a GPL workflow engine.
I've had this as well. When you try and contribute to solve a problem in the code, but the maintainer has silently decided not to work on it any more. I ended up fixing a bug that was in the bug tracker. There was no way to commit except save the patch against the bug. There is stayed without being committed or even reviewed. The means the last version was two years old. You are left building your project against your internal fork. At no point did the maintainer offer to hand it off to people who continued to actively develop against it.
My other pet peave is the way projects expect their users to log into their bug tracking system in order to report a defect. Several times I've found issues, tried to report them, only to give up.
Another variant of this problem is having defects closed as 'won't fix', or 'duplicate', only to find a stream of people reporting the same issue over years. Showing disinterest in users issues is a good way to also discourage deeper involvement such as contributions.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
What usually stops me are experiences in the past of simple PRs sitting unreviewed for months on end. I don't have a ton of free-time, so I get anxious thinking about spending several hours creating a worthy PR, just to have it completely ignored by the package author.
I'm not entirely faulting the package author, as I'm certain they're busy with their own work, but it certainly is a frustrating experience. I don't know how to fix it either.
I understand this. I've been there too. I guess the only way out of this is to check if the project is still active before submitting pull request. Like checking the date of the last commit, commenting on the issue and starting a conversation going before putting in effort to make changes and submit pull request.
Although I think, that developing the source for a PR is also a good exercise in working with unknown code and worth the while (if it isn't tooooo time consuming). And if the code is presumably dead, you could adopt it, if you feel to.
I've had this as well. When you try and contribute to solve a problem in the code, but the maintainer has silently decided not to work on it any more. I ended up fixing a bug that was in the bug tracker. There was no way to commit except save the patch against the bug. There is stayed without being committed or even reviewed. The means the last version was two years old. You are left building your project against your internal fork. At no point did the maintainer offer to hand it off to people who continued to actively develop against it.
My other pet peave is the way projects expect their users to log into their bug tracking system in order to report a defect. Several times I've found issues, tried to report them, only to give up.
Another variant of this problem is having defects closed as 'won't fix', or 'duplicate', only to find a stream of people reporting the same issue over years. Showing disinterest in users issues is a good way to also discourage deeper involvement such as contributions.