Zend Framework Community › ZF Contributor

Community Review Team

Classic

List

Threaded

24 messages Options

weierophinney

Community Review Team

Administrator

As a follow-up to the discussions last week, I'm going to open several
emails to cover some topics individually.

In this email: the ZF Community Committee proposal

In order for something to work, we need to establish clear guidelines to
measure success by. In other words, I don't want the responsiblities to
be vague.

First, I think a better name might be in order, something along the
lines of "ZF Review Team" (or some other name involving the word
"Team"). "Committee" implies bureaucracy, which implies layered
processes and red tape to me. "Team" better captures an idea of
camarderie and people working together towards a common goal. As for
"Review", I think it may make sense, considering the guidelines I'll
outline below.

Based on Ryan's email, and also some discussion on IRC, with Zeev, and
with my team, I'm thinking the following make sense:

* Assist contributors in getting patches and features into existing
components.
* Act as liaison for contacting a maintainer on behalf of a
contributor
* If the maintainer refuses to accept a patch, act as an arbiter
between the contributor and the maintainer
* If the maintainer does not respond after a set period of time,
would evaluate and/or apply the patch for the contributor
* Would issue pull requests to the Zend team in such instances as the
above
* Identify orphaned components
* Would identify when a component is no longer under active
maintenance
* Solicit volunteers to take over maintenance of orphaned components
* Decide when an orphaned component should be marked as such and
scheduled for removal (Note: removal can only happen in major
revisions)
* Shepherd new proposals.
* Solicit community feedback on proposals
* Would put competing proposal authors in touch with each other to
work on a unified proposal
* Provide feedback on proposals (including initial decision as to
whether or not there is enough community interest in including the
proposed functionality in the framework)
* Would notify the Zend team when a proposal is ready
* Would do initial code review on the proposal implementation
* Would notify the Zend team when the proposed feature is feature
complete and ready to pull into the master branch

While some specifics still need to be considered (how long to wait for a
maintainer's response? how long to wait until a component is considered
unmaintained? etc.), I think this shows a fairly clear set of
responsibilities, and also gives a sense of how much work might be
required by those members on the team.

I can envisage probably 12-16 hours of work to split between several
members -- so maybe as little as an hour of dedicated time each day.

Also, another point to consider: we should probably define a regular
review period for the team, to see who is able to live up to the
requirements, and how successful the team has been in meeting the
requirements as a whole. Along with this would be a plan for soliciting
new members for the team in the event that somebody is unable to
continue.

Any additions or changes any of you would like to make? And who might be
interested? :)

--
Matthew Weier O'Phinney
Project Lead | [hidden email]
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

Court Ewing

Re: Community Review Team

How will this team be chosen? How large of a team are you envisioning?

On Thu, Jun 3, 2010 at 2:26 PM, Matthew Weier O'Phinney <[hidden email]> wrote:

As a follow-up to the discussions last week, I'm going to open several
emails to cover some topics individually.

In this email: the ZF Community Committee proposal

In order for something to work, we need to establish clear guidelines to
measure success by. In other words, I don't want the responsiblities to
be vague.

First, I think a better name might be in order, something along the
lines of "ZF Review Team" (or some other name involving the word
"Team"). "Committee" implies bureaucracy, which implies layered
processes and red tape to me. "Team" better captures an idea of
camarderie and people working together towards a common goal. As for
"Review", I think it may make sense, considering the guidelines I'll
outline below.

Based on Ryan's email, and also some discussion on IRC, with Zeev, and
with my team, I'm thinking the following make sense:

* Assist contributors in getting patches and features into existing
components.
* Act as liaison for contacting a maintainer on behalf of a
contributor
* If the maintainer refuses to accept a patch, act as an arbiter
between the contributor and the maintainer
* If the maintainer does not respond after a set period of time,
would evaluate and/or apply the patch for the contributor
* Would issue pull requests to the Zend team in such instances as the
above
* Identify orphaned components
* Would identify when a component is no longer under active
maintenance
* Solicit volunteers to take over maintenance of orphaned components
* Decide when an orphaned component should be marked as such and
scheduled for removal (Note: removal can only happen in major
revisions)
* Shepherd new proposals.
* Solicit community feedback on proposals
* Would put competing proposal authors in touch with each other to
work on a unified proposal
* Provide feedback on proposals (including initial decision as to
whether or not there is enough community interest in including the
proposed functionality in the framework)
* Would notify the Zend team when a proposal is ready
* Would do initial code review on the proposal implementation
* Would notify the Zend team when the proposed feature is feature
complete and ready to pull into the master branch

While some specifics still need to be considered (how long to wait for a
maintainer's response? how long to wait until a component is considered
unmaintained? etc.), I think this shows a fairly clear set of
responsibilities, and also gives a sense of how much work might be
required by those members on the team.

I can envisage probably 12-16 hours of work to split between several
members -- so maybe as little as an hour of dedicated time each day.

Also, another point to consider: we should probably define a regular
review period for the team, to see who is able to live up to the
requirements, and how successful the team has been in meeting the
requirements as a whole. Along with this would be a plan for soliciting
new members for the team in the event that somebody is unable to
continue.

Any additions or changes any of you would like to make? And who might be
interested? :)

--
Matthew Weier O'Phinney
Project Lead | [hidden email]
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

weierophinney

Re: Community Review Team

Administrator

-- Court Ewing <[hidden email]> wrote
(on Thursday, 03 June 2010, 02:34 PM -0400):
> How will this team be chosen? How large of a team are you envisioning?

For now, I was hoping the team would be self-selecting -- but if we have
a lot of people interested, we can hold a vote using either the polling
functionality in Confluence or a Google Spreadsheets form.

The team should likely be at least 3 people, but probably shouldn't be
much bigger than 6 -- too few people, and there's too much work; too
many, and it's hard to coordinate.

