Workflow Structure

[Amy Stephen]

The reason that "the mob" is creating problems is that the group has not created any workflow. People don't understand what is expected of them. They have abilities that are counterproductive to the project. It's not clear what input is needed. And, it's an easy structure for a group to intentional or accidentally break.

Ever stop and think - no one should be hanging out at this repo? But, some have started doing so, and left as is, more will follow. During the tabs vs spaces debate, I reviewed some of the more militant types, looked at their github activity, and was not surprised to see that some of them have the majority of their activity in commenting, and in PHP-FIG, and little or no code. Some seem to be trolling here. What better place than this group of projects who have made themselves rulers over PHP land. Right?

It's not going to stop on it's own.

It would be a good idea to think about who needs access to what. And quickly, get traffic flow in place. In many ways, that should encourage participation because it will be more clear what input is needed and how to do so. Set some policies, for example, when an issue is closed, make it a policy that *anything* posted on that issue will be deleted. It's just the policy. *shrug*

What is really needed in terms of "stranger" input? If possible, make that as black box as possible. You need to protect communications for your membership, first. Take the fun out it for those who are only trying to create obstructions.

How do people proposal new ideas? Any reason not to have those privately submitted to membership, collected for three months, voted on/prioritized, and then scheduled as projects?

Once you have a project, who should respond to the ideas outside of the membership? Anyone? Or, would it make sense for people to request participation? In a sense, having named working group members might move things better. The Cache has been sitting there starving for your input. Did you all even know? Is it even clear to membership when their input is needed. And, yet tabs and spaces got everyone's attention. Seems like that should be corrected.

If you used working groups, why not close those from public view while they are working to ensure they have good communication and can work together towards a published drafts. Once a draft is available, you could take public comment for 60 days. Best to set a policy that the membership will not respond to the public feedback to avoid encouraging anyone to bait you in. After feedback is collected, then review, revise, publish, until the membership agrees it's ready.

Once it's published, how should people provide input on a completed standard? It's wishful thinking and counterproductive to think people will not want to change it. It'll create pushback if you say things are set in stone. Instead, set a policy to review each once a year (or once every other year) and blackbox collect input until review period. The membership can review the input, discuss, revise (however that is done) and leave it again for the next cycle.

The bottom line is there is no workflow. So, it's very easy to break the structure and obviously a it's  harming this effort.

But the great thing is -- it's all your fault. Call people trolls (and some are) but you are the ones who broke it. (And can fix it. =) ) It's not impossible, just needs some structure.

[Paul Jones]

On Feb 27, 2013, at 7:59 PM, Amy Stephen wrote:

> The reason that "the mob" is creating problems is that the group has not created any workflow. People don't understand what is expected of them. They have abilities that are counterproductive to the project. It's not clear what input is needed. And, it's an easy structure for a group to intentional or accidentally break.

I think this is a fair point, and one that IRCMaxell (er, Anthony Ferrara) has brought up before.



-- pmj

[Anthony Ferrara]

Hey! Someone remembered!!!

I was going to paste this when I got home anyway, so here goes:

https://groups.google.com/d/msg/php-fig/Y_otOAxTkvg/JghuQjjvVy0J

Hopefully there's enough drive now to do it...

Anthony 

[Lukas Kahwe Smith]

Hi Amy,

I absolutely agree that better governance (ie. clearer processes and workflows) would help greatly in reducing wasted energy and negative vibes on this list and within the community in general. Would you be willing to champion/shepherd the process to finding and defining better processes?

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

[Amy Stephen]

It would be an honor to help in this way. Maybe I'll start by touching base with Anthony, see what his thinking is, how we can combine ideas and come up with questions and proposals for the membership's consideration.

Thanks for the opportunity! =)

--
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.
For more options, visit https://groups.google.com/groups/opt_out.

[Lukas Kahwe Smith]

On Feb 28, 2013, at 11:59 , Amy Stephen <amyst...@gmail.com> wrote:

> It would be an honor to help in this way. Maybe I'll start by touching base with Anthony, see what his thinking is, how we can combine ideas and come up with questions and proposals for the membership's consideration.

Ralph has also been concerned with the topic, see also:
https://github.com/php-fig/fig-standards/pull/76

[Amy Stephen]

