[Pulp-dev] commit-bit nomination

[Milan Kovacik]

Folks,

thanks for your feedback and your trust, I do really appreciate your votes
and my nomination and I'm glad the majority of the electorate participated
in the vote.
I do believe an open commit bit assignment process is essential for a
viable community project as it boosts diversity which in turn fosters
innovation and creativity.
I wish not only for this process to stay but for more open processes being
introduced eventually.

Cheers,
milan

On Tue, Sep 11, 2018 at 7:31 PM, Daniel Alley <dalley at redhat.com> wrote:

> Hi all,
>
> We have had some challenges in the first execution of the new process to
> add a new commit bit owner. Some implications of the process were not fully
> realized until implemented, and the results were regrettable.  Our goal is
> to create an inviting atmosphere for community members, and to show that we
> value the time and effort they devote to contributing to the Pulp project;
> and it appears that some aspects of the current process are not properly
> aligned with this goal.  We apologize to all involved in this being
> discovered here in this manner, and we'd like to step back and re-evaluate
> how we can address these concerns.
>
> We are withdrawing this nomination on procedural grounds, and further
> nominations will be put on hold while we re-think the commit bit
> process.  We will follow up in a new thread once we have an update.
>
> -- Pulp Team
>
>
> On Mon, Sep 10, 2018 at 12:13 PM, Dennis Kliban <dkliban at redhat.com>
> wrote:
>
>> -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
>>>
>>>
>>
>> _______________________________________________
>> 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/20180912/6f7955ec/attachment.htm>