> On Thu, Jun 3, 2010 at 2:26 PM, Matthew Weier O'Phinney <[hidden email]>
> wrote:
>
> As a follow-up to the discussions last week, I'm going to open several
> emails to cover some topics individually.
>
> In this email: the ZF Community Committee proposal
>
> In order for something to work, we need to establish clear guidelines to
> measure success by. In other words, I don't want the responsiblities to
> be vague.
>
> First, I think a better name might be in order, something along the
> lines of "ZF Review Team" (or some other name involving the word
> "Team"). "Committee" implies bureaucracy, which implies layered
> processes and red tape to me. "Team" better captures an idea of
> camarderie and people working together towards a common goal. As for
> "Review", I think it may make sense, considering the guidelines I'll
> outline below.
>
> Based on Ryan's email, and also some discussion on IRC, with Zeev, and
> with my team, I'm thinking the following make sense:
>
> * Assist contributors in getting patches and features into existing
> components.
> * Act as liaison for contacting a maintainer on behalf of a
> contributor
> * If the maintainer refuses to accept a patch, act as an arbiter
> between the contributor and the maintainer
> * If the maintainer does not respond after a set period of time,
> would evaluate and/or apply the patch for the contributor
> * Would issue pull requests to the Zend team in such instances as the
> above
> * Identify orphaned components
> * Would identify when a component is no longer under active
> maintenance
> * Solicit volunteers to take over maintenance of orphaned components
> * Decide when an orphaned component should be marked as such and
> scheduled for removal (Note: removal can only happen in major
> revisions)
> * Shepherd new proposals.
> * Solicit community feedback on proposals
> * Would put competing proposal authors in touch with each other to
> work on a unified proposal
> * Provide feedback on proposals (including initial decision as to
> whether or not there is enough community interest in including the
> proposed functionality in the framework)
> * Would notify the Zend team when a proposal is ready
> * Would do initial code review on the proposal implementation
> * Would notify the Zend team when the proposed feature is feature
> complete and ready to pull into the master branch
>
> While some specifics still need to be considered (how long to wait for a
> maintainer's response? how long to wait until a component is considered
> unmaintained? etc.), I think this shows a fairly clear set of
> responsibilities, and also gives a sense of how much work might be
> required by those members on the team.
>
> I can envisage probably 12-16 hours of work to split between several
> members -- so maybe as little as an hour of dedicated time each day.
>
> Also, another point to consider: we should probably define a regular
> review period for the team, to see who is able to live up to the
> requirements, and how successful the team has been in meeting the
> requirements as a whole. Along with this would be a plan for soliciting
> new members for the team in the event that somebody is unable to
> continue.
>
> Any additions or changes any of you would like to make? And who might be
> interested? :)
>
> --
> Matthew Weier O'Phinney
> Project Lead | [hidden email]
> Zend Framework | http://framework.zend.com/
> PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
>
>

--
Matthew Weier O'Phinney
Project Lead | [hidden email]
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

padraicb

Re: Community Review Team

In reply to this post by weierophinney

The list seems fairly comprehensive, though I do hope the estimated 1hr per day is subject to flexitime ;). The missing requirements (review periods, etc) may need some early clarification so volunteers have a better grasp of what they are getting into and whether they can meet those requirements. At the moment, it's vague enough I'm tempted to volunteer yet not entirely sure if it's flexible enough to withstand my occasional periods of busy-ness and late nights. Maybe that is the point though - maybe I'm not an ideal candidate.

I am curious about the team count. Several suggests something in the region of 2-3 members. I would have expected, given the volunteer base, something closer to 5-6+. I don't see a problem finding 6 people from the community who are more than capable for the role. Is there a reason for the implied count restriction (assuming it was implied at all).

Paddy

Pádraic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com
OpenID Europe Foundation Irish Representative

From: Matthew Weier O'Phinney <[hidden email]>
To: [hidden email]
Sent: Thu, June 3, 2010 7:26:54 PM
Subject: [zf-contributors] Community Review Team

As a follow-up to the discussions last week, I'm going to open several
emails to cover some topics individually.

In this email: the ZF Community Committee proposal

In order for something to work, we need to establish clear guidelines to
measure success by. In other words, I don't want the responsiblities to
be vague.

First, I think a better name might be in order, something along the
lines of "ZF Review Team" (or some other name involving the word
"Team"). "Committee" implies bureaucracy, which implies layered
processes and red tape to me. "Team" better captures an idea of
camarderie and people working together towards a common goal. As for
"Review", I think it may make sense, considering the guidelines I'll
outline below.

Based on Ryan's email, and also some discussion on IRC, with Zeev, and
with my team, I'm thinking the following make sense:

* Assist contributors in getting patches and features into existing
components.
* Act as liaison for contacting a maintainer on behalf of a
contributor
* If the maintainer refuses to accept a patch, act as an arbiter
between the contributor and the maintainer
* If the maintainer does not respond after a set period of time,
would evaluate and/or apply the patch for the contributor
* Would issue pull requests to the Zend team in such instances as the
above
* Identify orphaned components
* Would identify when a component is no longer under active
maintenance
* Solicit volunteers to take over maintenance of orphaned components
* Decide when an orphaned component should be marked as such and
scheduled for removal (Note: removal can only happen in major
revisions)
* Shepherd new proposals.
* Solicit community feedback on proposals
* Would put competing proposal authors in touch with each other to
work on a unified proposal
* Provide feedback on proposals (including initial decision as to
whether or not there is enough community interest in including the
proposed functionality in the framework)
* Would notify the Zend team when a proposal is ready
* Would do initial code review on the proposal implementation
* Would notify the Zend team when the proposed feature is feature
complete and ready to pull into the master branch

While some specifics still need to be considered (how long to wait for a
maintainer's response? how long to wait until a component is considered
unmaintained? etc.), I think this shows a fairly clear set of
responsibilities, and also gives a sense of how much work might be
required by those members on the team.

