[Cache] Restoration of code and abuse of authority

[Larry Garfield]

On 16 March, I received an email from Paul Dragoonis that he had deleted
the PSR-6 repository on FIG, claiming it was "never used and the idea
was abandoned".

This poses a number of problems.

1) The repository in question *had been used*. It was added very late
in the PSR-6 discussion cycle so there was only minimal activity after
it was created, so there was, I think, only a single commit made after
it was forked from the main fig-standards repository. That repository
in fact held the public copy of the spec that I had moved to Review
status a few weeks ago.

2) That is, Paul deleted *the only public copy of the spec in Review*.

3) He did so unilaterally without the consultation of the owner of the
repository or the spec it held, i.e., me.

This is the second time that Paul has overstepped his authority and
abused his access to the FIG GitHub repositories. While I do not
believe in either case his intent was malicious, it is still
unacceptable. I asked him directly via email for an explanation and was
ignored (despite him responding to the email twice on other, irrelevant
points).

I therefore request that Paul Dragoonis have his access to the FIG
GitHub organization revoked, as I no longer believe he can be trusted
with it.

Fortunately I had the last edits to the spec locally on my laptop, so I
have made a new PR to merge them into the main fig-standards repository
here:

https://github.com/php-fig/fig-standards/pull/477

Someone with access, please hit Merge. (I do not have access to
fig-standards.)

