[Pulp-dev] commit-bit nomination

[Dennis Kliban]

-1

Milan has been a great contributor to the Pulp 2 RPM effort. I am looking
forward to all the future contributions in both Pulp 2 and Pulp 3. However,
after collaborating with Milan on issue 2619[0], I decided that he needs
more mentorship. I can provide more feedback directly to you Milan.

The last sentence in the "Becoming a committer" section of PUP 6 states
"Anyone who specifically wants to get more involved should approach the
existing commit bit holders about mentorship." This step was omitted during
this nomination process.

[0] https://pulp.plan.io/issues/2619

On Mon, Sep 10, 2018 at 10:47 AM, David Davis <daviddavis at redhat.com> wrote:

> +1. I agree with @asmacdo. I do think we need a larger discussion around
> team sizes, etc though.
>
> David
>
>
> On Mon, Sep 10, 2018 at 10:45 AM Austin Macdonald <amacdona at redhat.com>
> wrote:
>
>> +1, I agree that Milan has met the criteria. I think we should go forward
>> with giving him the bit and larger discussions about decision making can
>> happen separately.
>>
>> On Mon, Sep 10, 2018 at 9:03 AM Ina Panova <ipanova at redhat.com> wrote:
>>
>>> Brian,
>>>
>>> it feels like your reply is in contradiction of what we are trying to
>>> achieve as a community project:
>>>
>>> 1) I am concerned that this reply can be perceived very badly by the
>>> community, especially once we approved the pup and announced this in hope
>>> of community embracing this change, by encouraging new contributions and
>>> motivating them with one of the retributions of becoming a committer.
>>> 2) We cannot afford ourselves to behave like a dental clinic which will
>>> say: we are too full and we are not accepting new patients ATM. There are
>>> community projects with a larger committer base and somehow they still
>>> manage to develop and evolve.
>>> 3) Do you suggest splitting the team in 2 with the acknowledgement of
>>> the fact that pulp2 is near EOF which means those people will be pinned
>>> just for the maintenance mode? I wonder if we have such volunteers doing
>>> this job daily. Anyone? :)
>>>
>>> I agree with Dana, we adopted the pup, team has voted, now we need to
>>> deal with the decisions we as a project have made.
>>>
>>> I think Milan has met the criteria listed in the pup, and if he has
>>> systematically demonstrated diligence and commitment i do not really think
>>> once he gets the commit bit he will go right away and screw up pulp3 code
>>> base because he has less experience in that area than in another.
>>>
>>> I understand that in this email thread have popped up multiple problems
>>> we are struggling with, but I would at least try to stay focused on the
>>> initial email topic and create separate discussions for the other topics.
>>>
>>> +1 on the voting.
>>>
>>> I also solicit the team to be pro-active, so we can fail fast things
>>> which do not work out for us.
>>>
>>>
>>>
>>>
>>> --------
>>> Regards,
>>>
>>> Ina Panova
>>> Software Engineer| Pulp| Red Hat Inc.
>>>
>>> "Do not go where the path may lead,
>>>  go instead where there is no path and leave a trail."
>>>
>>> On Fri, Sep 7, 2018 at 2:17 AM, Dana Walker <dawalker at redhat.com> wrote:
>>>
>>>> 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
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>> _______________________________________________
>> 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/20180910/adc795e6/attachment.htm>