That's a good idea, it's been a bit of a question mark for others too. Will contact Ralph and get him involved (or if he sees this he join us =) ).

It would be good to hear thoughts on where membership feels better information and updates would help them, too.

Anything folks have to share, just drop it in here and we'll see where it fits.

[Paul Dragoonis]

Justin has also prepared a gist post on stuff that might aid this, I'll prompt him to post it here it has a crossover of the stuff going on here.

Thanks for stepping up Amy! I'll keep an eye on workflow stuff too.

[Amy Stephen]

Thanks Paul - there is a good discussion https://github.com/php-fig/fig-standards/pull/93 on process - both Andrew and Justin have good information. Going to follow some of those links.

What about using Google Group Communities?

There could be a PHP-FIG "central" community that links to other  communities established for working group and other needs (ex maybe a public area for feedback or requesting participation).

That provide different types of control for membership (open to all, must be invited, request invitation) and closed or public (assuming all would be public read, at minimum).

It would making closing topics for archival (no update) easier once a standard is adopted or canceled. And to do so in a way that isn't off-putting, but natural (of course it's closed, it's been passed).

Reasonable file and attachment capabilities.

Very good group communication support for meetings, voice, video, etc.

Important, of course, to pull these various sites together, but we can come up with a way to provide a common navigational features that brings the information website, github resources, communities and email lists together (although we'd probably archive the email list).

Thoughts?

[Anthony Ferrara]

I would highly suggest not reinventing the wheel here. Take a look at RFC2026, which documents the RFC process: http://www.ietf.org/rfc/rfc2026.txt

Also, check out Python's PEP-1 http://www.python.org/dev/peps/pep-0001/ which basically does the same thing (although isn't nearly as verbose).

One of the fundamental points is that after release (approval), no further changes can ever happen. That's absolutely critical. 

[Moisa Teodor]

The Java Community Process could also have some valuable information about the process they use when releasing JSRs:

http://www.jcp.org/en/procedures/jcp2

--
Doru Moisa
web: http;//moisadoru.wordpress.com
tel: +40 720 861 922
Bucharest, Romania

[FGM at GMail]

To be more accurate, in the IETF/IESG (RFC) process, only status
changes can happen to these documents: §6.2, 6.3 and 6.4 address this
specifically:

- "A new version of an established Internet Standard must progress
through the full Internet standardization process as if it were a
completely new specification."
- "[if two versions coexist] the relationship between the previous and
the new versions must be explicitly stated in the text of the new
version or in another appropriate document"
- when some standard becomes obsolete "the IESG shall approve a change
of status of the old specification(s) to Historic"

Note that in practice, the header of superseded RFCs is modified to
contain an information like "obsoleted by RFC#nnn", so they are not
strictly read-only.

2013/2/28 Anthony Ferrara <ircm...@gmail.com>:

[Lukas Kahwe Smith]

On Feb 28, 2013, at 14:30 , FGM at GMail <fgma...@gmail.com> wrote:

> To be more accurate, in the IETF/IESG (RFC) process, only status
> changes can happen to these documents: §6.2, 6.3 and 6.4 address this
> specifically:
>
> - "A new version of an established Internet Standard must progress
> through the full Internet standardization process as if it were a
> completely new specification."
> - "[if two versions coexist] the relationship between the previous and
> the new versions must be explicitly stated in the text of the new
> version or in another appropriate document"
> - when some standard becomes obsolete "the IESG shall approve a change
> of status of the old specification(s) to Historic"
>
> Note that in practice, the header of superseded RFCs is modified to
> contain an information like "obsoleted by RFC#nnn", so they are not
> strictly read-only.

FYI: This thread is discussing processes in more broad terms than just the question of if/how changes to PSRs can be done.

[Amy Stephen]

On Thu, Feb 28, 2013 at 7:34 AM, Lukas Kahwe Smith <sm...@pooteeweet.org> wrote:

FYI: This thread is discussing processes in more broad terms than just the question of if/how changes to PSRs can be done.

Yea, just the minimal structure in place that supports defined processes and helps direct people to where their input is needed and keeps them out of trouble where it's not needed =).

You guys might want to add input to this thread where members are discussing procedural requirements https://github.com/php-fig/fig-standards/pull/93
 
Anthony - given your previous input and references, and then also from that link above, I pulled those two out as important background information. Thanks - don't hide when I come talking to you. ;-)

 

[justin]

Here's the document Paul was talking about:

https://gist.github.com/bobthecow/8eba98be4acf52e8866a

Inline below to save you a click:

Thoughts on diffusing a mob of well-meaning community members

1. Revise the FIG mission statement, and do user testing on it, until it's clear what the FIG is and what it's trying to do.

2. Come up with some well-written FAQ entries about the FIG and its mission, common misconceptions, the PSR process, etc. When one of them comes up in a pull request or on the mailing list, point users to the FAQ entry.

3. Rename the standards repo to php-fig/psrs.

4. Make a concerted effort to refer to PSRs as Recommendations not Standards.

5. Add a CONTRIBUTING.md file to the psrs repo. Include a summary of how to get involved with FIG: contributing, requesting membership, discussing (mailing list only, of course) and proposing PSRs. Include a bunch of links to FAQ entries and bylaws for more info.

6. (possibly?) Disable issues on the psrs repo. Pull requests will still work, but it will discourage creating issues and discussion there and encourage it on the mailing list.

7. Appoint a couple of people as moderators of the GitHubs. Write up some rules about how people can interact on GitHub issues and PRs, post the rules in a public place, and grant moderators authority to enforce them.

That last one is a dangerous one, so it gets a couple more points:

• The moderators' prime directive is to facilitate helpful discussion (read: move it to the mailing list), inform n00bs, and enforce FIG processes.

• Everything they do must be completely transparent. They must enforce only rules which have been explicitly spelled out (or linked to) in CONTRIBUTING.md. If they delete comments, they should probably Gist the conversation and link to it in a comment:

  Please continue this discussion on the mailing list: {thread link}

  Off-topic comments have been archived {gist link} and removed.

• They should be helpful, supportive and nice while doing this. This means that they prolly should not delete the first off-topic comment on a pull request, but should remind users of the appropriate ways to interact.

• Moderators should apply the "broken window theory" to the discussion on issues and pull requests. If it is on topic, meaning it's actual comments regarding the content of the request, it can stay, but off-topic conversation, and conversation regarding the merit of the pull request, should be shut down quickly to keep it from getting out of hand. Here's where the moderators would delete comments, close pull requests and issues, etc, and point people to the FAQ, bylaws, CONTRIBUTING.md and mailing lists.

• Pull requests which are invalid should be closed (fairly quickly) with a helpful message:

  Revisions to finalized PSRs must follow the following process {link to bylaws}

  Feel free to discuss this on the mailing list {link}.

  Note that this relies on the bylaws and processes currently under discussion actually getting passed. So let's do that too :)

• As long as people engage trolls and off-topic conversation in issues and pull requests, they will keep commenting on issues and pull requests.

• This one is in BIG BOLD LETTERS because it is VERY IMPORTANT: We don't want to censor or stifle dissention. We want to redirect to a more useful place.

http://justinhileman.com

[Amy Stephen]

Thanks Justin, appreciate that.

Love the title. =)  Not so sure everyone fit that, but I do love the attitude.

[Amy Stephen]

Zend folks -

Does this post from @weierophinney entitled "On php-fig and Shared Interaces" post.http://www.mwop.net/blog/2012-12-20-on-shared-interfaces.html

Explain the point of view https://github.com/php-fig/fig-standards/pull/76 ?

This thread is about adding a little structure that makes it easier to know what activities are underway, how the public can get involved, isolates the voting activity so only members are able to vote, etc.

Are there ways that both types of activities, the standards and the interfaces (or bridges and adapters) can co-exist? Can we use work flow, neon signs and structure to clarify those two broad themes so the work can continue in both directions and clarify the purpose of the group?

I guess I'd like to hear what the Zend folks this is missing and what's needed. It might be difficult to understand at first, so patience is appreciated.

Also, I'm not sure if this is a bit of a conflict or not, but if it is, I'd ask this not be a debate at least until the Zend point of view is clear. Otherwise, it's hard for others to catch up. 

[Andreas Möller]

I would highly suggest not reinventing the wheel here. Take a look at RFC2026, which documents the RFC process: http://www.ietf.org/rfc/rfc2026.txt