Paddy has been occupied recently so unable to run a discussion around
PSR-6 Review status, but says he will do so shortly. (Hopefully as soon
as that PR is merged.) (No one has stepped forward to be an Editor for
a KeyValue spec, unfortunately. Still looking for that. If we can get
PSR-6 put to bed and off my plate I'm tempted to do so myself because I
think it's worth doing on its own.)

This also highlights that our process around access control right now is
seriously broken. Who should have access to what, when, and for what
purpose? Right now it's "a couple of people seem to have access,
because... reasons", and every spec in development is doing things
differently. This is not a good status quo. I know people hate
discussing process and bylaws but that is a discussion that is long long
overdue, and this incident highlights why.

--Larry Garfield

[Robert Hafner]

This email presents one take on a situation. There are a few immediate facts that I want to clear up.

1. The spec is *not* in review. Larry’s email putting it in review was done unilaterally and one of the sponsors replied to that email to clarify that the spec in question is still in the draft stage.

2. The commits that Larry is trying to get placed into the standard were never approved by anyone other than Larry. Paul and I both feel that adding two expiration methods- “expiresAt” and “expiresAfter”- is a bad API decision. I ask that no one merge that until a discussion is had.


Larry, you’ve done numerous things that people would consider over the bounds. You’re claiming Paul has as well. You’ve also pointed out that the process is currently pretty damn broken.

I see two options for going forward-

1. Assume maliciousness. You scream about what Paul did wrong. I scream about what you did wrong. Paul screams at people. Someone writes a blog post about how silly the FIG people are.

2. Assume good faith. We take the existing PSR-6 and we focus on trying to resolve the issues around it. We open up pull requests for changes, then have discussions. Once there’s a standard we can all live with (which I think we are *really* close to) we put it back in review.


If we go with option one I’m not seeing much hope for things. If we go with option two then I think we also need to follow things up with a general cleaning of house with regards to the bylaws so we can fix the issues that. Having an official policy about how pull requests are handled will clear up any issues like this in the future.

Rob

> --
> You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
> To post to this group, send email to php...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/55189835.2040306%40garfieldtech.com.
> For more options, visit https://groups.google.com/d/optout.

[Larry Garfield]

On 03/29/2015 08:17 PM, Robert Hafner wrote:
> This email presents one take on a situation. There are a few immediate facts that I want to clear up.
>
> 1. The spec is *not* in review. Larry’s email putting it in review was done unilaterally and one of the sponsors replied to that email to clarify that the spec in question is still in the draft stage.
>
> 2. The commits that Larry is trying to get placed into the standard were never approved by anyone other than Larry. Paul and I both feel that adding two expiration methods- “expiresAt” and “expiresAfter”- is a bad API decision. I ask that no one merge that until a discussion is had.

Robert, permit me to, yet again, remind you of something you seem to
actively block from your memory every time I remind you of it.

No one gets to veto changes to PSR-7 other than Matthew (Editor) and
Beau (Coordinator), despite there being others on the Contributors list.

No one gets to veto changes to PSR-5 other than Mike (Editor) and Phil
(Coordinator)[1].

No one gets to veto changes to PSR-9 other than Lukas (Editor) and
Korvin (Coordinator).

No one gets to veto changes to PSR-6 other than Larry (Editor) and
Padriac (Coordinator).

In all cases the Editor and Coordinator should be working in
consultation with all interested parties, and open to input from all
interested parties, but the ultimate decisions about what ends up in the
spec lies with them. That is, no, I do not need your prior consent to
tweak something in the spec. You and others have contributed to it,
greatly, but you do not have veto over it, just as I do not have veto
over PSR-7 (where my role is the same as yours is on PSR-6, Contributor).

So to your point "The commits that Larry is trying to get placed into
the standard were never approved by anyone other than Larry", well, they
don't need to be approved by anyone other than Larry, except perhaps
Paddy. I do not need your approval. I repeat: I do not need your approval.

As for it not being discussed, it came up in the off-list thread
involving you, me, Paul D, Paddy, and Matteo back in JULY the first time
PSR-6 was in review. The thread name is "PSR-6 regeneration time". The
context was the possibility of a expiresAt()/after(), and a
regenerateAt()/after(). In the end we opted to not add the latter, but
the former still seemed like a good idea.


[1] Incidentally, as Phil is no longer a voting representative PSR-5
will need a new Coordinator.

> Larry, you’ve done numerous things that people would consider over the bounds. You’re claiming Paul has as well. You’ve also pointed out that the process is currently pretty damn broken.\

No. I have worked on the spec as editor, which is exactly what my job
is. That I do not seek your consent for every change is not "over the
bounds". It is precisely my role as editor to make decisions about what
does and does not get in. That is precisely and deliberately by design,
precisely to avoid the "any random person can veto" problem. Your
accusations are false, and I would ask you, yet again, to remember that
you are not the editor of PSR-6. If you wish to vote against it when it
gets to a vote that is your prerogative, but you do not get a veto.

> I see two options for going forward-
>
> 1. Assume maliciousness. You scream about what Paul did wrong. I scream about what you did wrong. Paul screams at people. Someone writes a blog post about how silly the FIG people are.
>
> 2. Assume good faith. We take the existing PSR-6 and we focus on trying to resolve the issues around it. We open up pull requests for changes, then have discussions. Once there’s a standard we can all live with (which I think we are *really* close to) we put it back in review.

Quoting from my email, which you have included below:

"While I do not believe in either case his intent was malicious, it is
still unacceptable."

To repeat: I do not assume malice. Lack of malice does not imply lack of
harm, however.

I am done having discussions around PSR-6. It is, in my view, ready for
Review and voting. It was 9 months ago the last time we put it to
Review. There's no new PRs to discuss. It has been 3 years. There is
no more discussion to be had, only a vote.

I am in fact, rather shocked that you, especially, want to keep
discussing PSR-6. I don't even know what to make of that statement at
this point, when the spec is the SAME as was pushed to Review 9 months
ago originally plus the method split, which was discussed. If that DX
improvement is enough for you to want to further delay PSR-6 even more,
well, then I have no response for that other than a facepalm.

--Larry Garfield

[Robert Hafner]

Thank you for reminding everyone that you believe you do not need to consult with or listen to the other people on the PSR-Cache- that what you say goes. This isn’t, as far as you are concerned, a group where people are supposed to work together but one where people should fall in line or be prepared to be ignored and excluded.

Now, let me ask you again, where did discuss the new “expiresAt” and “expiresAfter” method? You’ve made the claim before that this was discussed on the mailing list, and just as you did then I brought up the fact that the mailing list is public and the “expiresAt” method was never mentioned on the list. The discussion you’ve twice now claimed to have happened is something you are literally making up, and if you want to prove otherwise all you have to do is reply with a link to where that conversation took place.

I am done having discussions around PSR-6.  It is, in my view, ready for Review and voting. It was 9 months ago the last time we put it to Review.  There's no new PRs to discuss.  It has been 3 years. There is no more discussion to be had, only a vote.

This part I agree with, but before your last minute hidden change. Just skip the splitting up of the expiration stuff- something only you have brought up, and was never discussed, and which everyone who has expressed an opinion about it thinks is amazingly unclear in wording and scope- 

I am in fact, rather shocked that you, especially, want to keep discussing PSR-6.  I don't even know what to make of that statement at this point, when the spec is the SAME as was pushed to Review 9 months ago originally plus the method split, which was discussed. If that DX improvement is enough for you to want to further delay PSR-6 even more, well, then I have no response for that other than a facepalm.

I don’t want to keep discussing it, I’m just not willing to give into your power plays if it’s going to weaken the standard. You’re the one who put the last minute change in, so you’re the one causing the problems. We tried to discuss this months ago but you decided to unilaterally put the process on hold for the key/value PSR. Stop with the gaslighting nonsense already.

I will 100% support pushing the code forward with a review, then vote, now without the added method.

Rob

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/5518F765.8070306%40garfieldtech.com.

[Peter Cowburn]

On 30 March 2015 at 01:26, Larry Garfield <la...@garfieldtech.com> wrote:

On 16 March, I received an email from Paul Dragoonis that he had deleted the PSR-6 repository on FIG, claiming it was "never used and the idea was abandoned".

This poses a number of problems.

1) The repository in question *had been used*.  It was added very late in the PSR-6 discussion cycle so there was only minimal activity after it was created, so there was, I think, only a single commit made after it was forked from the main fig-standards repository.  That repository in fact held the public copy of the spec that I had moved to Review status a few weeks ago.

