community-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John D. Ament" <johndam...@apache.org>
Subject Re: Vetoes for New Committers??
Date Wed, 29 Mar 2017 00:15:33 GMT
I asked a similar question on another list some time back, around voting in
new committers.  I'm not going to share that thread (public vs private) but
I think the advice i got from it was spot on.  In addition, I've heard
great additional feedback on other threads.

Projects want committers who are infrequent, but able to contribute.  They
want PMC members who are consistent and dedicated to the project.  You want
some form of consensus though through the addition of a committer.  IF
someone has serious concerns, and is unwilling to change their vote, you
may want to hold off and monitor a bit further to see when that person
passes that threshold to become a committer.  You have to have a clear
understanding through the community though to understand why the person
voting -1 feels strongly that way, in addition to not scaring the person
voting into withdrawing their vote - it could be a legitimate issue.
Though ideally, your discussion thread would flesh something like this out.

John

On Tue, Mar 28, 2017 at 8:04 PM Niclas Hedhman <niclas@hedhman.org> wrote:

> Hi,
> on https://community.apache.org/newcommitter.html#new-committer-process it
> describes the process of bringing in a new committer for a "typical
> project".
>
> But in the "Discussion" it speaks of "3 +1 and no vetoes"... Is it really
> "typical" that projects use vetoes for new committers? I can't recall
> seeing that anywhere, not saying it is incorrect, but asking whether it
> really is "typical".
>
> Perhaps we should provide links to a handful of well-known project's
> processes, to both give a template for projects to work with as well as
> different approaches.
>
> Anyone has any opinion on this matter?
>
> Cheers
> --
> Niclas Hedhman, Software Developer
> http://polygene.apache.org - New Energy for Java
>

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