Also, check out Python's PEP-1 http://www.python.org/dev/peps/pep-0001/ which basically does the same thing (although isn't nearly as verbose).

One of the fundamental points is that after release (approval), no further changes can ever happen. That's absolutely critical. 

One could also have a look how DIN and ISO are developing standards:

* http://www.din.de/cmd?menuid=47560&menusubrubid=59377&cmsareaid=47560&menurubricid=59362&level=tpl-unterrubrik&cmsrubid=59362&cmssubrubid=59377&languageid=en

* http://www.iso.org/iso/home/standards_development.htm

Best regards,

Andreas

[Amy Stephen]

Thank you Andreas. This particular thread is focused on how to support the mission and purpose of this group in a way that makes it clear to people where their input is needed and how to find information useful to them.

There are other threads and PR's open that are discussing the standard process itself. Don't have links at the moment - too much going on. =)

++++

Robert Hafner has good posts on organizational structure that should be reviewed. 

• Recently - https://groups.google.com/d/msg/php-fig/PlRDNJlX1Y8/hTrbIo_RyVcJ
• Earlier - https://groups.google.com/forum/?fromgroups=#!topic/php-fig/IR7dTkaFVXI

 

[Amy Stephen]

Justin's recommendation for a Contribution file to help inform the public when and where their input is needed

https://groups.google.com/d/msg/php-fig/-N56pNKtZHE/DvM1ZP2tYosJ

[Amy Stephen]

Very good points raised in other threads:

1. Points Andrew is making should be front and center, would reduce a lot of unnecessary tension and confusion from the public, IMO

Andrew Eddie - calling for clear and positive communication to other projects, flexibility, appreciating the significance of the group and pressure on the vendor communities.
https://groups.google.com/d/msg/php-fig/-N56pNKtZHE/nhgl-skVrF8J

2. Very good points on better utilizing README and CONTRIBUTOR files

Matthieu Napoli - good point on the README https://groups.google.com/d/msg/php-fig/-N56pNKtZHE/41D78Z1aYSkJ

3. Agree with Ryan that an ability to group all discussions, files, votes, for an issue would be very helpful:

Ryan Parman - https://groups.google.com/d/msg/php-fig/-N56pNKtZHE/JRjs1Z-W3QIJ

I also think it would be useful to include the relevant discussion links (read the post for more good info)

[Amy Stephen]

I'm sorry, but I need to step away. If there are questions, please email me. I won't be listening on the list.

Thank you.

[Justin Hileman]

On Friday, March 1, 2013 4:04:46 AM UTC-8, Amy Stephen wrote:

Justin's recommendation for a Contribution file to help inform the public when and where their input is needed

https://groups.google.com/d/msg/php-fig/-N56pNKtZHE/DvM1ZP2tYosJ

Note that, since we're currently discouraging conversation on GitHub issues and pull requests, we should remove that option from the README:

https://github.com/php-fig/fig-standards#proposing-a-standards-recommendation

--j 

[Paul Dragoonis]

Definitely agree.

--

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/msg/php-fig/-/q3ibZIEPgb4J.

[Pádraic Brady]

Hi all,

On 28 February 2013 17:37, justin <jus...@justinhileman.info> wrote:
> Here's the document Paul was talking about:
>
> https://gist.github.com/bobthecow/8eba98be4acf52e8866a
>
> Inline below to save you a click:
>
>
> Thoughts on diffusing a mob of well-meaning community members
>
> Revise the FIG mission statement, and do user testing on it, until it's
> clear what the FIG is and what it's trying to do.
>
> Come up with some well-written FAQ entries about the FIG and its mission,
> common misconceptions, the PSR process, etc. When one of them comes up in a
> pull request or on the mailing list, point users to the FAQ entry.
>
> Rename the standards repo to php-fig/psrs.

Don't quite get this one. Does PSR not already include the term
anyway? Burying what everybody already knows in an abbreviation
everybody already knows to camoflage that doesn't seem to do anything
worth the time.

> Make a concerted effort to refer to PSRs as Recommendations not Standards.

I appreciate the shift in terminology but people will continue to use
the prevailing language in common use until such time as the voting
members change "PSR" to something which explicitly does not refer to a
standard (not proposing this!).

