[Pulp-dev] commit-bit nomination

Fri Sep 7 00:17:42 UTC 2018

I respectfully disagree.

I was hoping for more discussion before the calling of a vote.
>

The process described in PUP6 specifically states that the nominating email
should have a vote end date, thus calling a vote.  There's nothing wrong
with having discussion now on this thread, as part of explaining your
stance or asking questions before deciding, but voting is still actively
taking place.  People can always change their vote based on the results of
discussion up to the vote end date in seven calendar days.

With Pulp2 nearing maintenance mode, the core and plugin teams need to
> assess what their needs are both in code and people. I feel that with 9
> people on the core team, maintaining vision is hard/impossible, and the
> mailing list discussions have demonstrated that.
>

No, what the mailing list discussions have demonstrated is that we have a
problem with our decision making process.  Plenty of projects have larger
teams, but they usually have a team lead for breaking ties and ensuring
that forward progress is made even with difficult decisions where a team is
split on what to do.  The bright side is, no matter what decisions are made
on any of those discussions, the project moves forward, and can always
pivot in future versions based on feedback or with community submitted open
source work.  But decisions must be made and if our lazy consensus method
where even a single -1 is blocking prevents work from moving forward and
releases from arriving on schedule, it's time we reconsider that process,
and that is a separate discussion for another place and time.

Also consider that Pulp3 is an order of magnitude smaller codebase
> (literally) so keeping the same number of committers seems too many.
>

Again, I disagree with this focus on number of committers for many reasons.

1) @bizhang just left the team and resigned a commit bit, so there is now
an opening and if there had been a problem with the number of commit bits
before today, then that should have been brought up previously, perhaps by
having no grandfathered-in committers and all team members voted on by
majority when this decision was made last fall, or perhaps by explicitly
limiting the number of commit bits in the PUP.

2) We just had lengthy discussions in meetings a week ago about ways to
improve the speed with which we respond to PRs.  There were suggestions
ranging from email notifications of every one that is submitted, a weekly
PR triage, having subject matter "experts" designated to divide up the
work, or it being on the shoulders of the pull requesters to continually
poke channels/individuals for a response until they get one.  The response
to all of this was simply that we are all too busy.  Too busy implies that
there is more than enough work to go around for more people, and the only
people who can approve and merge PRs are those with the commit bit, ergo we
need more commit bits out there.

3) We want to grow.  I have heard over and over again how much we want to
grow this project, that we want more community contributors.  We shouldn't
be measuring by how many lines of code exist now on a growing project when
we're having to delay various plugins and features because we just don't
have time right now.  With more people joining the work, we need more
commit bits to review and approve that work or we rapidly hit a bottleneck
where someone codes, hears nothing back for months of delay, and loses
interest or moves on to other projects.

4) Most importantly to me, I am alarmed at the apparent gatekeeping right
off the bat.  I noted my misgivings regarding the stated drawbacks to the
PUP during voting for PUP6, and having seen the quality of work for months
had fully expected this particular nominee to gain commit bit as soon as
the process was finalized, but maybe my expectations were out of line.  So
let's take a step back and look at the purpose of limiting the commit bit.

(Apologies to those reading, this email got long, but I think this is all
relevant and important to the discussion at hand, being the first
nomination on a new process.)

----

--What are the risks associated with giving someone a commit bit?

They are:
A) Malicious intent.  Someone could now delete the codebase, or include
malware secretly into the work.
B) Accidents due to inexperience.  Someone not used to this set of
commands, working in a shared repository could accidentally force push and
overwrite the upstream repository instead of just their local one, etc.
This mistake can and has happened even with experienced developers, so it
is always a risk but is more pronounced with someone new and/or
inexperienced with the way of doing things on a specific project.
C) Breaking the codebase, especially production, with buggy code.  This can
and does still happen even with experienced developers.

--How can these risks be mitigated?

Well, as far as A, malicious intent and accountability, you generally trust
your vetting process when you hire someone.  At my previous job, everyone
was given the commit bit, even interns, with appropriate onboarding and
guidance from mentors.  Pulp historically assumed this trust with Red Hat
employees, but being an open source project, we sought a fairer process to
encourage the community to be a larger part of Pulp and to be as
transparent as we can.  So let's focus on the open source aspect of dealing
with these risks.

A & C can be reduced through good review practices.  Every PR should be
reviewed, ideally by more than one person if it's a sizeable change.  We
already require review/approval before code can be merged.

C especially can be helped by working on a non-production codebase first
and allowing time for testing and review from QE before it goes live.
Having good tests is also a great goal for any project.

A & B can be reduced through the passage of time.  Having community members
who are active and in it for the long haul, who have demonstrated good
practices and gained experience such that you feel they are less likely to
make the mistakes of B or to be the malicious actor of A.