I can envisage probably 12-16 hours of work to split between several
members -- so maybe as little as an hour of dedicated time each day.

Also, another point to consider: we should probably define a regular
review period for the team, to see who is able to live up to the
requirements, and how successful the team has been in meeting the
requirements as a whole. Along with this would be a plan for soliciting
new members for the team in the event that somebody is unable to
continue.

Any additions or changes any of you would like to make? And who might be
interested? :)

--
Matthew Weier O'Phinney
Project Lead | [hidden email]
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

weierophinney

Re: Community Review Team

Administrator

-- Pádraic Brady <[hidden email]> wrote
(on Thursday, 03 June 2010, 12:02 PM -0700):
> The list seems fairly comprehensive, though I do hope the estimated 1hr per day
> is subject to flexitime ;). The missing requirements (review periods, etc) may
> need some early clarification so volunteers have a better grasp of what they
> are getting into and whether they can meet those requirements. At the moment,
> it's vague enough I'm tempted to volunteer yet not entirely sure if it's
> flexible enough to withstand my occasional periods of busy-ness and late
> nights. Maybe that is the point though - maybe I'm not an ideal candidate.

If we have somewhere in the neighborhood of 5-7 folks, and you
communicate when you're busy, I don't see a problem. :)

> I am curious about the team count. Several suggests something in the region of
> 2-3 members. I would have expected, given the volunteer base, something closer
> to 5-6+. I don't see a problem finding 6 people from the community who are more
> than capable for the role. Is there a reason for the implied count restriction
> (assuming it was implied at all).

I think 3 is a _minimum_ number... and honestly, think 7 should be a
maximum, since the communication issues get to be tricky when the
numbers get larger. (I think 7 would be a great number, honestly) But
I'm open to arguments. :)

> ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
> From: Matthew Weier O'Phinney <[hidden email]>
> To: [hidden email]
> Sent: Thu, June 3, 2010 7:26:54 PM
> Subject: [zf-contributors] Community Review Team
>
> As a follow-up to the discussions last week, I'm going to open several
> emails to cover some topics individually.
>
> In this email: the ZF Community Committee proposal
>
> In order for something to work, we need to establish clear guidelines to
> measure success by. In other words, I don't want the responsiblities to
> be vague.
>
> First, I think a better name might be in order, something along the
> lines of "ZF Review Team" (or some other name involving the word
> "Team"). "Committee" implies bureaucracy, which implies layered
> processes and red tape to me. "Team" better captures an idea of
> camarderie and people working together towards a common goal. As for
> "Review", I think it may make sense, considering the guidelines I'll
> outline below.
>
> Based on Ryan's email, and also some discussion on IRC, with Zeev, and
> with my team, I'm thinking the following make sense:
>
> * Assist contributors in getting patches and features into existing
> components.
> * Act as liaison for contacting a maintainer on behalf of a
> contributor
> * If the maintainer refuses to accept a patch, act as an arbiter
> between the contributor and the maintainer
> * If the maintainer does not respond after a set period of time,
> would evaluate and/or apply the patch for the contributor
> * Would issue pull requests to the Zend team in such instances as the
> above
> * Identify orphaned components
> * Would identify when a component is no longer under active
> maintenance
> * Solicit volunteers to take over maintenance of orphaned components
> * Decide when an orphaned component should be marked as such and
> scheduled for removal (Note: removal can only happen in major
> revisions)
> * Shepherd new proposals.
> * Solicit community feedback on proposals
> * Would put competing proposal authors in touch with each other to
> work on a unified proposal
> * Provide feedback on proposals (including initial decision as to
> whether or not there is enough community interest in including the
> proposed functionality in the framework)
> * Would notify the Zend team when a proposal is ready
> * Would do initial code review on the proposal implementation
> * Would notify the Zend team when the proposed feature is feature
> complete and ready to pull into the master branch
>
> While some specifics still need to be considered (how long to wait for a
> maintainer's response? how long to wait until a component is considered
> unmaintained? etc.), I think this shows a fairly clear set of
> responsibilities, and also gives a sense of how much work might be
> required by those members on the team.
>
> I can envisage probably 12-16 hours of work to split between several
> members -- so maybe as little as an hour of dedicated time each day.
>
> Also, another point to consider: we should probably define a regular
> review period for the team, to see who is able to live up to the
> requirements, and how successful the team has been in meeting the
> requirements as a whole. Along with this would be a plan for soliciting
> new members for the team in the event that somebody is unable to
> continue.
>
> Any additions or changes any of you would like to make? And who might be
> interested? :)
>
> --
> Matthew Weier O'Phinney
> Project Lead | [hidden email]
> Zend Framework | http://framework.zend.com/
> PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

--
Matthew Weier O'Phinney
Project Lead | [hidden email]
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

Pieter Kokx

Re: Community Review Team

On 03-06-10 21:19, Matthew Weier O'Phinney wrote:

> -- Pádraic Brady <[hidden email]> wrote
> (on Thursday, 03 June 2010, 12:02 PM -0700):
>> The list seems fairly comprehensive, though I do hope the estimated 1hr per day
>> is subject to flexitime ;). The missing requirements (review periods, etc) may
>> need some early clarification so volunteers have a better grasp of what they
>> are getting into and whether they can meet those requirements. At the moment,
>> it's vague enough I'm tempted to volunteer yet not entirely sure if it's
>> flexible enough to withstand my occasional periods of busy-ness and late
>> nights. Maybe that is the point though - maybe I'm not an ideal candidate.
>
> If we have somewhere in the neighborhood of 5-7 folks, and you
> communicate when you're busy, I don't see a problem. :)
>> I am curious about the team count. Several suggests something in the region of
>> 2-3 members. I would have expected, given the volunteer base, something closer
>> to 5-6+. I don't see a problem finding 6 people from the community who are more
>> than capable for the role. Is there a reason for the implied count restriction
>> (assuming it was implied at all).
>
> I think 3 is a _minimum_ number... and honestly, think 7 should be a
> maximum, since the communication issues get to be tricky when the
> numbers get larger. (I think 7 would be a great number, honestly) But
> I'm open to arguments. :)

With 7 people, it might get a little too busy. I would think that about
5 people would be better. And of course it is always possible to do
elections (or however the team members are chosen) for extra members of
the team when it turns out that the workload is too high. While it is a
lot more difficult to remove members from the team (the decision of
which person should leave the team is never easy).

>
>> ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
>> From: Matthew Weier O'Phinney <[hidden email]>
>> To: [hidden email]
>> Sent: Thu, June 3, 2010 7:26:54 PM
>> Subject: [zf-contributors] Community Review Team
>>
>> As a follow-up to the discussions last week, I'm going to open several
>> emails to cover some topics individually.
>>
>> In this email: the ZF Community Committee proposal
>>
>> In order for something to work, we need to establish clear guidelines to
>> measure success by. In other words, I don't want the responsiblities to
>> be vague.
>>
>> First, I think a better name might be in order, something along the
>> lines of "ZF Review Team" (or some other name involving the word
>> "Team"). "Committee" implies bureaucracy, which implies layered
>> processes and red tape to me. "Team" better captures an idea of
>> camarderie and people working together towards a common goal. As for
>> "Review", I think it may make sense, considering the guidelines I'll
>> outline below.
>>
>> Based on Ryan's email, and also some discussion on IRC, with Zeev, and
>> with my team, I'm thinking the following make sense:
>>
>> * Assist contributors in getting patches and features into existing
>> components.
>> * Act as liaison for contacting a maintainer on behalf of a
>> contributor
>> * If the maintainer refuses to accept a patch, act as an arbiter
>> between the contributor and the maintainer
>> * If the maintainer does not respond after a set period of time,
>> would evaluate and/or apply the patch for the contributor
>> * Would issue pull requests to the Zend team in such instances as the
>> above
>> * Identify orphaned components
>> * Would identify when a component is no longer under active
>> maintenance
>> * Solicit volunteers to take over maintenance of orphaned components
>> * Decide when an orphaned component should be marked as such and
>> scheduled for removal (Note: removal can only happen in major
>> revisions)
>> * Shepherd new proposals.
>> * Solicit community feedback on proposals
>> * Would put competing proposal authors in touch with each other to
>> work on a unified proposal
>> * Provide feedback on proposals (including initial decision as to
>> whether or not there is enough community interest in including the
>> proposed functionality in the framework)
>> * Would notify the Zend team when a proposal is ready
>> * Would do initial code review on the proposal implementation
>> * Would notify the Zend team when the proposed feature is feature
>> complete and ready to pull into the master branch
>>
>> While some specifics still need to be considered (how long to wait for a
>> maintainer's response? how long to wait until a component is considered
>> unmaintained? etc.), I think this shows a fairly clear set of
>> responsibilities, and also gives a sense of how much work might be
>> required by those members on the team.
>>
>> I can envisage probably 12-16 hours of work to split between several
>> members -- so maybe as little as an hour of dedicated time each day.
>>
>> Also, another point to consider: we should probably define a regular
>> review period for the team, to see who is able to live up to the
>> requirements, and how successful the team has been in meeting the
>> requirements as a whole. Along with this would be a plan for soliciting
>> new members for the team in the event that somebody is unable to
>> continue.
>>
>> Any additions or changes any of you would like to make? And who might be
>> interested? :)
>>
>> --
>> Matthew Weier O'Phinney
>> Project Lead | [hidden email]
>> Zend Framework | http://framework.zend.com/
>> PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
>

padraicb

Re: Community Review Team

In reply to this post by weierophinney

No, I agree 6/7 should be the absolute maximum - we don't need to flirt with a complete breakdown into anarchy ;)

In that case, I volunteer my time.

Pádraic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com
OpenID Europe Foundation Irish Representative

From: Matthew Weier O'Phinney <[hidden email]>
To: Zend Framework Contributors <[hidden email]>
Sent: Thu, June 3, 2010 8:19:05 PM
Subject: Re: [zf-contributors] Community Review Team

-- Pádraic Brady <[hidden email]> wrote
(on Thursday, 03 June 2010, 12:02 PM -0700):
> The list seems fairly comprehensive, though I do hope the estimated 1hr per day
> is subject to flexitime ;). The missing requirements (review periods, etc) may
> need some early clarification so volunteers have a better grasp of what they
> are getting into and whether they can meet those requirements. At the moment,
> it's vague enough I'm tempted to volunteer yet not entirely sure if it's
> flexible enough to withstand my occasional periods of busy-ness and late
> nights. Maybe that is the point though - maybe I'm not an ideal candidate.

If we have somewhere in the neighborhood of 5-7 folks, and you
communicate when you're busy, I don't see a problem. :)

> I am curious about the team count. Several suggests something in the region of
> 2-3 members. I would have expected, given the volunteer base, something closer
> to 5-6+. I don't see a problem finding 6 people from the community who are more
> than capable for the role. Is there a reason for the implied count restriction
> (assuming it was implied at all).

I think 3 is a _minimum_ number... and honestly, think 7 should be a
maximum, since the communication issues get to be tricky when the
numbers get larger. (I think 7 would be a great number, honestly) But
I'm open to arguments. :)

> Zend Framework | http://framework.zend.com/
> PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

--
Matthew Weier O'Phinney
Project Lead | [hidden email]
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

padraicb

Re: Community Review Team

In reply to this post by Pieter Kokx

Maybe just it clear to everyone who gets voted in that it's for a fixed term. After that, you can continue volunteering, or go through voting again if the team size is inappropriate (probably when appropriate - not sure if there's any intent for annual/periodical re-voting for everyone). I agree it's hard to remove people, so we might as well build some honestly/bluntness into the conditions of the team from the start. I'd prefer that to what may end up as a LIFO system which rewards service length over other attributes.

That said, I don't think many of us have egos so incredibly huge we'd get upset after being asked to leave because the team size needs a trim.

Pádraic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com
OpenID Europe Foundation Irish Representative

From: Pieter Kokx <[hidden email]>
To: [hidden email]
Sent: Thu, June 3, 2010 8:27:52 PM
Subject: Re: [zf-contributors] Community Review Team

On 03-06-10 21:19, Matthew Weier O'Phinney wrote:

>> Zend Framework | http://framework.zend.com/
>> PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
>

Shawn Stratton

Re: Community Review Team

In reply to this post by padraicb

Two cents time, depending on volume of people volunteering, do what
the PEAR community has done and have elections, I personally think
that a lot of people will volunteer just because it's another
something to claim in your title or your resume (sorry people but
that's reality in open source projects as well.)

Shawn Stratton
Zend Certified Engineer
phpDocumentor 2 Developer

On Thu, Jun 3, 2010 at 3:33 PM, Pádraic Brady <[hidden email]> wrote:

> No, I agree 6/7 should be the absolute maximum - we don't need to flirt with
> a complete breakdown into anarchy ;)
>
> In that case, I volunteer my time.
>
> Pádraic Brady
>
> http://blog.astrumfutura.com
> http://www.survivethedeepend.com
> OpenID Europe Foundation Irish Representative
>
>
> ________________________________
> From: Matthew Weier O'Phinney <[hidden email]>
> To: Zend Framework Contributors <[hidden email]>
> Sent: Thu, June 3, 2010 8:19:05 PM
> Subject: Re: [zf-contributors] Community Review Team
>
> -- Pádraic Brady <[hidden email]> wrote
> (on Thursday, 03 June 2010, 12:02 PM -0700):
>> The list seems fairly comprehensive, though I do hope the estimated 1hr
>> per day
>> is subject to flexitime ;). The missing requirements (review periods, etc)
>> may
>> need some early clarification so volunteers have a better grasp of what
>> they
>> are getting into and whether they can meet those requirements. At the
>> moment,
>> it's vague enough I'm tempted to volunteer yet not entirely sure if it's
>> flexible enough to withstand my occasional periods of busy-ness and late
>> nights. Maybe that is the point though - maybe I'm not an ideal candidate.
>
> If we have somewhere in the neighborhood of 5-7 folks, and you
> communicate when you're busy, I don't see a problem. :)
>
>> I am curious about the team count. Several suggests something in the
>> region of
>> 2-3 members. I would have expected, given the volunteer base, something
>> closer
>> to 5-6+. I don't see a problem finding 6 people from the community who are
>> more
>> than capable for the role. Is there a reason for the implied count
>> restriction
>> (assuming it was implied at all).
>
> I think 3 is a _minimum_ number... and honestly, think 7 should be a
> maximum, since the communication issues get to be tricky when the
> numbers get larger. (I think 7 would be a great number, honestly) But
> I'm open to arguments. :)
>
>
>>
>> ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
>> From: Matthew Weier O'Phinney <[hidden email]>
>> To: [hidden email]
>> Sent: Thu, June 3, 2010 7:26:54 PM
>> Subject: [zf-contributors] Community Review Team
>>
>> As a follow-up to the discussions last week, I'm going to open several
>> emails to cover some topics individually.
>>
>> In this email: the ZF Community Committee proposal
>>
>> In order for something to work, we need to establish clear guidelines to
>> measure success by. In other words, I don't want the responsiblities to
>> be vague.
>>
>> First, I think a better name might be in order, something along the
>> lines of "ZF Review Team" (or some other name involving the word
>> "Team"). "Committee" implies bureaucracy, which implies layered
>> processes and red tape to me. "Team" better captures an idea of
>> camarderie and people working together towards a common goal. As for
>> "Review", I think it may make sense, considering the guidelines I'll
>> outline below.
>>
>> Based on Ryan's email, and also some discussion on IRC, with Zeev, and
>> with my team, I'm thinking the following make sense:
>>
>> * Assist contributors in getting patches and features into existing
>> components.
>> * Act as liaison for contacting a maintainer on behalf of a
>> contributor
>> * If the maintainer refuses to accept a patch, act as an arbiter
>> between the contributor and the maintainer
>> * If the maintainer does not respond after a set period of time,
>> would evaluate and/or apply the patch for the contributor
>> * Would issue pull requests to the Zend team in such instances as the
>> above
>> * Identify orphaned components
>> * Would identify when a component is no longer under active
>> maintenance
>> * Solicit volunteers to take over maintenance of orphaned components
>> * Decide when an orphaned component should be marked as such and
>> scheduled for removal (Note: removal can only happen in major
>> revisions)
>> * Shepherd new proposals.
>> * Solicit community feedback on proposals
>> * Would put competing proposal authors in touch with each other to
>> work on a unified proposal
>> * Provide feedback on proposals (including initial decision as to
>> whether or not there is enough community interest in including the
>> proposed functionality in the framework)
>> * Would notify the Zend team when a proposal is ready
>> * Would do initial code review on the proposal implementation
>> * Would notify the Zend team when the proposed feature is feature
>> complete and ready to pull into the master branch
>>
>> While some specifics still need to be considered (how long to wait for a
>> maintainer's response? how long to wait until a component is considered
>> unmaintained? etc.), I think this shows a fairly clear set of
>> responsibilities, and also gives a sense of how much work might be
>> required by those members on the team.
>>
>> I can envisage probably 12-16 hours of work to split between several
>> members -- so maybe as little as an hour of dedicated time each day.
>>
>> Also, another point to consider: we should probably define a regular
>> review period for the team, to see who is able to live up to the
>> requirements, and how successful the team has been in meeting the
>> requirements as a whole. Along with this would be a plan for soliciting
>> new members for the team in the event that somebody is unable to
>> continue.
>>
>> Any additions or changes any of you would like to make? And who might be
>> interested? :)
>>
>> --
>> Matthew Weier O'Phinney
>> Project Lead | [hidden email]
>> Zend Framework | http://framework.zend.com/
>> PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
>
> --
> Matthew Weier O'Phinney
> Project Lead | [hidden email]
> Zend Framework | http://framework.zend.com/
> PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
>

