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 <dal...@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 <dkli...@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 <davidda...@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 <amacd...@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 <ipan...@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 <dawal...@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 <bbout...@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 <dal...@redhat.com> >>>>>>> wrote: >>>>>>> >>>>>>>> Now that PUP 6 has been merged, it's time to follow the process :) >>>>>>>> >>>>>>>> I would like to nominate Milan Kovacik (mkova...@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@redhat.com >>>>>>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Pulp-dev mailing list >>>>>>> Pulp-dev@redhat.com >>>>>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Pulp-dev mailing list >>>>>> Pulp-dev@redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> Pulp-dev mailing list >>>>> Pulp-dev@redhat.com >>>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>>> >>>> _______________________________________________ >>>> Pulp-dev mailing list >>>> Pulp-dev@redhat.com >>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>> >>> >>> _______________________________________________ >>> Pulp-dev mailing list >>> Pulp-dev@redhat.com >>> https://www.redhat.com/mailman/listinfo/pulp-dev >>> >>> >> >> _______________________________________________ >> Pulp-dev mailing list >> Pulp-dev@redhat.com >> https://www.redhat.com/mailman/listinfo/pulp-dev >> >> > > _______________________________________________ > Pulp-dev mailing list > Pulp-dev@redhat.com > https://www.redhat.com/mailman/listinfo/pulp-dev > >
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev