Hi, Peter. Thank you for taking the time to organize and share your thoughts.
> It took me a considerable amount of time to put this together, I hope > you will respect this effort by crafting a similarly thought out response. Please don't confuse the speed and brevity of my response with a lack of consideration. I've spent many hours over the past couple weeks considering this situation and discussing it with other administrators. > === Question to the PAUSE admins > To put it in the simplest terms: what is the conversation we are having here? In the simplest terms: (1) Matt appears to believe he transferred first-come permissions to you for administrative purposes, not to abrogate his interest in the direction of the project. [I will ask him to explain this himself publicly, since that hasn't happened yet.] (2) You appear to believe that because first-come permissions were transferred to you, you can make whatever permissions changes you like without consultation with Matt, other maintainers or the DBIC community at large. Given the conflict between these views, and given that it was raised to the attention of PAUSE administrators by both you and Matt, we have laid out the principles by which this should be resolved. > The selected person will not be announced until after [changing permissions] > [...large snip...] > If the PAUSE admins feel [Matt's] complaints do have merit - the only way > to address them would be by fiat. As you have quoted the principles I laid out in my earlier email, I'm disappointed in this response. I'm left to conclude that either you don't understand what we're saying or else you're choosing a defiant stance for your own purposes. In the hope that it's the former, I will attempt to clarify, this time with less diplomacy and fewer words. * PAUSE administrators feel the dispute has merit or we wouldn't be involved. * We have already acted by fiat to instruct you not to transfer permissions unilaterally. I understand your desire not to engage with Matt, but feel that's not in the best interests of the communities involved. I'd like to you to consider some scenarios: 1. You announce your successor; Matt and other co-maintainers endorse your choice → problem solved. 2. You announce your successor; Matt and other co-maintainers disagree → argument ensues. Imagine, hypothetically, if you announced the successor *after* transferring permissions: 3. Matt and other co-maintainers endorse your choice → problem solved. 4. Matt and other co-maintainers disagree → argument ensues, but you no longer hold permissions and the argument is left in the hands of your successor. I hope you realize that scenario #4 is strictly worse for your end goals for DBIC than scenario #2. Moreover, from the standpoint of the user community, what's important isn't who has what permissions, it's the actual future development direction and governance model for DBIC. *The community is best served by having the argument play out if one is required.* Unfortunately, that means that the *most* *responsible* thing you can do among your final acts as maintainer is engage Matt and/or the other comaintainers and/or the DBIC community at large with your thoughts about direction and a successor maintainer, despite your misgivings about interacting with Matt. The *least* *responsible* thing to do would be to continue the current course, refuse to engage with Matt and others, and transfer permissions to a successor unilaterally against the express instructions of PAUSE administrators. Being irresponsible in that way would uncut your moral authority to set direction or see your succession wishes respected by PAUSE admins. Therefore, I hope you'll reconsider your stance and choose to engage more constructively. Sincerely, David