akrabat

Re: Community Review Team

In reply to this post by padraicb

On 3 Jun 2010, at 20:33, Pádraic Brady wrote:

> No, I agree 6/7 should be the absolute maximum - we don't need to flirt with a complete breakdown into anarchy ;)
>
> In that case, I volunteer my time.
>
> Pádraic Brady
>

I tend to agree with 6/7.

I'm similar to Pádraic, with my occasional bouts of business and I also volunteer.

Regards,

Rob...

--
Rob Allen : http://akrabat.com
Zend Framework Tutorial: http://akrabat.com/zft
Author of Zend Framework in Action: http://www.zendframeworkinaction.com

Steven Brown-2

RE: Community Review Team

/me puts his hand up

-----Original Message-----
From: Rob Allen [mailto:[hidden email]]
Sent: Friday, 4 June 2010 7:25 AM
To: Zend Framework Contributors
Subject: Re: [zf-contributors] Community Review Team

On 3 Jun 2010, at 20:33, Pádraic Brady wrote:

> No, I agree 6/7 should be the absolute maximum - we don't need to flirt
with a complete breakdown into anarchy ;)
>
> In that case, I volunteer my time.
>
> Pádraic Brady
>

I tend to agree with 6/7.

I'm similar to Pádraic, with my occasional bouts of business and I also
volunteer.

Regards,

Rob...

--
Rob Allen : http://akrabat.com
Zend Framework Tutorial: http://akrabat.com/zft
Author of Zend Framework in Action: http://www.zendframeworkinaction.com

Shaun Farrell

Re: Community Review Team

Agree with Paddy and Matt on this one. More than 7 would bring in to much bureaucracy and that's not what is needed. I think if you start with a lower number and see how that works its always easier to add more than to subtract. That's just my thought.

I think this is a great idea and kudos to the framework team, the community and Zend for suggesting this!

With that said I am always willing to help where I can so I'll put my hat in the ring.

Shaun J. Farrell
Washington, DC

On Thu, Jun 3, 2010 at 5:44 PM, Steven Brown <[hidden email]> wrote:

/me puts his hand up

-----Original Message-----
From: Rob Allen [mailto:[hidden email]]
Sent: Friday, 4 June 2010 7:25 AM
To: Zend Framework Contributors
Subject: Re: [zf-contributors] Community Review Team

On 3 Jun 2010, at 20:33, Pádraic Brady wrote:

> No, I agree 6/7 should be the absolute maximum - we don't need to flirt
with a complete breakdown into anarchy ;)
>
> In that case, I volunteer my time.
>
> Pádraic Brady
>

I tend to agree with 6/7.

I'm similar to Pádraic, with my occasional bouts of business and I also
volunteer.

Regards,

Rob...

--
Rob Allen : http://akrabat.com
Zend Framework Tutorial: http://akrabat.com/zft
Author of Zend Framework in Action: http://www.zendframeworkinaction.com

Vic Farazdagi

Re: Community Review Team

In reply to this post by Shawn Stratton

