I'm the owner of the code in github and responsible of merging PRs in the main upper stream. I have two different PRs from different two contributers which have conflicts in some files. Who is responsible in resolving conflicts in the both PRs? shall I reject one of them?
That's a tricky question for the maintainers / core devs to answer and there cannot be "the one correct answer" as it depends highly on how that particular community works and how the people talk to each other.
Factors to consider are the type of contribution (bug fix, feature extension, new feature), quality of the contributions, the need and urgency to have one or both merged into master, and the time the individual people (patch authors, core devs) can and likely would be willing to spend on the issues. Either way it's good manners to explain the situation to the involved PR authors.
Whatever approach you take, you will need to decide which PR to merge first:
- is one PR clearly more important or beneficial than the other? IMHO: bug fix > feature enhancement / new feature
- is one of the PR authors more communicative and approachable? Explain the situation to him and ask him to rebase his/her PR on top of the other. If so agreed, merge the other PR and wait for an update to the second.
- can you spend the time yourself right now? Then just do that, if you want it done quickly. But still explain why you did so to the PR authors in the closing message or a comment. They might want to have done the necessary changes themselves in another way.
As @planetmaker pointed out, every one has their opinions. But weighing in my $.02, it's usually first raised first merged. So, whoever raised it later has to work on merging it in. The reason for doing this is simply because the the owner is just a middleman to make sure of code quality. So simulating the behaviour of git, usually the one who pushes after the last commit has to fix the conflict. Ofcourse, exceptions can be made when there's a bug fix that's needed ASAP and so on.