Dear Ken, I've seen that you closed a number of your own pull requests for probably no good reason other than being disappointed that your patch wasn't committed faster.
We are heavily understaffed. Not so much understaffed by the number of committers (there are plenty in principle), but mostly by the cumulative amount of time people spend reviewing others' work. Many committers update or fix their own ports when they come around it, but reviewing other people's work is something where we desperately lack the workforce. We have roughly 5000 open tickets on Trac. Most of them don't have any patches, but just to give you the idea. An additional problem is that we now have two types of otherwise top contributors who are held back by "alien technologies". Even for me as a great fan of GitHub, merging pull requests in a "proper way" (without merge commits, getting the right committer's email address, sometimes minor changes are needed) is quite a bit of a pain. To me a closed pull request is either: - an "user error" when the commit is in fact merged, but GitHub doesn't properly recognise it as such - a clear sign of rejecting the PR, meaning that patch was not appropriate for whatever reason Yours don't fall into either of those two categories. Closing it just because one feels bad for not getting it accepted earlier is super bad in my opinion. My personal policy is not to do anything about the PR if it's closed by the contributor, so I won't reopen it or work on it even if I feel that it should be. But mostly, people don't have time to dig through old tickets just for the sake of researching if they happen to have time to resurrect a closed ticket (there are enough open ones to wok on). In one case you mentioned that Ryan would have acted upon the ticket if he wanted to. Ryan is our top contributor (who feels much less at home with git and in particular with GitHub in comparison to subversion), who maintains over 1000 ports, but can no longer spend 16 hours per day working for MacPorts, so it's not fair "blaming" him for not providing you the feedback fast enough. Please reopen those tickets which you still consider worth merging. You may send an email to the -dev list or ping developers on IRC to remind them there's something you would like to see merged. But please don't close tickets "just because". Once you have sufficient track record of good contributions (I'm not sure what the criteria is exactly), you may request commit rights and then commit to the repository directly. Mojca PS: In one extreme case I waited *6 years* for upstream developers to include my patch (which just added additional module to export a graph in a different text-based format, without changing any core functionality). Developers just thought that installing another piece of software was too complex, so they could not test whether my export created any useful result and claimed that anyone who wanted to use my module could *easily* compile the software from source (which is super easy, right?).