On 06/04/2010 12:04 AM, Shawn Stratton wrote:
> Two cents time, depending on volume of people volunteering, do what
> the PEAR community has done and have elections, I personally think
> that a lot of people will volunteer just because it's another
> something to claim in your title or your resume (sorry people but
> that's reality in open source projects as well.)
>
Voting could ensure that there's no objections to selection criteria,
but I suppose if we think of a team of 5-7 ppl, we already have a
"de-facto" review team - those who tend to power the ml/irc/wiki etc
discussions. We can have that voting - but more crucially, as Pádraic
already suggested, it is important to clarify the requirements - as
Review Team is not about attaching yet another title/tag near your name,
it's about responsibilities.

In any case, I didn't see that there were serious flaws in ZF
development before (with probably exception for proposal process), but
with such a comprehensive list Matthew presented, and provided RT would
be up to task - well, ZF project seems on the right track.

Thanks,
Vic

> Shawn Stratton
> Zend Certified Engineer
> phpDocumentor 2 Developer
>
>
>
> On Thu, Jun 3, 2010 at 3:33 PM, Pádraic Brady<[hidden email]> wrote:
>
>> No, I agree 6/7 should be the absolute maximum - we don't need to flirt with
>> a complete breakdown into anarchy ;)
>>
>> In that case, I volunteer my time.
>>
>> Pádraic Brady
>>
>> http://blog.astrumfutura.com
>> http://www.survivethedeepend.com
>> OpenID Europe Foundation Irish Representative
>>
>>
>> ________________________________
>> From: Matthew Weier O'Phinney<[hidden email]>
>> To: Zend Framework Contributors<[hidden email]>
>> Sent: Thu, June 3, 2010 8:19:05 PM
>> Subject: Re: [zf-contributors] Community Review Team
>>
>> -- Pádraic Brady<[hidden email]> wrote
>> (on Thursday, 03 June 2010, 12:02 PM -0700):
>>
>>> The list seems fairly comprehensive, though I do hope the estimated 1hr
>>> per day
>>> is subject to flexitime ;). The missing requirements (review periods, etc)
>>> may
>>> need some early clarification so volunteers have a better grasp of what
>>> they
>>> are getting into and whether they can meet those requirements. At the
>>> moment,
>>> it's vague enough I'm tempted to volunteer yet not entirely sure if it's
>>> flexible enough to withstand my occasional periods of busy-ness and late
>>> nights. Maybe that is the point though - maybe I'm not an ideal candidate.
>>>
>> If we have somewhere in the neighborhood of 5-7 folks, and you
>> communicate when you're busy, I don't see a problem. :)
>>
>>
>>> I am curious about the team count. Several suggests something in the
>>> region of
>>> 2-3 members. I would have expected, given the volunteer base, something
>>> closer
>>> to 5-6+. I don't see a problem finding 6 people from the community who are
>>> more
>>> than capable for the role. Is there a reason for the implied count
>>> restriction
>>> (assuming it was implied at all).
>>>
>> I think 3 is a _minimum_ number... and honestly, think 7 should be a
>> maximum, since the communication issues get to be tricky when the
>> numbers get larger. (I think 7 would be a great number, honestly) But
>> I'm open to arguments. :)
>>
>>
>>
>>> ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
>>> From: Matthew Weier O'Phinney<[hidden email]>
>>> To: [hidden email]
>>> Sent: Thu, June 3, 2010 7:26:54 PM
>>> Subject: [zf-contributors] Community Review Team
>>>
>>> As a follow-up to the discussions last week, I'm going to open several
>>> emails to cover some topics individually.
>>>
>>> In this email: the ZF Community Committee proposal
>>>
>>> In order for something to work, we need to establish clear guidelines to
>>> measure success by. In other words, I don't want the responsiblities to
>>> be vague.
>>>
>>> First, I think a better name might be in order, something along the
>>> lines of "ZF Review Team" (or some other name involving the word
>>> "Team"). "Committee" implies bureaucracy, which implies layered
>>> processes and red tape to me. "Team" better captures an idea of
>>> camarderie and people working together towards a common goal. As for
>>> "Review", I think it may make sense, considering the guidelines I'll
>>> outline below.
>>>
>>> Based on Ryan's email, and also some discussion on IRC, with Zeev, and
>>> with my team, I'm thinking the following make sense:
>>>
>>> * Assist contributors in getting patches and features into existing
>>> components.
>>> * Act as liaison for contacting a maintainer on behalf of a
>>> contributor
>>> * If the maintainer refuses to accept a patch, act as an arbiter
>>> between the contributor and the maintainer
>>> * If the maintainer does not respond after a set period of time,
>>> would evaluate and/or apply the patch for the contributor
>>> * Would issue pull requests to the Zend team in such instances as the
>>> above
>>> * Identify orphaned components
>>> * Would identify when a component is no longer under active
>>> maintenance
>>> * Solicit volunteers to take over maintenance of orphaned components
>>> * Decide when an orphaned component should be marked as such and
>>> scheduled for removal (Note: removal can only happen in major
>>> revisions)
>>> * Shepherd new proposals.
>>> * Solicit community feedback on proposals
>>> * Would put competing proposal authors in touch with each other to
>>> work on a unified proposal
>>> * Provide feedback on proposals (including initial decision as to
>>> whether or not there is enough community interest in including the
>>> proposed functionality in the framework)
>>> * Would notify the Zend team when a proposal is ready
>>> * Would do initial code review on the proposal implementation
>>> * Would notify the Zend team when the proposed feature is feature
>>> complete and ready to pull into the master branch
>>>
>>> While some specifics still need to be considered (how long to wait for a
>>> maintainer's response? how long to wait until a component is considered
>>> unmaintained? etc.), I think this shows a fairly clear set of
>>> responsibilities, and also gives a sense of how much work might be
>>> required by those members on the team.
>>>
>>> I can envisage probably 12-16 hours of work to split between several
>>> members -- so maybe as little as an hour of dedicated time each day.
>>>
>>> Also, another point to consider: we should probably define a regular
>>> review period for the team, to see who is able to live up to the
>>> requirements, and how successful the team has been in meeting the
>>> requirements as a whole. Along with this would be a plan for soliciting
>>> new members for the team in the event that somebody is unable to
>>> continue.
>>>
>>> Any additions or changes any of you would like to make? And who might be
>>> interested? :)
>>>
>>> --
>>> Matthew Weier O'Phinney
>>> Project Lead | [hidden email]
>>> Zend Framework | http://framework.zend.com/
>>> PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
>>>
>> --
>> Matthew Weier O'Phinney
>> Project Lead | [hidden email]
>> Zend Framework | http://framework.zend.com/
>> PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
>>
>>
>

--
Victor Farazdagi

Blog | http://www.phpmag.ru
FourSee | http://www.4cinc.com
UMapper | http://www.umapper.com

till-2

Re: Community Review Team

I know this sounds crazy, but...

1) Why not define thresholds necessary for a successful or
unsuccessful vote. E.g. a minimum of 10 votes in favor of a component,
etc.. Conditional votes, and +1/-1. Done.

2) Let all contributors vote, vs. selecting a chosen few.

Till

akrabat

Re: Community Review Team

On 4 Jun 2010, at 11:10, till wrote:

> I know this sounds crazy, but...
>
> 1) Why not define thresholds necessary for a successful or
> unsuccessful vote. E.g. a minimum of 10 votes in favor of a component,
> etc.. Conditional votes, and +1/-1. Done.
>
> 2) Let all contributors vote, vs. selecting a chosen few.

Matthew's proposal contained nothing about selection of components. The closest I can see is identification of orphaned components and attempting to get a new maintainer.

The job of the team can be summarised as "Don't lose code or contributors through lack of communication".

Regards,

Rob...

till-2

Re: Community Review Team

On Fri, Jun 4, 2010 at 1:25 PM, Rob Allen <[hidden email]> wrote:

