Hi Ryan,

First of all I would like to thank you for the graceful way you replied to my message, even though I was deliberately blunt (maybe more than I realize, a risk I run due to English not being my native language).

In the interest of having a conversation to smooth out some rough edges and improve the workflow for everybody involved, "big" and "small" contributors alike, I'm going to reply to some of your points inline.

On 2017-10-01 19:53, Ryan Schmidt wrote:
Sorry about that.

I did receive notification that you submitted a PR. Thanks for doing that! I am 
not comfortable working with Git and pull requests, so I usually leave them to 
someone else to do.

In that case, I fell it would make a world of difference for the submitter if you just wrote a quick reply with a one-liner stating this (you can just reply to the e-mail you received, you don't even need to use the GitHub website) compared to silence, so the submitter does not spend days waiting for a review that will not happen and can find another reviewer — or ask the list. Wouldn't you agree? Or do you really feel that this is asking too much? (Honest question.)

The port is openmaintainer, which means other developers are to feel free to 
make minor changes to the port, so I did so.

Right. That's a deliberate decision that I took for most (all?) the ports I maintain. I don't want to create any additional friction for other contributors who might want to update the port (or do other *minor* changes) before I have the chance to do so.

Apologies for rehashing the point, but I really feel the need to reinforce it. In this specific case, I was annoyed not because of the change itself (which you rightfully stated that is within the spirit of openmaintainer) but because you used your commit rights to deliberately "jump the queue". I was more annoyed now than in the first time because on that time you probably didn't know (even though according to the guidelines you should have checked), but this time you *knew* I had a PR open with the exact same change, but you went there and committed to it anyway (which you also knew that would result in a conflict) instead of replying to me here, reviewing the PR, or at sent me a FYI one-liner that you were going to change/had changed it — any of which I would have found acceptable. And you did that in a few minutes and moved on while I have to wait many days for my changes to go through (and they still didn't), plus resolve conflicts. I hope that you can see how that can be frustrating, if you put yourself into my shoes, and sympathize with me venting.

So I'm not sure what the solution is. Sounds like I either have to make myself 
comfortable with git and pull requests, and merge any existing pull requests 
before making my own commits (which means everytime I want to commit something 
to a port I have to first check if there are any PRs for it), or I just have to 
refrain from making commits to others' ports. I don't really like either of 
those options. The former is something I've not succeeded in doing all year, so 
I don't feel I'm likely to ever succeed at it. The latter means that when I 
notice a problem in a port that's not mine, instead of fixing it, I ignore it; 
that doesn't seem ideal.

I don't think I'm completely familiarized with the decision making process that led the whole migration from SVN to Git+GitHub, but I found it curious (honestly, not being sarcastic to you) that the project as a whole agreed and published a new process and new tooling but you, being of the project managers and one of the big contributors, are not comfortable with it. It's actually quite a surprise to me.

Regarding merging the PRs before making changes: no, you don't need to do that. However, you *could* quickly search the PRs in GitHub by the port name and see if there are any opened ones, and a simple visual inspection of the diff will suffice in virtually all cases to tell you if whatever you're going to do is going to conflict. I feel that this is important to be done out of politeness to avoid "destroying" other contributor's work, especially if they're waiting a long time to get their work merged. You may miss PRs that don't have the port name, but then they're not following the guidelines and it's not your fault if you missed them.

(There will be also other kinds of situations in which you may need to bypass the queue — security issues, urgent problems affecting many users, etc. That's complete different, of course.)

It looks like you're forcing a false dichotomy here: you either reduce your contribution or you should be allowed to completely ignore the guidelines that the project has put in place (it's literally on the checklist you have to fill in on every PR) and not attempt to communicate with others that might be doing competing work — even though it might antagonize some contributors. Well, you're such an important part of this project that I feel that if you're not willing to compromise in any way shape or form, then small volunteers like me have to just suck it up and accept that this is the way that things are run around here. (I would still stick around and contribute by the way.)

Since we're discussing this topic, I would like to seize this opportunity and ask the list for feedback regarding what is the best workflow moving forward for somebody with *my* profile. But this e-mail is already too long so I'm going to spawn a new thread.

// Leonardo.

Reply via email to