2) That is, Paul deleted *the only public copy of the spec in Review*.

3) He did so unilaterally without the consultation of the owner of the repository or the spec it held, i.e., me.

This is the second time that Paul has overstepped his authority and abused his access to the FIG GitHub repositories.  While I do not believe in either case his intent was malicious, it is still unacceptable.  I asked him directly via email for an explanation and was ignored (despite him responding to the email twice on other, irrelevant points).

I therefore request that Paul Dragoonis have his access to the FIG GitHub organization revoked, as I no longer believe he can be trusted with it.

-1.  Okay, he made a mistake and hopefully he can learn from it. We all make whoopsies from time to time. I don't believe Paul should have his access revoked because of this incident.  Frankly, he has been super-helpful over the years playing his part in FIG and the repo, website, etc. management.

Rather than giving even fewer people access to the org repos (ideally, there would be a whole bunch *more* involved), let's address the real problem at hand: backing up the repos, in case of accidental loss or indeed Github being inaccessible. If you feel this an important topic, let's start a new thread?

 

Fortunately I had the last edits to the spec locally on my laptop, so I have made a new PR to merge them into the main fig-standards repository here:

https://github.com/php-fig/fig-standards/pull/477

Someone with access, please hit Merge.  (I do not have access to fig-standards.)

Paddy has been occupied recently so unable to run a discussion around PSR-6 Review status, but says he will do so shortly. (Hopefully as soon as that PR is merged.)  (No one has stepped forward to be an Editor for a KeyValue spec, unfortunately. Still looking for that. If we can get PSR-6 put to bed and off my plate I'm tempted to do so myself because I think it's worth doing on its own.)

This also highlights that our process around access control right now is seriously broken.  Who should have access to what, when, and for what purpose?  Right now it's "a couple of people seem to have access, because... reasons", and every spec in development is doing things differently.  This is not a good status quo.  I know people hate discussing process and bylaws but that is a discussion that is long long overdue, and this incident highlights why.

--Larry Garfield

--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+unsubscribe@googlegroups.com.

[Pádraic Brady]

Let's keep the thread on topic ;).

Once the missing edits are restored...somewhere. I'll move this along
to Review. We need a canonical repo for the PSR to proceed. I think
there was just the one other point for the metadoc to reflect the
discussion that had us retract the previous Review state (for
posterity and so we can point at it should it come up again). Even
this is slightly off topic!

On topic, there should be some sort of formal controls over repo
access. I know I've actively declined being added on the basis I don't
see approval from the group at large in any documented form, and I
tend to be something of a ticking nuke around even the mere appearance
of (let alone any reality of) inappropriateness. I think Paul made a
simple error, and honestly this is going to happen without guidelines
as to how PSR teams should or should not be using the repo. We're only
Human.

Paddy

--
Pádraic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com

[Beau Simensen]

On Monday, March 30, 2015 at 2:04:34 PM UTC-5, Pádraic Brady wrote:

On topic, there should be some sort of formal controls over repo access. [snip] ... this is going to happen without guidelines as to how PSR teams should or should not be using the repo. We're only Human.

Indeed. I think that it would make sense to have a formal process around access to GitHub repositories. At the very least we should have transparency as to who has access and who does not at any given time.

