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
