I don't mean to make another stink, but....

[Drak]

I'd really rather not make another big deal on this list, but I think something just happened to me which sort of demonstrates a point I made quite recently when I opposed the PSR autoloader and the discussions that arose as a result about the way some things go on in this group.

One point I illustrated was the regularity with which a sponsor of a proposal can summarily filter out what they don't agree with with zero/little discussion basically shutting down any communication and not waiting for any feedback from the group. 

So this has happened more than infrequently, but here is an example where a PR was simply closed without any discussion and without any possibility to address concerns.

I'm past caring, but as someone who has strongly opposed this particular proposal, I STILL took extra an hour out of my time to re-review the proposal again (since it's back on the drawing board) and took some time to constructively contribute by cleaning up and simplifying the code examples in the PSR and make the code examples consistent with each other - why we need two code snippets  I don't know frankly - PSR0 had just one and that worked perfectly OK as a reference for all the subsequent libraries written around it.  (I'd vote for just keeping the closure reference implementation).

I was sure there would be some discussions about a few variable names, but there are certainly valid changes to code. So all that has happened here, is I feel disheartened because again, those with more time and those with more energy just stamp all over those who don't and frankly, I'm getting fed up of it. Realise, if someone contributes a PR, they took time to complete it and at the very least, you owe them some explanation and a chance to discuss it. You don't just close it with a vague objection and be done with it, certainly not in a group like this which is supposed to be about collaboration. 

So, regardless of variable names the code seems unpolished to me and needs to be tweaked. Especially remembering the code examples may very well be copied by all an sundry, we owe it to everyone to take a lot of time to get things polished and right - especially because, unlike say php.net where the docs can evolve, updating something in a PSR is not ever going to be straightforward. People are looking to us as a group and we need to over-deliver.

And for what it's worth, this Friday is probably too soon to resubmit this for vote.

Regards,

Drak

ref: https://github.com/php-fig/fig-standards/pull/124

[Jordi Boggiano]

On 21.05.2013 17:15, Drak wrote:
> So this has happened more than infrequently, but here is an example
> where a PR was simply closed without any discussion and without any
> possibility to address concerns.

The issue with PRs is that they have low visibility. I *try* to read
most mails to the ML, but github notifications tend to face the mark all
read button.

> So, regardless of variable names the code seems unpolished to me and
> needs to be tweaked. Especially remembering the code examples may very
> well be copied by all an sundry, we owe it to everyone to take a lot of
> time to get things polished and right - especially because, unlike say

> php.net <http://php.net> where the docs can evolve, updating something

> in a PSR is not ever going to be straightforward. People are looking to
> us as a group and we need to over-deliver.

I agree with the general sentiment, and most of the changes that were
submitted. I never looked at the code before because frankly I don't
care much about the sample code, but now that I did it does indeed feel
a bit alien to me, and contains stuff like underscore property names
which while not strictly dictated by PSR-1 kinda go against the idea of
camel-casing symbols.

> And for what it's worth, this Friday is probably too soon to resubmit
> this for vote.

+1

Cheers

--
Jordi Boggiano
@seldaek - http://nelm.io/jordi

[Paul Jones]

On May 21, 2013, at 10:15 AM, Drak wrote:

> One point I illustrated was the regularity with which a sponsor of a proposal can summarily filter out what they don't agree with with zero/little discussion basically shutting down any communication and not waiting for any feedback from the group.

My guess is that Drak is referring to this pull request: <https://github.com/php-fig/fig-standards/pull/124>

I said exactly what I thought was wrong with it, and closed the request; when Drak asked what the deal was, I explained further, and offered to review further pull requests. Perhaps my curtness was off-putting; my bad.

> I'm past caring, but as someone who has strongly opposed this particular proposal, I STILL took extra an hour out of my time to re-review the proposal again (since it's back on the drawing board) and took some time to constructively contribute by cleaning up and simplifying the code examples in the PSR and make the code examples consistent with each other -

The specific issue is that the changes you make sever the variable and property names from the terminology used in the spec.

> why we need two code snippets I don't know frankly - PSR0 had just one and that worked perfectly OK as a reference for all the subsequent libraries written around it. (I'd vote for just keeping the closure reference implementation).

Does anyone else here think that two examples is too many? I'm happy to remove one or the other if there's a general feeling in that direction.

> Realise, if someone contributes a PR, they took time to complete it and at the very least, you owe them some explanation and a chance to discuss it.