>
> On 4 Jun 2010, at 11:10, till wrote:
>
>> I know this sounds crazy, but...
>>
>> 1) Why not define thresholds necessary for a successful or
>> unsuccessful vote. E.g. a minimum of 10 votes in favor of a component,
>> etc.. Conditional votes, and +1/-1. Done.
>>
>> 2) Let all contributors vote, vs. selecting a chosen few.
>
> Matthew's proposal contained nothing about selection of components. The closest I can see is identification of orphaned components and attempting to get a new maintainer.

I wasn't talking about components, I talked about a group of people to
feedback/comment/vote on proposals. :-)

> The job of the team can be summarised as "Don't lose code or contributors through lack of communication".
>
>
> Regards,
>
> Rob...

akrabat

Re: Community Review Team

On 4 Jun 2010, at 12:53, till wrote:

> I wasn't talking about components, I talked about a group of people to
> feedback/comment/vote on proposals. :-)

Even then, nothing Matthew posted changes the current policy of which is that the Zend team choose whether to accept a proposal.

The community team would help get the proposal to a point where it is ready to be reviewed by the Zend team and possibly help to prevent someone working on a proposal that will not be accepted.

Regards,

Rob...

Vic Farazdagi

Re: Community Review Team

In reply to this post by till-2

Well, having some better proposal acceptance mechanism is certainly
necessary.

Still, see no extreme need for voting (I actually prefer more simplified
process, not adding yet another layer). The way Matthew described it (at
least it's how I got it) RT can already assist proposal makers
throughout process of proposal preparation, and as such this would also
mean less work for Matthew and Co once proposal is ready. And it all
should amount in a more robust and quick workflow.

On 06/04/2010 03:53 PM, till wrote:

> On Fri, Jun 4, 2010 at 1:25 PM, Rob Allen<[hidden email]> wrote:
>
>> On 4 Jun 2010, at 11:10, till wrote:
>>
>>
>>> I know this sounds crazy, but...
>>>
>>> 1) Why not define thresholds necessary for a successful or
>>> unsuccessful vote. E.g. a minimum of 10 votes in favor of a component,
>>> etc.. Conditional votes, and +1/-1. Done.
>>>
>>> 2) Let all contributors vote, vs. selecting a chosen few.
>>>
>> Matthew's proposal contained nothing about selection of components. The closest I can see is identification of orphaned components and attempting to get a new maintainer.
>>
> I wasn't talking about components, I talked about a group of people to
> feedback/comment/vote on proposals. :-)
>
>
>> The job of the team can be summarised as "Don't lose code or contributors through lack of communication".
>>
>>
>> Regards,
>>
>> Rob...
>>
>

--
Victor Farazdagi

Blog | http://www.phpmag.ru
FourSee | http://www.4cinc.com
UMapper | http://www.umapper.com

till-2

Re: Community Review Team

In reply to this post by akrabat

On Fri, Jun 4, 2010 at 3:01 PM, Rob Allen <[hidden email]> wrote:

>
> On 4 Jun 2010, at 12:53, till wrote:
>
>> I wasn't talking about components, I talked about a group of people to
>> feedback/comment/vote on proposals. :-)
>
>
> Even then, nothing Matthew posted changes the current policy of which is that the Zend team choose whether to accept a proposal.
>
> The community team would help get the proposal to a point where it is ready to be reviewed by the Zend team and possibly help to prevent someone working on a proposal that will not be accepted.
>
> Regards,
>
> Rob...

Yeah, and I am after a more open process from the beginning to the end.

Not just opening up part of it to a couple people who do the
groundwork for the Zenders.

I really think that some code that's currently shipped with the ZF
shouldn't have been part of it to begin with. Reason would be both
code quality and purpose. And I don't say that to offend anyone who
worked on these in the past - both actual contributor or code
reviewer. I sure believe more eyes on it would improve the process.

And I'd hardly call voting an extreme need.

This is open source? I thought...

Till

Vic Farazdagi

Re: Community Review Team

On 06/04/2010 06:27 PM, till wrote:

> On Fri, Jun 4, 2010 at 3:01 PM, Rob Allen<[hidden email]> wrote:
>
>> On 4 Jun 2010, at 12:53, till wrote:
>>
>>
>>> I wasn't talking about components, I talked about a group of people to
>>> feedback/comment/vote on proposals. :-)
>>>
>>
>> Even then, nothing Matthew posted changes the current policy of which is that the Zend team choose whether to accept a proposal.
>>
>> The community team would help get the proposal to a point where it is ready to be reviewed by the Zend team and possibly help to prevent someone working on a proposal that will not be accepted.
>>
>> Regards,
>>
>> Rob...
>>
> Yeah, and I am after a more open process from the beginning to the end.
>
> Not just opening up part of it to a couple people who do the
> groundwork for the Zenders.
>
> I really think that some code that's currently shipped with the ZF
> shouldn't have been part of it to begin with. Reason would be both
> code quality and purpose. And I don't say that to offend anyone who
> worked on these in the past - both actual contributor or code
> reviewer. I sure believe more eyes on it would improve the process.
>

Well not being selected as reviewer doesn't mean you can't go through
code, and jump into irc (or get in touch with Review Team via e-mail) -
and express your concerns. If someone would do it more than often (and I
am pretty sure there will not be that many ppl doing it) - he can be
considered to be given place in RT.

> And I'd hardly call voting an extreme need.
>
> This is open source? I thought...
>
Open source and get riddled by committees are completely different
things, imo. Overall, I don't think that absence of Review Team was a
bottleneck, or is primary cause of sub-optimal code being included into
framework. Nor do I believe that having RT would solve all issues - but
it would expand the circle of ppl whom you might contact when you want
to get more involved with the framework. Now with github enabled
repositories, moving code around, should be even easier.

--
Victor Farazdagi

Blog | http://www.phpmag.ru
FourSee | http://www.4cinc.com
UMapper | http://www.umapper.com