> Add a CONTRIBUTING.md file to the psrs repo. Include a summary of how to get
> involved with FIG: contributing, requesting membership, discussing (mailing
> list only, of course) and proposing PSRs. Include a bunch of links to FAQ
> entries and bylaws for more info.
>
> (possibly?) Disable issues on the psrs repo. Pull requests will still work,
> but it will discourage creating issues and discussion there and encourage it
> on the mailing list.

I disagree that fewer communication channels is a solution. We'd be
removing an ideal medium for reporting actual issues of a genuine
nature.

> Appoint a couple of people as moderators of the GitHubs. Write up some rules
> about how people can interact on GitHub issues and PRs, post the rules in a
> public place, and grant moderators authority to enforce them.

Completely agreed.

> That last one is a dangerous one, so it gets a couple more points:
>
> The moderators' prime directive is to facilitate helpful discussion (read:
> move it to the mailing list), inform n00bs, and enforce FIG processes.

Agreed.

> Everything they do must be completely transparent. They must enforce only
> rules which have been explicitly spelled out (or linked to) in
> CONTRIBUTING.md. If they delete comments, they should probably Gist the
> conversation and link to it in a comment:
>
> Please continue this discussion on the mailing list: {thread link}
>
> Off-topic comments have been archived {gist link} and removed.

Disagree. If a comment is off-topic we should delete it - not archive
it. If any comment is on-topic it should not need to be archived.

> They should be helpful, supportive and nice while doing this. This means
> that they prolly should not delete the first off-topic comment on a pull
> request, but should remind users of the appropriate ways to interact.
>
> Moderators should apply the "broken window theory" to the discussion on
> issues and pull requests. If it is on topic, meaning it's actual comments
> regarding the content of the request, it can stay, but off-topic
> conversation, and conversation regarding the merit of the pull request,
> should be shut down quickly to keep it from getting out of hand. Here's
> where the moderators would delete comments, close pull requests and issues,
> etc, and point people to the FAQ, bylaws, CONTRIBUTING.md and mailing lists.

Delete or archive? It sounded earlier like you intended to archive off-topics?

> Pull requests which are invalid should be closed (fairly quickly) with a
> helpful message:
>
> Revisions to finalized PSRs must follow the following process {link to
> bylaws}
>
> Feel free to discuss this on the mailing list {link}.

Agreed - subject to bylaws we pass and subject to clarifying the
moderators authority.

> Note that this relies on the bylaws and processes currently under discussion
> actually getting passed. So let's do that too :)
>
> As long as people engage trolls and off-topic conversation in issues and
> pull requests, they will keep commenting on issues and pull requests.
>
> This one is in BIG BOLD LETTERS because it is VERY IMPORTANT: We don't want
> to censor or stifle dissention. We want to redirect to a more useful place.

--
Pádraic Brady

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

[Amy Stephen]

On Saturday, March 2, 2013 7:57:01 AM UTC-6, Pádraic Brady wrote:

> Appoint a couple of people as moderators of the GitHubs. Write up some rules
> about how people can interact on GitHub issues and PRs, post the rules in a
> public place, and grant moderators authority to enforce them.

Completely agreed.

> That last one is a dangerous one, so it gets a couple more points:
>
> The moderators' prime directive is to facilitate helpful discussion (read:
> move it to the mailing list), inform n00bs, and enforce FIG processes.

Agreed.

> Everything they do must be completely transparent. They must enforce only
> rules which have been explicitly spelled out (or linked to) in
> CONTRIBUTING.md. If they delete comments, they should probably Gist the
> conversation and link to it in a comment:
>
> Please continue this discussion on the mailing list: {thread link}
>
> Off-topic comments have been archived {gist link} and removed.

Disagree. If a comment is off-topic we should delete it - not archive
it. If any comment is on-topic it should not need to be archived.

> They should be helpful, supportive and nice while doing this. This means
> that they prolly should not delete the first off-topic comment on a pull
> request, but should remind users of the appropriate ways to interact.

What I would hope could be designed is an environment where people are not *able* to post in a location where that post is not welcome.

No matter how nice someone is when they do it, having your post removed is, at best, embarrassing and discouraging. And, that's with the most gentle approach.

