Do the contributing rules apply just to non-committers?

[Bruce Miller]

On 10/01/2017 01:53 PM, Ryan Schmidt wrote:
> 
> On Oct 1, 2017, at 12:41, Leonardo Brondani Schenkel wrote:
>> After replying to your message (within minutes) that I was going to submit the PR (which I did the next day [1] since it was late on my time zone) you felt the need, one day after I opened the PR and explicitly notified you in the PR for review, to go ahead and commit directly to the port — which created a conflict that I'm the one that has to fix if I want to get the PR merged.
...
> 
> 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.
> 
> The port is openmaintainer, which means other developers are to feel free to make minor changes to the port, so I did so.
> 
> 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.

Some thoughts from the sidelines; apologies if I've
misunderstood the context...

Firstly, I suspect you'll get more comfortable with git's
unique approach to vcs over time. It does take adjustment.

Secondly, maybe a compromise solution:
Actually, it's probably *not* a good idea to feel
compelled to merge all PRs before making your own
changes, since PRs are typically PRs exactly because
they need to be reviewed first, and so shouldn't be
rushed.

On the other hand, it probably is worthwhile to
scan any outstanding PRs to sense whether they're
likely to conflict with the changes you want to make.
If there are conflicts, there's the high probability
that you're tackling the same problem as the PR,
and you may want to compare approaches.

Hope I haven't completely missed the point;
bruce