An idea I've seen floated around is that coordinators (and possibly editors/sponsors) of a proposal be granted read+write access to fig-standards. I think this makes sense (and I personally requested read+write access so that I could help coordinate PSR-7). This leaves open the question of who should have access to work with proposals that are no longer under active development, whether it be typos or translations or whatever.

[Larry Garfield]

That would make the most sense to me, and help resolve the mix of 3rd
party repos, huge PRs, etc. that we have now. (IE, in progress
proposals are always in fig-standard/master, in the proposed directory.
Commit as needed.)

For the second point, we should likely have a small number of general
maintainers who have merge for things like bylaws, who can then also do
paperwork around stale PRs, typos, etc. Those should be appointed by
the group.

--Larry Garfield

[Kayla Daniels]

Is there the possibility of creating separate repos for each PSR, giving the Editor and Collaborator access to those repos. Once a PSR is accepted, it can be added to the main fig-standards repository? Is that too much overhead?

It seems that it would solve the problem nicely, so that each person responsible for a PSR will have access, but we won't have an overly large number of people with write access to the main repository. 

Thoughts?

Kayla

[Matteo Beccati]

On 31/03/2015 17:35, Kayla Daniels wrote:
> Is there the possibility of creating separate repos for each PSR, giving
> the Editor and Collaborator access to those repos. Once a PSR is
> accepted, it can be added to the main fig-standards repository? Is that
> too much overhead?
>
> It seems that it would solve the problem nicely, so that each person
> responsible for a PSR will have access, but we won't have an overly
> large number of people with write access to the main repository.
>
> Thoughts?

That sounds like a pretty good way to solve many problems at once.


Cheers
--
Matteo Beccati

Development & Consulting - http://www.beccati.com/

[Paul Dragoonis]

Thank you to my fellow team members for your support, it's comforting to know I have good and honest people around me.

I will not entertain Larry's childish antics at all. Let's use this thread as historical evidence of what kind of antics Larry gets up to instead of working on the Cache proposal.

Regarding repo access - for some time now I've been looking to get more people with access. I sent an off-list email last week about opening up access to more members and there's been no objections to this. Today I've sent a mailing list thread about this officially so it's transparent and out there. 

Please use the 'access' thread for that topic of discussion.

Please create new threads for cache topics and separate-repo topics.

Business as usual folks, keep up the good work on PSR-7, it's looking superb!

--

You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.

To post to this group, send email to php...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/21ecd568-c121-4df0-8a04-b774f66f1593%40googlegroups.com.

