Do the contributing rules apply just to non-committers?

[Ryan Schmidt]

On Oct 1, 2017, at 14:17, Leonardo Brondani Schenkel wrote:

> 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.


Leonardo,

Your English is perfect! No need to worry about that.

I completely understand that you're frustrated, and I apologize for that.

I recall receiving email notification of your PR, but I didn't open the email or look at the PR, since I'm not comfortable with PRs. As such I didn't know that you had only notified me. The PR shows up in the list of open PRs and any developer comfortable dealing with PRs could do so -- as l2dy did, though not before I had committed the conflict we're talking about.

I'm sorry I committed a change similar to one you were proposing in the PR. I honestly had already forgotten that I had asked you to make that change. I remembered that when the dict update commit email first came through, I noticed that the master_sites line probably needed reworking. I then tried to rework it but couldn't verify my changes because SourceForge was down. When SourceForge came back online a couple days later, I remembered that I had tried to work on this port, and completed the work. It wasn't my intention to cause a conflict for you.

We were required to move MacPorts off of Apple's macOS forge hosting infrastructure last year when it was discontinued. After taking a survey of existing contributors, and finding almost unanimous support and approval for Git, we took the opportunity to move our repository to GitHub because that had been requested by many contributors over the years. Many of our maintainers have left MacPorts over the years, in part because they felt the Subversion/Trac workflow was archaic. We hoped moving to GitHub would help most of our existing contributors and attract new ones. After evaluating the GitHub issue tracker we decided to keep our issues in Trac, but convert the source code to Git to be able to offer the pull request workflow which many contributors wished to use. I did not want to let my personal unfamiliarity with Git and GitHub stand in the way of what most of our developer population seemed to want. I still think moving to GitHub has been a net positive for MacPorts, since we've already gained new contributors, even if I personally am not able to use our new infrastructure as effectively as I could use the old one. Fortunately GitHub offers a way to access Git repositories using the Subversion client; in that way, I'm still able to contribute in much the same way as I could before, without getting frustrated by a new tool that doesn't behave how I expect.

\r