If the roles and processes are clearly defined, we can support those rules with a structure that only enables access for those who need it, when they need it, no more, no less.

That doesn't mean things won't go off-topic, from time to time, but -- until the membership shows a commitment to their own rules -- https://github.com/php-fig/fig-standards/pull/95 -- never should we expect more of our guests who did not write the rules and are very likely unaware.

When a group commits to treating guests like very important people, it builds a tremendous amount of positive energy, respect, and support. What attracts trolls is dealing with trolls. Starts to look fun for trolls. Stronger dealing with trolls and it gets to be a Disney World for asshats. You grow what you pay attention too.

When the membership individually holds itself to higher standards than guests, the reverse happens.

[Pádraic Brady]

Not sure if it fits here but yesterday I posted comments on a PR and
Larry, quite rightly so, reminded us not to do that. Worth noting the
technical reasons why PR commenting is limited and discouraged, i.e.
comments vanish if the line they were added for in the change diff is
subsequently changed/removed in the PR'd code/text.

Paddy

--
Pádraic Brady

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

> --

> 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/msg/php-fig/-/1EBKPPkhC9cJ.

[Pádraic Brady]

Hi Amy,

Being from the "Zend" side of the tracks, it's worth bearing in mind
that the Zend folk tend to represent personal opinions without the
concensus of the community. We are a benevolent dictatorship so my
views here will differ from Matthew's and Ralph's.

Reading Matthew's post, he makes a lot of good points - PSRs to date
don't really address the "best practices" that assist
interoperability. My own personal opinion, however, is that
interoperability can be aided by agreed interfaces and I'm confident
that Larry's ongoing poll will overwhelmingly bear that out. Will this
hinder innovation? Of course it will - Logger libraries of the future
will feel compelled to use PSR-3 even if it hampers a looser interface
more in keeping with the selection of features they expose. Presumably
this is already being addressed by narrowing the scope of final
interfaces to minimal features. Does this mean we shouldn't do it? I
believe that's why we have a voting mechanism ;).

On the naming of PSRs, I see no point in changing the the name or
abbreviation to suit a vocal few. If people are incapable of reading
the website then it's their own damn fault for being idiots. There is
no evidence to suggest that the vocal few represent the community at
large - people who complain will always be heard because everyone else
is either too happy or too indifferent to bother writing an email. It
may be worth considering a standard text block to add to future
standards to explain what the standard is, how it was formulated, and
that FIG is independent of any "official" PHP group or authority.

Paddy

--
Pádraic Brady

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

> --
> 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/msg/php-fig/-/Gku8v-IJ-mAJ.

[Amy Stephen]

Paddy - when I can respond in 4 tweet or less, I will answer this. For now, I want you to know I read your comments and appreciate your respectful perspective.

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/BIs5ZyqPc1E/unsubscribe?hl=en.
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.

[Drak]

FYI - They don't vanish anymore. They are linked to. e.g.  skyzyx discussed an outdated diff 6 days ago Show outdated diff

[Amy Stephen]

Added ideas on structure https://groups.google.com/d/msg/php-fig/-M977NUKF00/moHMedwLb1UJ

[Phil Sturgeon]

As I said on that PR, commenting on a PR is perfectly acceptable if its about the text or message of a PR. If these comments raise a conversation about policy or politics then it needs to be spun into its own mailing list conversation. 

Now, issues I definitely agree with being turned off. Pull Requests are a valid conversation point (as long as its not policy or politics, which should be done over here). I think there are more than enough channels of communication already.

https://github.com/php-fig/fig-standards/issues

There are a bunch of issues here which are just people asking questions, or making proposals completely incorrectly. If they were being moderated correctly and having their questions answered, or linked to useful resources, or anything, then this would be less of a problem but they are just sitting there doing nothing and that helps nobody. I'm happy to help moderate, I can even be nice about it.

Having a CONTRIBUTING.md would definitely help and changing to fig-psr's would help too. Standard Recommendation are more accurate to the goals of the group when used together than separately, so less folks will freak out over seing the word "standard" by itself.

[Amy Stephen]