[Matthew Weier O'Phinney]

On Tue, Mar 31, 2015 at 11:36 AM, Paul Dragoonis <drag...@gmail.com> wrote:
> I will not entertain Larry's childish antics at all. Let's use this thread
> as historical evidence of what kind of antics Larry gets up to instead of
> working on the Cache proposal.

I'm sorry, but this, too, is an ad hominem attack. If you'd left this
out entirely, your statement would have been much stronger. Instead it
now sounds like a "he said — he said" argument, and this doesn't help
anyone.

FWIW, Larry's objection is that your removal of the repository
HAMPERED his work on the Cache proposal, and was done without notice.
I will not weigh on whether or not it was malicious — I have no way of
knowing — but I can understand his frustration. Address the action,
and move on, but don't continue attacking each other in a public
forum.

> Regarding repo access - for some time now I've been looking to get more
> people with access. I sent an off-list email last week about opening up
> access to more members and there's been no objections to this.

This is not true. An objection was raised that the email should have
been ON-LIST, in public. Thankfully, no actions were taken based on
the off-list email.

> Today I've
> sent a mailing list thread about this officially so it's transparent and out
> there.

Which is where it should be. Thanks for opening it up!


--
Matthew Weier O'Phinney
mweiero...@gmail.com
https://mwop.net/

[Larry Garfield]

On 3/31/15 10:35 AM, Kayla Daniels wrote:
> Is there the possibility of creating separate repos for each PSR, giving
> the Editor and Collaborator access to those repos. Once a PSR is
> accepted, it can be added to the main fig-standards repository? Is that
> too much overhead?
>
> It seems that it would solve the problem nicely, so that each person
> responsible for a PSR will have access, but we won't have an overly
> large number of people with write access to the main repository.
>
> Thoughts?
>
> Kayla

We did that. The separate repo for PSR-6 is the one that Paul deleted
unilaterally without notice. That's the problem.

--Larry Garfield

[Kayla Daniels]

Sorry, misread your initial message then. 

-- 
Kayla Daniels
Sent with Airmail

--
You received this message because you are subscribed to a topic in the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/php-fig/TM61B0rs2Tw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to php-fig+u...@googlegroups.com.

To post to this group, send email to php...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/551AD335.3050002%40garfieldtech.com.

[Anthony Ferrara]

All,

I think there's a fundamental problem not being talked about here
(well, besides by Larry). A repository was deleted. That's a serious
issue, as it means that the canonical source of truth for a proposal
was lost. Reasons aside, that should not happen. Even if the
repository is of no more use, there's nothing wrong with leaving it
there (you're not paying by repository). Instead, by deleting it you
lose the history and the source of truth that it provides **to the
public**.

Perhaps it's worth having a hard and fast rule that nothing is deleted.

PS: All of this tension that's going back and forth is really
off-putting. There are people I consider friends on both sides of this
here, and it's really sickening to me. I hope that differences can be
worked out, or at least worked past. But this hostility is really not
cool...

Anthony

> You received this message because you are subscribed to the Google Groups

> "PHP Framework Interoperability Group" group.

> To unsubscribe from this group and stop receiving emails from it, send an

> email to php-fig+u...@googlegroups.com.
> To post to this group, send email to php...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/php-fig/etPan.551ae40b.1f16e9e8.332%40Kaylas-MBP.

[Cal Evans]

Paul,

There was no need to attack Larry.

I did not consider his email antics. To the contrary, I was waiting for you to step up and explain your actions.

Please limit your comments to facts and not attacks. Larry's email was not an attack, he laid out a problem.

Cheers!

=C=

On Tue, Mar 31, 2015 at 11:36 AM, Paul Dragoonis <drag...@gmail.com> wrote:

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAKxcST8C9rcfJfFH5J53GOPAfZYWeugpJnh44piA5LKyOSpbcw%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Culture of Respect

How to find, hire, and retain developers

[Paul Dragoonis]

On Tue, Mar 31, 2015 at 8:21 PM, Cal Evans <c...@calevans.com> wrote:

Paul,

There was no need to attack Larry.

I did not consider his email antics. To the contrary, I was waiting for you to step up and explain your actions.

Please limit your comments to facts and not attacks. Larry's email was not an attack, he laid out a problem.

Cheers!

=C=

Hi Cal / All!

Apologies if I upset anyone earlier, I was having a bad day and wasn't in the mood to deal with Larry's stuff. I've had several emails from him in the past about removing myself from PHPFIG, and about him getting access. I lost patience a bit with it.

Despite my reply earlier I publicly proposed to give Larry and others access to help out more, so you can take that as me not actually having an issue with Larry with his access and me getting on with things.

The background about this change is:

I was doing some cleaning up, and trying to reduce confusion as to where we're making pull requests and what's the "source of truth" for the cache proposal - because there was two.

I emailed Larry, Paddy and so on updating them about the changes, and the feedback was "you deleted the wrong one" - which was an oops from me, and as Peter pointed out - lessons learned. We spoke about it a week ago and larry said he thinks he has a copy, and he will dig it out, which was good. That's the last we spoke about that, until today.

As Matthew said, let's crack on and I'm always looking to do that so if we can crack on and use the main repo as normal then we can crack on with the Cache stuff.

Anything I've not covered here?

Thanks!

Paul

 

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAPf%3DPy%2BMTHNgNa%3DSo1a%2B0LHX7nMw1kR2tiLdWBMqNbB_%2BYCqVA%40mail.gmail.com.

[Christopher Pitt]

Extraordinary level-headed response. Thank you Paul.

[Korvin Szanto]

So then what can we do to prevent something like this in the future? I'm with Anthony in saying that we just don't delete anything and deal with it the next time something needs deleted.

As an aside, can we all agree to give ourselves a small buffer when replying in a negative way? This group is highly public and eternal, I'd hate for stuff like this to continue to cause a smell to be associated with the FIG.

On Tue, Mar 31, 2015 at 1:28 PM Christopher Pitt <cgp...@gmail.com> wrote:

Extraordinary level-headed response. Thank you Paul.

--

You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/56b93f6d-4275-4f34-8c92-ca5ceb3bf88f%40googlegroups.com.