> After weeks (sometimes longer) spent tackling a problem
If you are submitting a single PR after weeks of work, it sounds like the real problem is work has gone on too long without feedback. Current industry practice says you should be committing to mainline daily. In other words, you should have your code reviewed at least once per day.
This feedback cycle of weeks before discussion explains why you might be passionate about this.
However, the real answer to "who should have final say" is whoever is going to:
1. Wake up in the middle of the night if it's an issue
2. Work on future iterations of the code the most
I think this becomes the most clear in open source land. Say you spent weeks adding a feature to an open source project in which you aren't a maintainer. The maintainer has feedback. Who's gets final say? The maintainer, not the PR author. I think it could be helpful to ask why the PR maintainer gets final say. It's not just because of social contract.
After reading the article I did notice that I tend to give the devs the responsibility (authority to make final decisions as well as carry the consequences of such) wherever possible. This actually also includes asking them first whether they want to take part in the project or do a special task in the first place. It's too soon to tell how much better this approach is than simple "you do this, you do that". My thinking is, that you can not embrace any kind of responsibility, if that responsibility is enforced on you. You can not care, if you are a prisoner. I can argue why I think "doing this, doing that" may be good for you/project/team, but enforcing stuff makes things easy in the short run and hard in the long run.
> After weeks (sometimes longer) spent tackling a problem
If you are submitting a single PR after weeks of work, it sounds like the real problem is work has gone on too long without feedback. Current industry practice says you should be committing to mainline daily. In other words, you should have your code reviewed at least once per day.
This feedback cycle of weeks before discussion explains why you might be passionate about this.
However, the real answer to "who should have final say" is whoever is going to:
1. Wake up in the middle of the night if it's an issue
2. Work on future iterations of the code the most
I think this becomes the most clear in open source land. Say you spent weeks adding a feature to an open source project in which you aren't a maintainer. The maintainer has feedback. Who's gets final say? The maintainer, not the PR author. I think it could be helpful to ask why the PR maintainer gets final say. It's not just because of social contract.
After reading the article I did notice that I tend to give the devs the responsibility (authority to make final decisions as well as carry the consequences of such) wherever possible. This actually also includes asking them first whether they want to take part in the project or do a special task in the first place. It's too soon to tell how much better this approach is than simple "you do this, you do that". My thinking is, that you can not embrace any kind of responsibility, if that responsibility is enforced on you. You can not care, if you are a prisoner. I can argue why I think "doing this, doing that" may be good for you/project/team, but enforcing stuff makes things easy in the short run and hard in the long run.