Phil - I am resigned to the fact that we are not going to agree on what happened in that thread. I do understand your right to stop a discussion and, as you have indicated, I am to accept that I am never to say a word following your instruction that the discussion is now complete. As an adult, maybe even especially as an older adult ;-), I personally find that approach outputting. That's not your fault, it's a result of a moderator structure and the defiant person I can be.

If you read the link I just shared, there are ways to create a structure that prevents discussion and proposals that aren't desired. In the case of the tabs-vs-spaces gang war, no one should have been able to comment on a closed discussion. They should have read it, been annoyed, walked away. The group was no longer inviting comment and should have ensured there wasn't a gate open for comment. 

In my suggestion, Google Group Communities would be created for each proposal. When that proposal was complete, the community would be closed, archiving the discussing, closing the gate for more input.

In the case you are describing, the rule is no discussion in the proposal. All discussion should take place on list. So, why open the gate for discussion in a proposal? There is nothing that warns people as they post. There is no "Read the Rules First" indicator on the page. Even if you go to the home page and read the rule about submitting proposals, it doesn't say not to discuss in the issue. There is no where that rule is listed. So, there is a gate open for input, no indication that input is not needed, which means every time it happens, someone with authority must stop adults from using the gate.

At best, that's just creating unnecessary, at worst, it's creating hostility.

In my link (above), I suggest getting the proposals off of github where discussion areas appear and cannot be closed with PRs. Instead, have those emailed and then displayed for comment. When a vote comes for which are accepted and which are rejected, post the results and create a community group for the active projects.

In getting ahead of the problem, opening gates where input is needed, closing gates where it's not needed, a group can move away from most moderation. No matter how nicely it's implemented, telling a grown adult publicly that they are not allowed to say something or that they asked in the wrong place, or that their discussion is not fruitful or useful to the group, etc., is difficult.

--
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/BIs5ZyqPc1E/unsubscribe?hl=en.
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/msg/php-fig/-/PcleXz0Je0cJ.

[Pádraic Brady]

Hi Phil,

I think issues just need moderation, i.e. someone who can close the
obviously trivial or redirect proposals to PRs and then close them.
There are valid points to raise as issues and people may not be as
inclined to use the ML. I agree it sounds a bit like panning for gold
though. Lots of work, few gold specks ;).

Paddy

--
Pádraic Brady

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

> --
> 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

[Pádraic Brady]

Will probably take me another day to catch up on the workflow discussion...

Amy, I think a group or WG per large proposal (excl. trivial PRs and
bylaws) would be nice. We'd need FIG members to steer each basically
as a moderator to ensure it runs without getting too distracted or
bogged down. The main risk is opening up so many channels of
communication that monitoring them all becomes too much of an effort
for our time-deprived members. Replying to PR feedback is pretty
tempting so that's a hard one to enforce I think. It just takes one
comment and the need to respond boils up ;).

Paddy

--
Pádraic Brady

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

> 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.

[Phil Sturgeon]

Amy: it's a good thing I wasn't talking about that PR then :)

P: I guess next to the whole workflow in general conversation, we need to close down some channels of communication. I've been moderation by proxy through Paul D but issues just not being there would be much better. I'd like some other people's opinions on this.

[Amy Stephen]

=)

Yea, I think it'd help. As the group gets more and more known, and it will, ensuring people can only provide input where you want it will save a lot of trouble.

Thanks Phil.

On Fri, Mar 8, 2013 at 6:26 AM, Phil Sturgeon <em...@philsturgeon.co.uk> wrote:

Amy: it's a good thing I wasn't talking about that PR then :)

P: I guess next to the whole workflow in general conversation, we need to close down some channels of communication. I've been moderation by proxy through Paul D but issues just not being there would be much better. I'd like some other people's opinions on this.

--
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/BIs5ZyqPc1E/unsubscribe?hl=en.
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/msg/php-fig/-/hUvG5-QHGU4J.

[Larry Garfield]

On 03/08/2013 06:26 AM, Phil Sturgeon wrote:
> Amy: it's a good thing I wasn't talking about that PR then :)
>
> P: I guess next to the whole workflow in general conversation, we need to close down some channels of communication. I've been moderation by proxy through Paul D but issues just not being there would be much better. I'd like some other people's opinions on this.

If we don't want people using issues, remove issues entirely. Problem
solved.

+1 from me.

--Larry Garfield