Which is exactly what we're doing here, isn't it?

> So, regardless of variable names the code seems unpolished to me and needs to be tweaked. Especially remembering the code examples may very well be copied by all an sundry, we owe it to everyone to take a lot of time to get things polished and right - especially because, unlike say php.net where the docs can evolve, updating something in a PSR is not ever going to be straightforward.

I'm all for discussing it here on the list. If there are particular changes you'd like to see, bring them up here where we can all talk about it.

> And for what it's worth, this Friday is probably too soon to resubmit this for vote.

That's fair; I'm not in a particular hurry to push it through. Maybe the following week.


-- pmj

[Paul Jones]

On May 21, 2013, at 10:40 AM, Jordi Boggiano wrote:

> it does indeed feel
> a bit alien to me, and contains stuff like underscore property names
> which while not strictly dictated by PSR-1 kinda go against the idea of
> camel-casing symbols.

Not only is not strictly dictated, it is explicitly ignored by PSR-1. As such, there is nothing wrong with underscored property names (and nothing right with camel cased ones; it's entirely off the table.)



-- pmj

[Jordi Boggiano]

Off the table because they're usually private and therefore do not
impact cognitive interoperatibility. But if you camel case methods and
classes, having lowercases in var names feels pretty wrong to me. Anyway
that's not the only problem, but then again it's all minor issues, and
that's why I never looked at the code..

[Drak]

On 21 May 2013 16:44, Paul Jones <pmjo...@gmail.com> wrote:

Not only is not strictly dictated, it is explicitly ignored by PSR-1.  As such, there is nothing wrong with underscored property names (and nothing right with camel cased ones; it's entirely off the table.)

And that's one of the reasons I changed it, and also changed the logic so there was not an `if (! $foo)` simply because these cases are not explicitly covered by the PSR and so we should not be presenting any code formatting which is not specifically within our coding standards, otherwise, it create confusions and precedent where we maybe don't mean to. Not to mention, there was an easier and less verbose way anyhow. But I'd simply bypass the whole thing by removing the second example. It's superfluous. The closure illustrates the point so it's enough.

Regards,

Drak

 

[Paul Jones]

On May 21, 2013, at 10:49 AM, Jordi Boggiano wrote:

> then again it's all minor issues, and that's why I never looked at the code..

I agree that the issues are minor, trivial even, and probably don't warrant a ton of effort either way.

If we're down to arguing underscores in property names, I think that's a good sign for the proposal as a whole.



-- pmj

[Paul Jones]

On May 21, 2013, at 10:49 AM, Drak wrote:

> And that's one of the reasons I changed it, and also changed the logic so there was not an `if (! $foo)` simply because these cases are not explicitly covered by the PSR and so we should not be presenting any code formatting which is not specifically within our coding standards, otherwise, it create confusions and precedent where we maybe don't mean to. Not to mention, there was an easier and less verbose way anyhow.

If you want to bring those changes up to be discussed on the list, in the "Round 2" thread, I think everyone here would be happy to talk about it.


-- pmj

[Pádraic Brady]

Not much to add - but PRs really are low visibility. I will almost
certainly never look at them unless specifically brought up on the
mailing list. Not sure if it was done, but we should rely on the ML to
track such discussions and then use PRs after a decision or suggestion
is invited/decided there to keep it as visible as possible.

Paddy

> --
> 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/C1B482CF-631F-4A89-87C2-1E6F111D93AC%40gmail.com?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>



--

--
Pádraic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com
Zend Framework Community Review Team
Zend Framework PHP-FIG Representative

[justin]

On Tue, May 21, 2013 at 10:35 AM, Pádraic Brady <padrai...@gmail.com> wrote:

Not much to add - but PRs really are low visibility. I will almost
certainly never look at them unless specifically brought up on the
mailing list. Not sure if it was done, but we should rely on the ML to
track such discussions and then use PRs after a decision or suggestion
is invited/decided there to keep it as visible as possible.

Pull requests aren't just for merging changes. From Scott Chacon's great GitHub Flow post[1]:

> you can use them to say “I need help or review on this” in addition to “Please merge this in”

PRs are a *great* way to indicate "This is the exact change I intend to propose or discuss". As such, I'd *prefer* to see PRs accompany mailing list discussion: open a PR with changes, then open a discussion on the ML with a link to the PR. Then, as an added bonus, once the discussion has played out on the mailing list, the PR with any additional changes can be merged :)

--justin

 [1]: http://scottchacon.com/2011/08/31/github-flow.html

[Tobias Hoffmann]

I will almost certainly never look at them unless specifically brought up on the
mailing list.

Ouch. I can't think why this can happen. PR discussions on Github are great because all the discussion can happen by a click of the mouse on a line of code.

No more copy/pasting huge chunks of code into emails, which are hardly readable anymore. I'm a lurker on this list mostly and I know that my eyes just

glance over once I see more than 5 lines of code in a thread.

It's in my opinion a great mistake to summarily ignore Github's tools such as PR's and inline code discussion because everyone resolves to "certainly never look at them".

I mean, how hard is that?! I'm watching the "fig-standards" repo and in the morning I read the 2-3 threads in my "from: fig-standards" filter folder with activity that popped up over the night.

It takes me literally 10 minutes each morning.

[Ryan McCue]

P�draic Brady wrote:
> Not much to add - but PRs really are low visibility. I will almost
> certainly never look at them unless specifically brought up on the
> mailing list. Not sure if it was done, but we should rely on the ML to
> track such discussions and then use PRs after a decision or suggestion
> is invited/decided there to keep it as visible as possible.
>

Maybe we could whip up something that posts GitHub emails to the list?
IMO, PRs are a much better way to discuss, since it's linked in to the
code, but the visibility issue is fairly concerning.

--
Ryan McCue
<http://ryanmccue.info/>

[Drak]

On 22 May 2013 11:13, Ryan McCue <li...@rotorised.com> wrote:

Maybe we could whip up something that posts GitHub emails to the list? IMO, PRs are a much better way to discuss, since it's linked in to the code, but the visibility issue is fairly concerning.

So good infact is Github's system that Symfony basically closed down their developer list.

But I think the problem here was that people already find it hard enough keeping up with the ML and what has happened is conversations kind of fork, with some things happening in the PRs/issues and others happening on the ML. While I understand the problems, I too think it's a crying shame because the effort to communicate code changes via email is insane. It's also rather ironic that just about everyone here uses Github exactly as intended, but it's not allowed for PHP-FIG discussions. My balance has been to link my emails to a diff now, so that discussion has to happen in the ML but at least, I dont need to copy paste code blocks into email.

It's a shame we just cant move to Github and write everything in an Issue and use issues/PRs. It's practically the same thing anyway. Why bother with email. Github issues/PRs notify to email and you can reply by email. So why bother with the list at all? The only reason I like email is because it "comes to me" but then, so does notification by github.

Sorry to throw the cat among the pigeons but it's seems only logical to drop the list entirely and move to github issues.

Regards,

Drak

[Andreas Möller]

All you need to do is star the repo on GitHub. 

--

Andreas Möller

Web Developer

a...@localheinz.com

--

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/CANAnSg0qUexdDxoyn2ZN5vch%3D8MQJYJcjvR%2B4YGM52%3D0reUHZQ%40mail.gmail.com?hl=en.

[Evert Pot]

Nice idea in theory.. but the level of discourse on github has historically not been very high. I prefer email, forcing people to think a bit about their response, rather than github where it's all too easy to leave a nasty, or unhelpful comment.

Evert

[Lukas Kahwe Smith]

I have the direct opposite experience, mailinglist are much easier to get into bike shedding, while github discussions tend to stay more on point as its closer to code rather than theoretical lala. That being said .. since for the most part we do not discuss actual implementations but interfaces and CS and things like that .. bike shedding is to some degree simply our business.

regards,
Lukas Kahwe Smith
sm...@pooteeweet.org

[Andreas Möller]

Nice idea in theory.. but the level of discourse on github has historically not been very high. I prefer email, forcing people to think a bit about their response, rather than github where it's all too easy to leave a nasty, or unhelpful comment.

You can still reply to comments by email.

Best,

Andreas

[Evert Pot]

On May 22, 2013, at 12:30 PM, Andreas Möller <a...@localheinz.com> wrote:

>> Nice idea in theory.. but the level of discourse on github has historically not been very high. I prefer email, forcing people to think a bit about their response, rather than github where it's all too easy to leave a nasty, or unhelpful comment.
>
> You can still reply to comments by email.

Frankly I'm not worried about myself sending low-quality comments. I hope that's not arrogant.

My worry is about the low barrier to entry.

Evert

[Andreas Möller]

> My worry is about the low barrier to entry.

The barrier of entry isn't any lower than here, I guess.
An advantage would be that everything happens in one place, more or less.

But, the proof is in the pudding, as they say.


Best regards,

Andreas

[Pádraic Brady]

You're misunderstanding - point to the PR in an email. I don't expect the full code in one ;)

Yes it's harsh I really am THAT busy.

Pádraic Brady

http://blog.astrumfutura.com

--

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/CANAnSg0qUexdDxoyn2ZN5vch%3D8MQJYJcjvR%2B4YGM52%3D0reUHZQ%40mail.gmail.com?hl=en.

[Paul Jones]

Hear hear.


-- pmj

[Paul Jones]

Again, hear hear. We don't want to be closed off, but we don't want drive-bys or flash mobs either.


-- pmj

[Andreas Möller]

> Again, hear hear. We don't want to be closed off, but we don't want drive-bys or flash mobs either.

Sometimes it seems to me that what non-voters have to say is more than often perceived as of little value. Maybe, though, it's just a coincidence because I'm a non-voter.


Best regards,

Andreas

[justin]

On Wed, May 22, 2013 at 4:27 AM, Lukas Kahwe Smith <sm...@pooteeweet.org> wrote:

I have the direct opposite experience, mailinglist are much easier to get into bike shedding, while github discussions tend to stay more on point as its closer to code rather than theoretical lala. That being said .. since for the most part we do not discuss actual implementations but interfaces and CS and things like that .. bike shedding is to some degree simply our business.

Meta-bikeshedding is my favorite of all the kinds of bikeshedding :)

