incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Om <bigosma...@gmail.com>
Subject Re: List of Inactive Apache Flex PPMC Members
Date Fri, 16 Nov 2012 00:11:58 GMT
>
>
> If I recall correctly, we've only not elevated directly to PMC in a small
> handful of occasions, when the new committers had not yet actually
> contributed patches but were working on big code grants/contributions to
> the project. I believe it was encouraged and most people were voted
> directly as PPMC/committers.


Not true.  It was exactly the opposite of what you describe here.  There
was pretty much a consensus that we should make them committers-only first.
  And then elevate them to PPMC members if they continue to show that they
care about Apache Flex.
If you want to go into details about who you think they were, IMHO, we
should take the conversation into the flex-private list.


>


> >
> > There are a fairly significant number of non-coders in the current PMC.
> >  Maybe they should actively recruit folks that do interaction design,
> > evangelism, etc.  The lack of such activity does not mean that we should
> > not invite new coders/committers into Apache Flex.
> >
>
> I don't think anyone has ever proposed stopping the invitations of new
> committers. I believe its encouraged to add as many as are actively
> participating and contributing to the project as we can find that are
> active and accepting of the invitation.
>

The implication was that since the PMC consists of mostly coders, only
coders are being invited into the PMC.  That is the point I was trying to
counter.  If non-coder-PMC members were more active, we probably will not
have such an imbalance.  One of the stated responsibilities of a PMC member
is to actively look for new people to add to the project who will advance
the project.


>
>
> >
> > More of both is what we need.  I have personally reached out to
> non-coders
> > who have been active on this list to see if they are interested in
> becoming
> > PPMC members.  And we should all be doing that regularly.
> >
>
> Sure, it just takes a simple nomination by PPMC members, that's never been
> discouraged that I recall.
>
>
> >
> > But this is tangential to the current discussion.  Erik raises a valid
> > question here.  We are at the cusp of graduating and we need to figure
> out
> > what standards we want an Apache Flex PMC member should be held to.  Lets
> > all agree to a standard and start adhering to it.
> >
> > Thanks,
> > Om
> >
>
> What standards? The decision of whether or not they should be a (P)PMC
> member is always done at the time of voting them in as new ppmc/committers.
> Once they're voted in there's no real standard, that is why people aren't
> really removed once they're committers. People earn their way in with
> activity and a vote in, and after being voted in, for whatever kind of life
> reasons their activity reduces there aren't demotions or removal of
> peoples, so I don't see the necessity for a defined standard for PMC
> members. It really all comes down to the vote when they're added.
>

The question is what are the standards?  The answer could very well be
'there are no standards'.  But as you say, an invitation is put forth based
on a person's level of activity and attitude shown in the list.  So, there
is an implicit 'standard' we want PPMC members to adhere to.

The immediate question for us is should we apply the same 'standard' to the
initial list of committers and PPMC members.  That is what we need to
decide as a team.

And as Alex mentioned, this is a pretty standard process that takes place
when a podling graduates into an Apache top level project.    The initial
committer list is culled during this transition.  Again, this is not a
demotion - if the person is really interested, they can contribute to Flex
and be invited again.



>
> Am I wrong here? Glad we're keeping some mentors around for these
> discussions, maybe they can chime in a little bit here.
>
> -Omar
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message