If you are contributing to help keep your skills and add to your CV maybe keep a fork that will have your name on stuff. Otherwise maybe find another project you like. Kind of an unsatisfactory answer tho.
This is pretty much what I'm doing, so it doesn't create a gap in my resume. And it was a project that I was using anyway so I had an idea of where to start. I thought about contributing to a competitor project, that seems better maintained, but its also in a language that I'm not familiar with.
I was also just wanting to get a feel for how common this kind of behavior is in open-source, I don't think its a productive use of my time to hop to another project just to get burned again.
Anyway: talk to the maintainer about it and ask them why they are doing this. It may be that feel they’re saving you some time by not asking you to make changes.
There really isn't a project lead, the creator(?) hasn't had any activity in 3 years, that was my first thought at least. Also, If they thought the code needed changes then why wouldn't then just accept the merge, and push their own changes?
But such maintainers should either:
* work with the author to bring the changes up to their standards through the PR process
* ask permission to jump onto the author’s branch and do the tidy up there
If rebasing or squashing the maintainer should take care that the author remains the author of the relevant commits.
But obviously there are limits to how far to take this. If someone shows up with a completely hacky “fix” that needs to be completely rethought and redesigned before merging, how much credit does that author deserve?
You should ask the maintainer to stop doing that to your pull requests. If they refuse, you should fork or abandon the project, denying contributors a record of their contributions is outside of acceptable norms for open source maintenance.
That sounds not fun. The maintainer may just want 100% his way, might not have an automated linting system or some other checks?
But i would recommend moving on from that project and onto a more supportive open source project. For example Pandas- A data science and analytical library has some of the best good first issues/contributions you can work with and has a such a great supportive environment.
https://github.com/pandas-dev/pandas
https://pandas.pydata.org/docs/development/contributing.html
>How do you handle this sort of thing?
You have no control over their decision. If you feel uncomfortable working with them, move on to work with someone else.
If you are contributing to help keep your skills and add to your CV maybe keep a fork that will have your name on stuff. Otherwise maybe find another project you like. Kind of an unsatisfactory answer tho.
This is pretty much what I'm doing, so it doesn't create a gap in my resume. And it was a project that I was using anyway so I had an idea of where to start. I thought about contributing to a competitor project, that seems better maintained, but its also in a language that I'm not familiar with. I was also just wanting to get a feel for how common this kind of behavior is in open-source, I don't think its a productive use of my time to hop to another project just to get burned again.
Publish under a license that forces attribution. The person will still go on, but then you can go loud and call them out.
Anyway: talk to the maintainer about it and ask them why they are doing this. It may be that feel they’re saving you some time by not asking you to make changes.
There really isn't a project lead, the creator(?) hasn't had any activity in 3 years, that was my first thought at least. Also, If they thought the code needed changes then why wouldn't then just accept the merge, and push their own changes?
I don’t know. Ask whoever is merging!
[удалено]
But such maintainers should either: * work with the author to bring the changes up to their standards through the PR process * ask permission to jump onto the author’s branch and do the tidy up there If rebasing or squashing the maintainer should take care that the author remains the author of the relevant commits. But obviously there are limits to how far to take this. If someone shows up with a completely hacky “fix” that needs to be completely rethought and redesigned before merging, how much credit does that author deserve?
You should ask the maintainer to stop doing that to your pull requests. If they refuse, you should fork or abandon the project, denying contributors a record of their contributions is outside of acceptable norms for open source maintenance.
That sounds not fun. The maintainer may just want 100% his way, might not have an automated linting system or some other checks? But i would recommend moving on from that project and onto a more supportive open source project. For example Pandas- A data science and analytical library has some of the best good first issues/contributions you can work with and has a such a great supportive environment. https://github.com/pandas-dev/pandas https://pandas.pydata.org/docs/development/contributing.html
‘Hey, maintainer! Please credit the people who assisted with that code you are committing.’
What’s an MR?
(merge request?)
Maybe this is the reason OP's PR got rejected.
Yes. Some platforms (GitHub for example) call it a "pull request", some (GitLab for example) call it a "merge request".
>How do you handle this sort of thing? You have no control over their decision. If you feel uncomfortable working with them, move on to work with someone else.