--j

[Paul Jones]

On May 22, 2013, at 8:18 AM, Andreas Möller wrote:

>> Again, hear hear. We don't want to be closed off, but we don't want drive-bys or flash mobs either.
>
> Sometimes it seems to me that what non-voters have to say is more than often perceived as of little value. Maybe, though, it's just a coincidence because I'm a non-voter.

The distinction to draw is not between voters and non-voters. It is instead between those who take the time to understand the issues and engage in considered discourse, and those who do not. Most of the subscribers to this list, voter and non-voter alike, belong to the former group.


-- pmj

[Drak]

On 22 May 2013 12:54, Pádraic Brady <padrai...@gmail.com> wrote:

You're misunderstanding - point to the PR in an email. I don't expect the full code in one ;)

But that is exactly the problem - then one gets communications happening in two places. Frankly, having been part of Symfony for a few years, it's amazing how well it works on Github - issues + PRs and their integration... it worked so well that the Symfony dev list was removed. I give this as an example because, if we thought this list was busy, you should see how active it is over at Symfony - it's positively buzzing - and getting more and more busy as time goes on - yet, it works really well for both discussions, RFCs as well as PRs (which can link so nicely. I'm not saying it is the solution for us, just that, there is a real world example where it does work. There is no barrier to entry more than having to join a google mailing list either.

Anyway :-)

