Adopting a more open process - Stage One
92 views
Skip to first unread message
Anthony Ferrara
Jun 4, 2012, 1:29:37 PM6/4/12
to PHP Standards Working Group
Hey all,
As you may or may not have read, I wrote a blog post a few weeks ago
about making the PSR/FIG group/standards more open and more beneficial
( http://blog.ircmaxell.com/2012/05/open-standards-better-way.html ).
Well, as promised, here is my first recommendation to that effect:
Have a canonical source of information for proposals.
Right now, there's a lot of conflicting information around where
proposals live. There's some indication that they should live in the
master repo under /proposed. There is another indication that they
live in other people's forks. Then there's this post
https://groups.google.com/group/php-standards/browse_thread/thread/8d9278f5b7593548
that says it doesn't matter, but it won't be in the master repository.
That's very confusing to an outsider. I shouldn't have to follow mails
on a list to view a proposed standard.
My suggestion: Use the current proposals folder on the master branch
of the master repo ( https://github.com/php-fig/fig-standards/tree/master/proposed
) to document all officially accepted proposals. What does that mean?
Well, let's follow through an example workflow of how a standard might
be adopted (what I would like to see):
Step 1: A draft is written by someone from the community (for clarity,
let's say it's a non-voting member, but it works either way). They
write it however they want (github, blog post, whatever).
Step 2: They start a thread about the draft to the mailing list. It's
discussed and evolved.
Step 3: A voting member decides it's ready (by themselves, no vote
yet), and chooses to "sponsor" the draft.
Step 4: At this point, the draft becomes a proposal, is numbered and
pulled into the /proposed folder of the master repo.
Step 5: The sponsor sends a RFC email to the list about the official
proposal, starting a discussion.
Step 6: After at least 2 weeks in discussion, a last call request is
made by the sponsor (speak now, or forever hold your peace).
Step 7: After 1 week after the last call, a vote is called for by the
sponsor.
Step 8: If approved, the proposal is moved into /accepted. If not,
it's moved into /rejected...
Note that steps 4, 7 and 8 are binding. Once you hit those steps, a
idea cannot go back to an earlier step. So a proposal cannot go back
to draft once it is sponsored. It would need to be rejected first,
then re-issued as a new draft. The reason is so that it's clear what's
being voted on and everyone can understand what was changed (so that
there are not moving targets).
Now, there's some significant rationale behind this methodology. The
first is that nothing can be officially proposed without the backing
of at least one voting member. That should help to keep down proposal
traffic to just proposals that would get at least one vote. Second, it
attempts to keep things solid once they are proposed, so that people
understand what's being discussed (it's not a moving target). It also
allows for the numbering to be consistent (since the numbering is done
at sponsor time by the voting body).
More importantly, it provides a canonical place to view proposals.
Don't undervalue this concept. When PSR-1 was proposed, it took a good
bit of time searching to try to find the official proposal. It wasn't
linked to from the working groups github site. The only way I found it
was to dig through the mailing list archive to find what I assumed to
be the official proposal. Having the proposals be in the master github
account allows people to come view all official proposals in one
place, and not have to worry about old content or conflicting content,
or other changes.
The most important point is that it should lower the barrier to
participation. Both on the proposing an idea side, and the commenting
on proposed ideas side. People may not want to follow the mailing
lists. But that's no reason they shouldn't have first-class access to
the proposals...
Thoughts?
Anthony
As you may or may not have read, I wrote a blog post a few weeks ago
about making the PSR/FIG group/standards more open and more beneficial
( http://blog.ircmaxell.com/2012/05/open-standards-better-way.html ).
Well, as promised, here is my first recommendation to that effect:
Have a canonical source of information for proposals.
Right now, there's a lot of conflicting information around where
proposals live. There's some indication that they should live in the
master repo under /proposed. There is another indication that they
live in other people's forks. Then there's this post
https://groups.google.com/group/php-standards/browse_thread/thread/8d9278f5b7593548
that says it doesn't matter, but it won't be in the master repository.
That's very confusing to an outsider. I shouldn't have to follow mails
on a list to view a proposed standard.
My suggestion: Use the current proposals folder on the master branch
of the master repo ( https://github.com/php-fig/fig-standards/tree/master/proposed
) to document all officially accepted proposals. What does that mean?
Well, let's follow through an example workflow of how a standard might
be adopted (what I would like to see):
Step 1: A draft is written by someone from the community (for clarity,
let's say it's a non-voting member, but it works either way). They
write it however they want (github, blog post, whatever).
Step 2: They start a thread about the draft to the mailing list. It's
discussed and evolved.
Step 3: A voting member decides it's ready (by themselves, no vote
yet), and chooses to "sponsor" the draft.
Step 4: At this point, the draft becomes a proposal, is numbered and
pulled into the /proposed folder of the master repo.
Step 5: The sponsor sends a RFC email to the list about the official
proposal, starting a discussion.
Step 6: After at least 2 weeks in discussion, a last call request is
made by the sponsor (speak now, or forever hold your peace).
Step 7: After 1 week after the last call, a vote is called for by the
sponsor.
Step 8: If approved, the proposal is moved into /accepted. If not,
it's moved into /rejected...
Note that steps 4, 7 and 8 are binding. Once you hit those steps, a
idea cannot go back to an earlier step. So a proposal cannot go back
to draft once it is sponsored. It would need to be rejected first,
then re-issued as a new draft. The reason is so that it's clear what's
being voted on and everyone can understand what was changed (so that
there are not moving targets).
Now, there's some significant rationale behind this methodology. The
first is that nothing can be officially proposed without the backing
of at least one voting member. That should help to keep down proposal
traffic to just proposals that would get at least one vote. Second, it
attempts to keep things solid once they are proposed, so that people
understand what's being discussed (it's not a moving target). It also
allows for the numbering to be consistent (since the numbering is done
at sponsor time by the voting body).
More importantly, it provides a canonical place to view proposals.
Don't undervalue this concept. When PSR-1 was proposed, it took a good
bit of time searching to try to find the official proposal. It wasn't
linked to from the working groups github site. The only way I found it
was to dig through the mailing list archive to find what I assumed to
be the official proposal. Having the proposals be in the master github
account allows people to come view all official proposals in one
place, and not have to worry about old content or conflicting content,
or other changes.
The most important point is that it should lower the barrier to
participation. Both on the proposing an idea side, and the commenting
on proposed ideas side. People may not want to follow the mailing
lists. But that's no reason they shouldn't have first-class access to
the proposals...
Thoughts?
Anthony
Andrea Turso
Jun 4, 2012, 8:02:27 PM6/4/12
to php-st...@googlegroups.com
I fully agree with Anthony, I'd also suggest to promote and reference the PSR/FiG and their endeavour on the PHP.net website and in the documentation as well.
Step 5: The sponsor sends a RFC email to the list about the official
proposal, starting a discussion.
Anthony Ferrara
Jun 4, 2012, 9:02:12 PM6/4/12
to php-st...@googlegroups.com
Andrea,
> I fully agree with Anthony, I'd also suggest to promote and reference the
> PSR/FiG and their endeavour on the PHP.net website and in the documentation
> as well.
I'd keep this group separate from the core as much as possible.
Perhaps a promotion on www, but that's about it. It shouldn't be the
"supported" group by mandate, but by behavior and community
recognition...
>>
>> Step 5: The sponsor sends a RFC email to the list about the official
>> proposal, starting a discussion.
>
> Are you referring to the PHP RFC (wiki.php.net/rfc), aren't you?
No. I meant RFC as Request For Comments only. In that the sponsor
sends an email requesting people to comment on it. Perhaps not the
best choice of words given the php.net usage...
Anthony
> I fully agree with Anthony, I'd also suggest to promote and reference the
> PSR/FiG and their endeavour on the PHP.net website and in the documentation
> as well.
Perhaps a promotion on www, but that's about it. It shouldn't be the
"supported" group by mandate, but by behavior and community
recognition...
>>
>> Step 5: The sponsor sends a RFC email to the list about the official
>> proposal, starting a discussion.
>
> Are you referring to the PHP RFC (wiki.php.net/rfc), aren't you?
sends an email requesting people to comment on it. Perhaps not the
best choice of words given the php.net usage...
Anthony
Andrew Eddie
Jun 4, 2012, 9:55:06 PM6/4/12
to php-st...@googlegroups.com
Great suggestions Anthony.
Regards,
Andrew Eddie
> --
> You received this message because you are subscribed to the Google Groups "PHP Standards Working Group" group.
> To post to this group, send email to php-st...@googlegroups.com.
> To unsubscribe from this group, send email to php-standard...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/php-standards?hl=en.
>
Regards,
Andrew Eddie
> You received this message because you are subscribed to the Google Groups "PHP Standards Working Group" group.
> To post to this group, send email to php-st...@googlegroups.com.
> To unsubscribe from this group, send email to php-standard...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/php-standards?hl=en.
>
Matthew Lanigan
Jun 4, 2012, 10:00:53 PM6/4/12
to php-st...@googlegroups.com
I agree wholeheartedly with your suggestions, Anthony. I think that making the process of this more open is essential to its success in the long term.
Matthew
Drak
Jun 4, 2012, 10:53:59 PM6/4/12
to php-st...@googlegroups.com
On 4 June 2012 23:14, Anthony Ferrara <ircm...@gmail.com> wrote:
Step 1: A draft is written by someone from the community (for clarity,
let's say it's a non-voting member, but it works either way). They
write it however they want (github, blog post, whatever).
Step 2: They start a thread about the draft to the mailing list. It's
discussed and evolved.
Step 3: A voting member decides it's ready (by themselves, no vote
yet), and chooses to "sponsor" the draft.
Step 4: At this point, the draft becomes a proposal, is numbered and
pulled into the /proposed folder of the master repo.
Step 5: The sponsor sends a RFC email to the list about the official
proposal, starting a discussion.
Step 6: After at least 2 weeks in discussion, a last call request is
made by the sponsor (speak now, or forever hold your peace).
Step 7: After 1 week after the last call, a vote is called for by the
sponsor.
Step 8: If approved, the proposal is moved into /accepted. If not,
it's moved into /rejected...
Without any comment on the actual proposal, this workflow is slightly unnecessary.
The proposal/ directory is unworkable as we have seen and useless in the github contributor workflow.
A proposal should be discussed on the list and the actual proposal should remain in the proposee's girhub repo as a pull request.
This way the PR can be updated as necessary. When it's finally ready for voting, it can be pulled. There is no need for a
proposal directory in this workflow.
Drak
Phil Sturgeon
Jun 4, 2012, 11:08:06 PM6/4/12
to php-st...@googlegroups.com
I agree that the standards proposition process needs to be simplified and Anthony's suggestion is spot on.
Currently things like the HTTP Client are being discussed in a pull request and on here, duplicating efforts and confusing conversations. Make a proposition anywhere and discuss the draft in one place, then get a pull request in, merge it and talk about it once again before it gets voted on then accepted or rejected. Perfect.
Matthew Lanigan
Jun 4, 2012, 11:23:04 PM6/4/12
to php-st...@googlegroups.com
I'm not sure I understand your argument here. You seem to be describing the workflow which is currently in use, and my understanding of reasoning behind this proposal is that the current workflow is fundamentally flawed and inaccessible, as there is no canonical source for proposals.
Apologies if I'm simply misunderstanding.
Matthew
Drak
Jacob Christiansen
Jun 5, 2012, 3:50:19 AM6/5/12
to php-st...@googlegroups.com
As an "outsider"/non-voting member only following the mailing list on and off, this proposal would greatly increase the transparency of things.
Using PR as it is used now, does not work, it does for code, but not standards. Maybe using GitHub is overkill in this case.
Mail: ja...@wayf.dk
Skype: jacchristiansen
WAYF - Where Are You From
C/O Kulturstyrelsen
H. C. Andersens Boulevard 2
DK-1553 København V
WAYF - Where Are You From
C/O Kulturstyrelsen
H. C. Andersens Boulevard 2
DK-1553 København V
Anthony Ferrara
Jun 5, 2012, 7:39:37 AM6/5/12
to php-st...@googlegroups.com
Drak,
> This way the PR can be updated as necessary. When it's finally ready for
> voting, it can be pulled. There is no need for a
> proposal directory in this workflow.
Once a standard is proposed, it should not be updated at all. If it
needs to be changed, it should be rejected. That way, there's no
moving target. The revision stage happens in the draft steps.
That's the whole point to this workflow. That the modification happens
when it's in draft, finalizing the proposal. Then it's pulled into a
proposal when it's ready. Then that proposal is discussed. If it was
modified as a proposal, it becomes really hard to follow the
discussion around it, since it's not immediately clear what discussion
points were rectified and which were not. That's one issue I have with
the PHP RFC process. It's not really conducive to outsiders who want
to comment on what's being proposed, as they would need to follow both
the discussion and the proposal for changes to understand what's being
proposed.
By using this methodology, a proposal is the final version of the
standard the second it's proposed. The discussion happens around that
final version. If it is determined that the proposal is flawed and
needs updating, it's not ready to be a proposal and should be rejected
and re-enter draft mode.
Sure, this can be a little bit more work for the people involved,
since it will require moving the proposals more. But it will also make
it much easier to follow along from the outside as an observer. Which
is the true point of an open process... Right now, there's a barrier
to entry for an outsider, as they really need to follow the full
discussion in near-real time to understand what's actually proposed.
That's not a good thing, and should (IMHO) be rectified to lower the
barrier to entry so that it's easier for outsiders to understand
what's going on.
And that's the whole point. To open the process more, it should focus
on making it easier for community members that aren't directly
involved to understand what the group is doing, and to make it easy
for them to give input on what's happening without having to invest a
lot of time trying to follow the discussion...
Thanks,
Anthony
> This way the PR can be updated as necessary. When it's finally ready for
> voting, it can be pulled. There is no need for a
> proposal directory in this workflow.
needs to be changed, it should be rejected. That way, there's no
moving target. The revision stage happens in the draft steps.
That's the whole point to this workflow. That the modification happens
when it's in draft, finalizing the proposal. Then it's pulled into a
proposal when it's ready. Then that proposal is discussed. If it was
modified as a proposal, it becomes really hard to follow the
discussion around it, since it's not immediately clear what discussion
points were rectified and which were not. That's one issue I have with
the PHP RFC process. It's not really conducive to outsiders who want
to comment on what's being proposed, as they would need to follow both
the discussion and the proposal for changes to understand what's being
proposed.
By using this methodology, a proposal is the final version of the
standard the second it's proposed. The discussion happens around that
final version. If it is determined that the proposal is flawed and
needs updating, it's not ready to be a proposal and should be rejected
and re-enter draft mode.
Sure, this can be a little bit more work for the people involved,
since it will require moving the proposals more. But it will also make
it much easier to follow along from the outside as an observer. Which
is the true point of an open process... Right now, there's a barrier
to entry for an outsider, as they really need to follow the full
discussion in near-real time to understand what's actually proposed.
That's not a good thing, and should (IMHO) be rectified to lower the
barrier to entry so that it's easier for outsiders to understand
what's going on.
And that's the whole point. To open the process more, it should focus
on making it easier for community members that aren't directly
involved to understand what the group is doing, and to make it easy
for them to give input on what's happening without having to invest a
lot of time trying to follow the discussion...
Thanks,
Anthony
FGM at GMail
Jun 5, 2012, 9:20:10 AM6/5/12
to php-st...@googlegroups.com
Part of the problem might be that people authoring proposals just keep
them on their GH account and do not send pull requests for them, but
mention them on the list, which makes it difficult to find them. The
pull request provides a mechanism to centralize the proposals.
2012/6/5 Anthony Ferrara <ircm...@gmail.com>:
them on their GH account and do not send pull requests for them, but
mention them on the list, which makes it difficult to find them. The
pull request provides a mechanism to centralize the proposals.
2012/6/5 Anthony Ferrara <ircm...@gmail.com>:
Paul M. Jones
Jun 5, 2012, 9:49:08 AM6/5/12
to php-st...@googlegroups.com
On Jun 5, 2012, at 8:20 AM, FGM at GMail wrote:
> Part of the problem might be that people authoring proposals just keep
> them on their GH account and do not send pull requests for them, but
> mention them on the list, which makes it difficult to find them. The
> pull request provides a mechanism to centralize the proposals.
-- pmj
Norv N.
Jun 5, 2012, 11:19:31 AM6/5/12
to php-st...@googlegroups.com
I agree, these points are great, and correct. I thought PR vs proposals were almost equivalent, given the appropriate documentation (information), but anyway the case was opposite, right now, documentation was talking about the /proposals and the practice was PRs.
Drak
Jun 5, 2012, 12:54:16 PM6/5/12
to php-st...@googlegroups.com
On 5 June 2012 17:24, Anthony Ferrara <ircm...@gmail.com> wrote:
Drak,
Once a standard is proposed, it should not be updated at all. If it
> This way the PR can be updated as necessary. When it's finally ready for
> voting, it can be pulled. There is no need for a
> proposal directory in this workflow.
needs to be changed, it should be rejected. That way, there's no
moving target. The revision stage happens in the draft steps.
Absolutely not the case - if you have seen how much tooing and froing there was with PSR-1/2 you'd see this. The standard is constantly moving until it goes for a vote. The entire discussion phase is about refining the proposal. Once it's ready for vote that's the only time it "freezes" to be voted on. If it passes the PR should be merged, if not closed.
Drak
Anthony Ferrara
Jun 5, 2012, 1:16:11 PM6/5/12
to php-st...@googlegroups.com
Drak
> Absolutely not the case - if you have seen how much tooing and froing there
> was with PSR-1/2 you'd see this. The standard is constantly moving until it
> goes for a vote. The entire discussion phase is about refining the proposal.
> Once it's ready for vote that's the only time it "freezes" to be voted on.
> If it passes the PR should be merged, if not closed.
That's exactly the behavior I think needs to be avoided in the future.
When you ask for someone's comments (when it's officially proposed),
it should never be on a moving target. Otherwise, you're creating an
artificial barrier to entry for outsiders to follow what's happening.
The discussion phase is not about refining the proposal. That's what
the draft phase is for. The discussion phase is about identifying
issues with the proposal (which would send it back to draft) and
indicating to voters what the community at large thinks about it. But
by the time it's actually proposed, it really needs to be solidified.
Otherwise, you'll get into a situation like congress was in with the
healthcare bill. Nancy Pelosi famously stated "But we have to pass the
bill so that you can find out what is in it, away from the fog of the
controversy." Do you think that's a good position to be in?
A truly open process looks to prevent that. A proposal should be
solidified *before* discussion happens. Not at vote time. Otherwise
you're unfairly biasing information towards the voters. If you freeze
the proposal at vote time, I (being a non-voting member) cannot give
input on the final proposal before it's voted on. How is that open and
fair?
Instead, keep the modifications and tweaks in the draft phase. That
way, once it's officially proposed, everyone has an even and fair
chance to view and comment on it. If it's not good, send it back to
draft. But don't edit it in proposed phase, it's a huge barrier to
community contribution...
Anthony
> Absolutely not the case - if you have seen how much tooing and froing there
> was with PSR-1/2 you'd see this. The standard is constantly moving until it
> goes for a vote. The entire discussion phase is about refining the proposal.
> Once it's ready for vote that's the only time it "freezes" to be voted on.
> If it passes the PR should be merged, if not closed.
When you ask for someone's comments (when it's officially proposed),
it should never be on a moving target. Otherwise, you're creating an
artificial barrier to entry for outsiders to follow what's happening.
The discussion phase is not about refining the proposal. That's what
the draft phase is for. The discussion phase is about identifying
issues with the proposal (which would send it back to draft) and
indicating to voters what the community at large thinks about it. But
by the time it's actually proposed, it really needs to be solidified.
Otherwise, you'll get into a situation like congress was in with the
healthcare bill. Nancy Pelosi famously stated "But we have to pass the
bill so that you can find out what is in it, away from the fog of the
controversy." Do you think that's a good position to be in?
A truly open process looks to prevent that. A proposal should be
solidified *before* discussion happens. Not at vote time. Otherwise
you're unfairly biasing information towards the voters. If you freeze
the proposal at vote time, I (being a non-voting member) cannot give
input on the final proposal before it's voted on. How is that open and
fair?
Instead, keep the modifications and tweaks in the draft phase. That
way, once it's officially proposed, everyone has an even and fair
chance to view and comment on it. If it's not good, send it back to
draft. But don't edit it in proposed phase, it's a huge barrier to
community contribution...
Anthony
Olivier Finlay Beaton
Jun 5, 2012, 2:16:56 PM6/5/12
to php-st...@googlegroups.com
I'd like to point out that PSR2 has two 4.3 headers, screwing up the numbering for the rest of the section.
Somehow this escaped notice during the review process, and it's now in /accepted (as of this writing) despite being a pretty obvious problem.
When I reviewed PSR2 for my document, I assumed I was looking at an out of date PR and that a more recent one fixed the problem, so I didn't report it. Trying to navigate the PRs as a git-newbie (I confess!) was incredibly frustrating and I ended up coming back to the thread and just trying to find a URI to the proposal instead.
I have to wonder if other errors then or in the future will be caused or at the very least be hard to spot because of all the confusion with PRs during voting.
tl;dr: When something goes up for vote, please put it in /proposals so everyone can find it and be clear on what is being voted on.
Paul M. Jones
Jun 5, 2012, 2:25:37 PM6/5/12
to php-st...@googlegroups.com
On Jun 5, 2012, at 1:16 PM, Olivier Finlay Beaton wrote:
> I'd like to point out that PSR2 has two 4.3 headers, screwing up the numbering for the rest of the section.
> Somehow this escaped notice during the review process, and it's now in /accepted (as of this writing) despite being a pretty obvious problem.
-- pmj
Norv N.
Jun 5, 2012, 5:08:35 PM6/5/12
to php-st...@googlegroups.com
A couple of things that PRs don't do so well:
- differentiate enough (at a glance) which are the current proposals, because PRs are made also for small fixes to the fig repo. Yes, they may be named appropriately, but perhaps there's a difference between seeing 3 proposals somewhere listed, and browsing 12 PRs, 9 unrelated.
- allow to know which is still active. Maybe the theory is that they all are, but it's a normal question in one's mind IMHO, to wonder if one has been forgotten and no longer of interest, when there are 3-4 months old. I didn't really know if it is the case to bother, in a couple cases. Not that it's very relevant, but I think it's a consequence. (for the newcomer at least)
Andrew Eddie
Jun 5, 2012, 6:27:58 PM6/5/12
to php-st...@googlegroups.com
On 5 June 2012 01:29, Anthony Ferrara <ircm...@gmail.com> wrote:
> Step 6: After at least 2 weeks in discussion, a last call request is
> made by the sponsor (speak now, or forever hold your peace).
> Step 7: After 1 week after the last call, a vote is called for by the
> sponsor.
Possibly the only change I'd make here is to allow the author to
> made by the sponsor (speak now, or forever hold your peace).
> Step 7: After 1 week after the last call, a vote is called for by the
> sponsor.
withdraw the proposal in the event that they find it needs more work.
I think that would be more practical and less wasteful of people's
time (imagine the case where the author receives predominantly
negative feedback after the RFC is posted). In that case, the author
returns to step 1.
Anthony, if you feel this next comment is out of scope, please say so.
There is, I feel, still a Step 9 missing to this process and that's
how we acknowledge adoption. If we are going to the trouble of
working all these details out but can't easily demonstrate anyone is
actually using the PSR's, why are we bothering (in other words, how do
we measure success?). I'd like to see a final step where vendors can
register their software as compliant (start simple, don't
over-engineer it - a .md file and a pull request is all you need for
now). I think that would give a big boost to the credibility of this
group and provide a visible "reward" for vendors that go through the
effort of changing their code (not to mention, give the little guys a
bit of exposure amongst a saturated PHP market).
Regards,
Andrew Eddie
Anthony Ferrara
Jun 5, 2012, 8:01:56 PM6/5/12
to php-st...@googlegroups.com
Andrew,
>> Step 6: After at least 2 weeks in discussion, a last call request is
>> made by the sponsor (speak now, or forever hold your peace).
>> Step 7: After 1 week after the last call, a vote is called for by the
>> sponsor.
>
> Possibly the only change I'd make here is to allow the author to
> withdraw the proposal in the event that they find it needs more work.
> I think that would be more practical and less wasteful of people's
> time (imagine the case where the author receives predominantly
> negative feedback after the RFC is posted). In that case, the author
> returns to step 1.
Absolutely. That sounds completely reasonable and fits well inline
with the goals. Very good idea...
> Anthony, if you feel this next comment is out of scope, please say so.
Well, I like the idea. I really do. I do however feel it's a bit out
of scope for this particular discussion (which is why I labeled it
Stage One).
Perhaps it would be worth opening a new thread (continuing the
compliance matrix concept) about it... It's definitely related, just
not strictly about how a standard is adopted...
> There is, I feel, still a Step 9 missing to this process and that's
> how we acknowledge adoption. If we are going to the trouble of
> working all these details out but can't easily demonstrate anyone is
> actually using the PSR's, why are we bothering (in other words, how do
> we measure success?). I'd like to see a final step where vendors can
> register their software as compliant (start simple, don't
> over-engineer it - a .md file and a pull request is all you need for
> now). I think that would give a big boost to the credibility of this
> group and provide a visible "reward" for vendors that go through the
> effort of changing their code (not to mention, give the little guys a
> bit of exposure amongst a saturated PHP market).
Thanks,
Anthony
>> Step 6: After at least 2 weeks in discussion, a last call request is
>> made by the sponsor (speak now, or forever hold your peace).
>> Step 7: After 1 week after the last call, a vote is called for by the
>> sponsor.
>
> Possibly the only change I'd make here is to allow the author to
> withdraw the proposal in the event that they find it needs more work.
> I think that would be more practical and less wasteful of people's
> time (imagine the case where the author receives predominantly
> negative feedback after the RFC is posted). In that case, the author
> returns to step 1.
with the goals. Very good idea...
> Anthony, if you feel this next comment is out of scope, please say so.
of scope for this particular discussion (which is why I labeled it
Stage One).
Perhaps it would be worth opening a new thread (continuing the
compliance matrix concept) about it... It's definitely related, just
not strictly about how a standard is adopted...
> There is, I feel, still a Step 9 missing to this process and that's
> how we acknowledge adoption. If we are going to the trouble of
> working all these details out but can't easily demonstrate anyone is
> actually using the PSR's, why are we bothering (in other words, how do
> we measure success?). I'd like to see a final step where vendors can
> register their software as compliant (start simple, don't
> over-engineer it - a .md file and a pull request is all you need for
> now). I think that would give a big boost to the credibility of this
> group and provide a visible "reward" for vendors that go through the
> effort of changing their code (not to mention, give the little guys a
> bit of exposure amongst a saturated PHP market).
Anthony
Anthony Ferrara
Jun 5, 2012, 8:13:21 PM6/5/12
to php-st...@googlegroups.com
Paul,
> Additionally, the maintainers of the "php-fig/standards" repo are understandably busy with many things, and can't always pay attention to pull requests in a timely manner.
And that's exactly why this style system is critical. If you're that
busy and can't pay attention to pull requests, imagine how other
members of the community feel who don't have the requisite knowledge
about how the system works to even dig through the pull requests...
And the "busy" part is the reason for all proposals to require a
voting member sponsor. That sponsor would handle the pull request and
the other activities up to voting for that proposal. If no voting
member deems the draft to be important enough to spend the time on, it
doesn't go through the process. This is intentional and important. It
does add some work to the voting body, but that work has a great side
effect of filtering the proposals to those that are worth while
considering.
Anthony
> Additionally, the maintainers of the "php-fig/standards" repo are understandably busy with many things, and can't always pay attention to pull requests in a timely manner.
busy and can't pay attention to pull requests, imagine how other
members of the community feel who don't have the requisite knowledge
about how the system works to even dig through the pull requests...
And the "busy" part is the reason for all proposals to require a
voting member sponsor. That sponsor would handle the pull request and
the other activities up to voting for that proposal. If no voting
member deems the draft to be important enough to spend the time on, it
doesn't go through the process. This is intentional and important. It
does add some work to the voting body, but that work has a great side
effect of filtering the proposals to those that are worth while
considering.
Anthony
justin
Jun 6, 2012, 12:18:27 AM6/6/12
to php-st...@googlegroups.com
On Tue, Jun 5, 2012 at 3:27 PM, Andrew Eddie <mamb...@gmail.com> wrote:
> I'd like to see a final step where vendors can
> register their software as compliant (start simple, don't
> over-engineer it - a .md file and a pull request is all you need for
> now). I think that would give a big boost to the credibility of this
> group and provide a visible "reward" for vendors that go through the
> effort of changing their code (not to mention, give the little guys a
> bit of exposure amongst a saturated PHP market).
How about a wiki page? Then anyone can add their project, and there's
> I'd like to see a final step where vendors can
> register their software as compliant (start simple, don't
> over-engineer it - a .md file and a pull request is all you need for
> now). I think that would give a big boost to the credibility of this
> group and provide a visible "reward" for vendors that go through the
> effort of changing their code (not to mention, give the little guys a
> bit of exposure amongst a saturated PHP market).
no PR approval overhead.
It's all honor system anyway, right?
-- justin
Norv N.
Jun 6, 2012, 12:10:08 PM6/6/12
to php-st...@googlegroups.com
> Step 6: After at least 2 weeks in discussion, a last call request is made by the sponsor (speak now, or forever hold your peace).
> Step 7: After 1 week after the last call, a vote is called for by the sponsor.
Just a thought here. Considering the progress timelines for the existing PSRs, and some of the feedback on time availability of people, for these discussions, I wonder if it's better to increase significantly these indicative times.
i.e.
2 weeks -> 4 weeks
1 week -> 3 weeks.
On Monday, June 4, 2012 1:29:37 PM UTC-4, Anthony Ferrara wrote:
Kris Wallsmith
Jun 17, 2012, 9:55:29 AM6/17/12
to php-st...@googlegroups.com
I'm in favor of Anthony's suggestions and appreciative of him bringing them to the group.
How would you like to move this forward? I think we should create a voting thread for some or all of this and move it through the current process. We should do this soon, before the group gets so big that a quorum becomes impossible :)
Kris
Miguel Ramos
Jun 17, 2012, 6:42:38 PM6/17/12
to php-st...@googlegroups.com
You're right. It is now a bit dificultt to follow all discussions.
Joel Simpson
Jul 1, 2012, 3:03:28 PM7/1/12
to php...@googlegroups.com, PHP Standards Working Group
I don't want to derail or interrupt the conversation, but I ran across an interesting tool that looks like it could be helpful for facilitating the proposal and voting process.
http://liquidfeedback.org/open-source/project/ I'm hoping that someone from the core group here could take a quick look to see if it's worth investigating. I don't trust my knowledge of the group to make that determination.
Reply all
Reply to author
Forward
0 new messages