--What does this mean for the commit bit process?

What we can't mitigate in other ways and really are trying to control is
time and commitment.  We want to see people who care about the project more
than just today for one contribution, who are comfortable with the process,
and would add to the positive collaboration going on.  This is outlined in
our PUP, and one of the reasons we left this subjective was so that folks
wouldn't try to game a system if it was automated based on numbers.   For
some people, this process may take one month, for others one year, but
anyone who meets these qualifications should be given the commit bit so
that we can continue to grow.

However, this subjective assessment shouldn't be a really high bar.  We're
not seeking epic level contributions, we're not here to limit this project
to only principle devs.  Even someone starting out may start with an open
source project, and as they contribute more and more, with filing bugs,
submitting pull requests, engaging in discussions, and providing
constructive feedback, they too should be qualified to review and approve
code without having to make a full-time job of it, or we might as well go
back to having employees have the commit bit only.

This project is too large to limit commit bits/code reviews/merging only to
individuals who know the workings of the entire repository inside and out.
Is there a chance they could miss something in a review that has an
unanticipated negative impact elsewhere in the code?  Sure, as with anyone,
but that's also what tests, QE, teammates, and bugfixes are for.  We need
trust, not control beyond the basic level to mitigate risks.

----

Either way, this type of conversation is probably best suited for
> discussion amongst each plugin group as they determine what their needs are.
>

Here I agree with you.  I had assumed if you were qualified to receive the
commit bit for Pulp, you'd be qualified to have it in other areas,
especially as I've seen folks from the mini teams requesting cross-team
help when they're overloaded, but if we really want plugins to have
autonomy, then this vote should really be focused on pulp then the pulp_rpm
team can make their own call in a separate procedure.

As for this nomination specifically, @milan has demonstrated each of the
points to becoming a committer listed here. [0]  Therefore, I am still +1
on giving him the commit bit.*

[0] https://github.com/pulp/pups/blob/master/pup-0006.md
* I do not have the commit bit yet myself, so technically my vote does not
count, but I think this was a very important discussion to have given the
new process and the potential effects these decisions will have on the
health of the Pulp project community, and thus eventually on my job.

Respectfully,

--Dana

Dana Walker

Associate Software Engineer

Red Hat

<https://www.redhat.com>
<https://red.ht/sig>

On Thu, Sep 6, 2018 at 8:26 AM, Brian Bouterse <bbouters at redhat.com> wrote:

> I was hoping for more discussion before the calling of a vote. I'm a
> committer in both of these areas, and this nomination surprised me since
> we've never talked about either change. I have concerns both with
> increasing the sizes of these teams and also with this specific nomination
> at this time.
>
> With Pulp2 nearing maintenance mode, the core and plugin teams need to
> assess what their needs are both in code and people. I feel that with 9
> people on the core team, maintaining vision is hard/impossible, and the
> mailing list discussions have demonstrated that. Also consider that Pulp3
> is an order of magnitude smaller codebase (literally) so keeping the same
> number of committers seems too many. I also feel that any committer being
> added should already be very involved, contributing features and
> discussion, not added and then gotten involved. Milan has been very
> involved in Pulp2 RPM work, but Pulp2 and Pulp3 are very different.
> pulp_rpm for Pulp3 is nearly feature complete and Milan hasn't been
> involved in any of that planning or implementation. Maybe the Pulp3/2 teams
> should be split? Either way, this type of conversation is probably best
> suited for discussion amongst each plugin group as they determine what
> their needs are.
>
> @Milan I think one area the core team does need leadership now is on
> pulp2->3 migration planning. I think that would be a good way to get more
> involved as a non-committer to demonstrate epic-level feature planning,
> show more collaboration, and clearer communication. Those are the main
> aspects I'm looking for. I can give feedback directly too if that's helpful.
>
>
>
> On Wed, Sep 5, 2018 at 10:44 AM, Daniel Alley <dalley at redhat.com> wrote:
>
>> Now that PUP 6 has been merged, it's time to follow the process :)
>>
>> I would like to nominate Milan Kovacik (mkovacik at redhat.com) for a
>> commit bit on these repositories:
>>
>>
>>    - pulp
>>    - pulp_rpm
>>    - devel
>>
>>
>> Milan has demonstrated a consistent dedication to quality in his
>> contributions and his reviews.  I believe his work speaks for itself :).
>>
>> The vote end date is September 12th, seven days from today.
>>
>> _______________________________________________
>> Pulp-dev mailing list
>> Pulp-dev at redhat.com
>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>
>>
>
> _______________________________________________
> Pulp-dev mailing list
> Pulp-dev at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20180906/85fe4613/attachment.htm>