Regards,

Drak

[Phil Sturgeon]

Generally speaking, this is what I try and do:

Send a Pull Request, start a thread on the mailing list, keep conversation on the PR to a minimum. 

Nothing political, nothing about goals of the group, no insults, keep it simple. 

Post syntax corrections on the PR, post word changes or typos, but probably best to throw whole paragraphs up on the ML.

It's tricky having the conversation in two places, but if we had all GitHub comments coming into the ML we would get SPAAAAMED by trolls arguing about tabs v spaces and never have any useful conversations. 

Keeping discussion on the ML buts a reasonable barrier up, because folks need to register if they want to talk and this usually means people only contribute if they have something useful to say. I've seen discussions on GH get NASTY. It's a weird difference.

[Paul Jones]

On May 26, 2013, at 11:23 AM, Phil Sturgeon wrote:

> Keeping discussion on the ML buts a reasonable barrier up, because folks need to register if they want to talk and this usually means people only contribute if they have something useful to say. I've seen discussions on GH get NASTY. It's a weird difference.

Preach the Word, brother.


-- pmj

[Donald Gilbert]

Nice idea in theory.. but the level of discourse on github has historically not been very high. I prefer email, forcing people to think a bit about their response, rather than github where it's all too easy to leave a nasty, or unhelpful comment.

Evert

Github parses email responses as well. Just subscribe to the repo. 

[Paul Jones]

To reiterate, the idea is to require some level of commitment (however small) from participants in the conversation. A requirement to register for the mailing list provides that very low barrier to entry.


-- pmj