Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dev Insiders tend to ignore PRs from others, take the work and put it in their own PR #834

Carbon-Zero opened this Issue Mar 11, 2019 · 2 comments


None yet
2 participants
Copy link

Carbon-Zero commented Mar 11, 2019

The few devs with write access to the PIVX repo appear to ignore pull requests from outsiders. Then a similar commit magically appears in their pull request and the one opened by the outsider is closed, with the insider commenting that it was fixed in another pull request and no credit is given to the outsider.

To reproduce:

  1. Go through the work of fixing code, open PR with any git account except Warrows, Fuzzbawls, Presstab, or Mrs X.
  2. Wait. See your PR get older while it goes unacknowledged.
  3. Wait longer and see your change show up in a different pull request with a hundred other commits.

Expected result: Your commit gets merged and you are given credit.

Actual result: Commit is rewritten by Fuzzbawls, Warrows, Presstab, or Mrs. X, and they are credited with the commit. They say that what you fixed in your commit was already fixed in another PR. Refer to other PR. They close your PR and you feel like an idiot for helping as they fail to acknowledge that you did anything helpful at all.

Note: As evidenced by the current list of open PRs, you will almost never see a comment or acknowledgement on an outsider's pull request from a user with PIVX repo write access.


This comment has been minimized.

Copy link

Warrows commented Mar 11, 2019

Alright, I'll try to go through your concerns. If you will allow me, here is what I understand:
1° No one else than "core" devs gets PR merged
This is simply not true: look at #804, merged a month ago. Or #795, #791, #788, #778...
2° "core" devs steal code and commits
I guess you are refering to #809 or #811. If you look at the commits which were merged in place, they are older than these PRs. And also in a PR with a lot more work. The "core" devs being aware such a PR was being worked on, we didn't take the time to review an other. I don't think it would make sense to merge #809 and ask the author of #812 to remove the changes from there when that's where we first saw it. However, you are right that we fail on acknowledging the work done and communicating. But I personaly don't know the best way to do it. Should we say it when we have a several month old branch which already contains the same changes (and others)? Even if we don"t feel ready to share it?
3° "external" devs don't get answers nor recognition
You just have to go through to see that anyone having had a commit merged will get his/her shoutout in the release notes. But indeed, some PR are not getting answers as quick as their authors would like it. There are several reasons to that, and one of them is the dev team being busy.
I get how frustrating it can be to not get reviews or answers, I've been there. If you look at one of my first PR (#447), it took 10 days to get a first acknowledgement.
That being said, it's no excuse for bad communication and we should do our best to keep you guys posted when you help.

If I may, I don't often see external devs reviewing neither "external" nor "core" devs PR. Maybe that would also boost the collaboration.


This comment has been minimized.

Copy link

Carbon-Zero commented Mar 11, 2019

Wow, that was an excellent and we'll thought out answer with tons of info, especially considering the sarchastic/negative tone of my post. My past impressions (possibly incorrect) we're that you aren't very open to outside help.

But you are a true professional and I actually feel bad that I was so careless with what I said there. I was a little frustrated by a two line commit that's 18 days old without acknowledgement. It's fairly trivial to PIVX because the project isn't likely to encounter the condition that calls it again unless something changes, but it's obviously good practice to keep everything shiny. Nothing that needed immediate attention. There are basically two simple ways to fix it, but probably only one is correct.

I have noticed that, despite the exceedingly large number of projects that fork PIVX, there are very few that come back to contribute in a meaningful way, which is unfortunate and possibly really frustrating if I were on your side. I have reviewed a few of the teams commits and commented on them, but your coding skills are head and shoulders above mine and the average dev, so it's a little intimidating to do that. The chances of me catching mistakes with commits from the PIVX team are pretty slim. I do try to contribute with a fix here and there (first time with this account though) if I run into an issue - rather than just fixing it in my code, I think it's a dev's responsibility to bring that fix back to the original project, but I know that's pretty rare and it's unfortunate.

Anyway, I'm really impressed with your reply. A real class act compared to my snarky post. I apologise for that. I'll continue to contribute what I can. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.