@Owen Some interesting thoughts and proposals. None of which I think we
could easily implement, but some that I would LOVE to have.
I also apologize for restating many things that Helena has already said,
but it is taking my a long time to craft this email...
Jake has raised a concern that I share. In too many cases contributors
are made committers on the basis of "mateship" and less on tangible
contributions. I remember cases where proposed committers were rejected
for not having been active enough on mailing lists or even PR. Yet in
other cases no contributions on mailing lists are over shadowed by the
sheer volume of PR's submitted, resulting in the granting of committer
(and pmc) rights. In most successful (nomination cases) the nominee sat
in the same office,same team, had breakfast/lunch/coffee and socialized
with many other Geode committers/pmc members. Which automatically evokes
a "mateship" bias. "The person is a nice person and I enjoy working with
them" very often overshadows the lack of dev/user list contributions or
PR's.
Having guidelines based code quality and technical knowledge is only
part the criteria. Activity in the community (mailing lists) is the
other part that should be considered. All of these, are factors in
determining a committer.
As a PMC member I also ask myself the questions:
* "Do I as a PMC member trust that all future commits from a nominee
to be of the same high standard going forward?"
* "Will this nominee continue to be active on mailing lists and the
community at large."
* "Am I convinced that the PR's that I am seeing is really that of the
nominee and not that of a team effort of pair programming with
another committer/pmc member".
(https://github.com/apache/geode/pull/3650,https://github.com/apache/geode/pull/3573).
How am I to judge the quality of work of the nominee when multiple
developers were part of it? I have witnessed this in many cases, where
developers submit PR's under their name, but the main body of work was
predominantly done by their more experienced pair. Synthetic bolstering
of PR number to use as "fact" when it comes to committer nomination. In
these cases I look to the mailing lists to gain insight into that
nominees understanding of project and problem area, rather than can they
write compliant code.
Being a PMC member, imo, is another role that should be evaluated on,
after having become a committer. Activity in mailing list, reviewing of
PR's (yes a committer's responsibility, AND imo an evaluation criteria),
shows commitment to the project. Commitment to the project results in
rights to become a PMC member. Once again there are no metrics (or exact
numbers) that we can attribute to this, BUT subjectively everyone can
evaluate the contributions and gauge if they feel the nominee is strong
enough. As a side note, anonymization would be awesome here.. take away
the face and familiarity and only evaluate on contributions would be
SOOO much simpler. But alas too much work and most likely complete and
utter overkill.
@Owen, you are correct, a single -1 is a strong signal that something is
not as clear or apparent to a single PMC member as it is to many others.
This is why a reason is required. This also allows space for other PMC
members to present their views on the nominee, which might not be as
apparent to others. In some cases I feel maybe reasons should accompany
a +1. I mean, why would a -1 need justification and a +1 does not. THAT
+1 justification might just sway a -1 to change their mind to a "0" or
even a "+1".
I also want to highlight another elephant in the room. Out of 100
(registered) committers and 50 (registered) pmc members, only 6 have
commented on this thread. Pause for thought.....
--Udo
On 5/31/19 02:41, Owen Nichols wrote:
I appreciate the concern about bias/cronyism. If having some criteria will
“level the playing field”, then let’s discuss what those criteria would be.
However, in voting for a committer, a single -1 carries more weight than all
the +1’s in the world. A -1 also requires explanation. This system of checks
and balances should be sufficient to combat most implicit bias or voting blocs.
If it looks like someone is getting +1 votes for the wrong reasons, it only
takes one person to call it out by casting a -1. If you have a reservation,
don’t be afraid to speak up!
Keep in mind what we are voting for when we make someone a committer. We are
not voting “have they satisfied this or that”. We are voting “can we trust
them to be a good steward of the codebase”. Apache’s guidelines are
intentionally vague, because to be any more specific risks applying an
artificial definition of “trust”.
Suggesting some signals a voter might take into account to judge
trustworthiness is very different from prescribing an explicit metric that
every voter must use. If we want to go that route, let's follow the DMV model
and give each prospective committer a multiple-choice test about Geode which
they must score 80% or higher to earn their “license to commit”. If they fail
the test, they must wait 90 days before they can retake it.
I think it might be helpful to first define clearly what code of conduct a
committer is expected to follow. That exercise would help frame exactly what
we are trusting new (and existing) committers to adhere to.
It might also be useful to consider making it policy to suspend committer
status if expected code of conduct is not adhered to, like a DUI. In this
commit-then-review model, the bar to becoming a committer could be lower, but
followed up with continuing mentorship.
-Owen
On May 30, 2019, at 10:23 PM, Jacob Barrett <jbarr...@pivotal.io> wrote:
The major concern I have with voting without guidelines is that this process
has been vary biased towards fellow employees. Internal knowledge and trust is
being used to evaluate each candidate. Some have had very little public
interaction with the community as a whole. I think it's important that we have
guidelines to avoid this implicit bias we have for fellow employees. Having
some criteria that states they have to have contributed to some threshold in a
breadth of facets in the community would help with this.
Ask yourself honestly, how would you vote on a Committer/PMC nomination of an
anonymous community member that has only had a handful of small commits? Keep
in mind we have approved fellow employees for a handful of small commits. Is
that fair?
The point is the process need to be fair and without bias for employment and
relationships. The criteria you use to vote +1 on any individual should be
consistent. If the community honestly thinks we are doing this already then
there isn’t a problem. I don’t think we are. I think we have a problem.
-Jake
On May 30, 2019, at 4:17 PM, Owen Nichols <onich...@pivotal.io> wrote:
A 6-month waiting period from committer to PMC is tempting because it’s easy to
implement, but as you described it yourself, it is arbitrary, which ultimately
de-values what it means to be a member of the Geode PMC.
The bottom of https://www.apache.org/foundation/voting.html
<https://www.apache.org/foundation/voting.html> explains why The Apache Way favors
voting over authority figures, rules, or processes: "None of these tend to be very
good substitutes for doing the hard work of resolving the conflict”.
If we could perfectly enumerate objective criteria to be a committer or PCM
member, there would be no need to vote: just make sure all the boxes are
checked. That isn’t the Apache way.
I feel that our existing procedures for discussing and voting work fine, even
without well-defined criteria. As I outlined in another branch of this thread,
the only real requirement for committer (or PMC) is trust, and I believe voting
is the best way to reach consensus on when trust has been earned.
-Owen
On May 29, 2019, at 12:04 PM, Jacob Barrett <jbarr...@pivotal.io
<mailto:jbarr...@pivotal.io>> wrote:
A few observations I have found by looking through the Apache wiki for all the
projects is:
That several of them do separate the two roles.
The discussions about committers happens in the dev@ list while discussions for
PMC happen on the private@ list.
Some projects projects treat PMC as a promotion role for someone that has been
successful at the committer role, but with no clear definition of success or
timeline.
Maybe a starting point we just set some arbitrary period of time, say 6 months,
after becoming a committer where someone on the PMC can nominate a committer
for a promotion to the PMC. If within this time the committer as continued to
show increasing merit then the PMC’s should vote positively.
Then we are just left with coming up with clear metrics for measuring merit as
a contributor to become a committer. I think the The Apache Way Merit
definition is pretty clear in its distinction of what is and isn’t considered
merit. The key things I see is that employment is not considered in the merit,
nor is future or vapor works. Merit must only be ranted for things that have
been completed and measured by its impact.
Personally, I think we need to look at more than just code contributions. We
also need to look at process and community. By process I think they should be
able to submit a PR, respond to feedback on the submission, and see the PR
through to merge. They should also be commenting and providing clear actionable
feedback on other’s PRs. For community I think they need to be actively
participating in user@ and dev@ discussions. Additionally I feel that in all
these forums they need to adhere to our code of conduct, which we should also
attempt to solidify. The bottom line is that if we accept this person as a
committer what will they bring to the community beyond their ability to produce
some code.
Perhaps then the PMC role is more about amplifying those that excel at these
things and mentors others in them.
Apache Felix has a pretty good page we could use as a starting point for
outlining our process.
https://cwiki.apache.org/confluence/display/FELIX/Apache+Felix+Community+Roles+and+Processes
<https://cwiki.apache.org/confluence/display/FELIX/Apache+Felix+Community+Roles+and+Processes>
<https://cwiki.apache.org/confluence/display/FELIX/Apache+Felix+Community+Roles+and+Processes
<https://cwiki.apache.org/confluence/display/FELIX/Apache+Felix+Community+Roles+and+Processes>>
On May 29, 2019, at 10:13 AM, Anthony Baker <aba...@pivotal.io> wrote:
I think it’s time to re-establish consensus around two things:
1) What is our criteria for becoming a committer and PMC member?
2) Do we have separate criteria for committers and PMC members (and thus should
elect them separately)?
The ASF notes that projects are free to chose the approach that works best for
them [1]:
PMCs are free to set the bar for merit within their projects, as long as
decision making is done in a collaborative fashion as in the Apache Way.
Healthy PMCs will regularly review contributions from non-committers - both
specific code patches, bugs reported or commented on, or just helpful
interaction on their project lists - to evaluate contributors as potential
committers. Ensuring that PMC members are helping to mentor helpful new
contributors to their projects helps to ensure a healthy and growing project
community.
PMCs vary significantly in the level of commitment and work expected to be considered for a
committership. Some PMCs vote in new PMC members typically from their existing committers (i.e. the
progression is contributor -> vote -> committer -> vote -> PMC), while other PMCs always
elect new committers into the PMC simultaneously (contributor -> vote -> committer & PMC
member).
To date, we’ve been mostly following the “bundling” approach of combining
committers / PMC’s votes. This is not explicitly spelled out in our wiki
however (see [2][3]). We established the current criteria back in 2016 [4].
The private@ thread [5] that spawned this discussion included some great advice
from our project mentors (Roman, Kos, Niall, William Rowe). If I can summarize
it here, it basically boils down to:
- Set the bar for inclusion as low as possible
- Read the definition of Merit [5]
- Is the person trustworthy with code, community, etc.
Thoughts?
Anthony
[1] https://apache.org/foundation/governance/pmcs.html
[2] https://cwiki.apache.org/confluence/display/GEODE/Becoming+a+committer
[3]
https://cwiki.apache.org/confluence/display/GEODE/Nominating+a+Committer+and+PMC+Member
[4]
https://lists.apache.org/thread.html/819a140349394833cf1c51b653672ab7a950d48891cf6abef245b8a7@1452130249@%3Cdev.geode.apache.org%3E
[5] http://theapacheway.com/merit/
