First I'd like to say that I recognize that this discussion is incredibly personal. Brandon and Russell, please do not be offended, but I know that I probably would be if this very public thread involved myself. That being said, please know that from my perspective this is *not* personal, rather I see this as a general discussion about the precedent that we are creating here.
Responses in-line. On Fri, Aug 14, 2015 at 9:32 AM, Kyle Mestery <mest...@mestery.com> wrote: > On Fri, Aug 14, 2015 at 6:29 AM, Ihar Hrachyshka <ihrac...@redhat.com> > wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA256 >> >> Thanks a lot for the reply! I think it raises some good points here >> that I would like to clarify with other team members. I don't think >> those should interface with the current nomination run, so I spin it >> into a separate thread. >> >> > Absolutely! I think it's super healthy to have these discussions, it's > what healthy open source communities do. I'll answer your specific concerns > below. > > >> Some comments inline. >> >> On 08/12/2015 07:16 PM, Kyle Mestery wrote: >> >> [1] http://stackalytics.com/report/contribution/neutron-group/90 >> > >> > >> > Shouldn't we use the link that shows neutron core repo >> > contributions only? I think this is the right one: >> > >> > http://stackalytics.com/report/contribution/neutron/90 >> > >> > >> >> Sure, if you want to look at only the neutron repo. I tend to >> >> look at people across all of our repos, which you may or may not >> >> agree with. I >> >> Neutron-core gerrit group indeed always had a vague definition. It >> worked fine before when we had just neutron and python-neutronclient >> repositories [even though client expertise stands out somewhat of >> usual server oriented development we do in neutron repo]. >> >> > Agreed. And on that note, I think it may make sense to separate out client > merge responsibilities from server ones, as there are typically hardly any > core reviewers for neutron who pay attention to the client at this point. > > >> Now, with successful tree split into neutron, neutron-*aas, >> networking-*, + having a separate repo for specs; now that neutron is >> really a meta-project (a big tent they say), >> >> > Nope, it's the "Neutron Stadium", the "Big Tent" moniker was already > taken, so we came up with our own. ;) > > >> it feels to me that leaving neutron-core group as a "meta-group" that >> includes everyone who makes significant positive impact in any of >> those repos is not optimal. >> > > This is where I'd disagree. I think in general teams pay too much > attention to stats, which are incredibly easy to game. Case in point, with > the current objections people have over Brandon and Russell being > nominated, I could have waited 4-6 weeks and let them amass a plethora of > review stats, but what would the point of that have been? > None what so ever. I think the point here is that if someone is focusing on another project then it's debatable if they should become a core in the Neutron project itself. Very simply put, if someone is a core in a subproject and is doing a fantastic job, but that person is not truly involved in the Neutron project itself, then that person becoming core in Neutron to me is dangerous. Before someone becomes core, I would like to be familiar with their expertise in Neutron so that I know if to trust their +2 or not on a given area in Neutron. If that person didn't really focus on Neutron then I have no way of being familiar with their expertise, thus no ability to trust them even if I'm generally a trusting person. > I trust both of them to merge code, they have both proven it in other > Neutron projects (Brandon) and other OpenStack project (Russell). A month > of collecting meaningless stats doesn't help anyone. Further, if either of > them takes advantage of their merge responsibilities in anyway, we'll > remove them. We're a community that is self governed and built on trust and > integrity, breaching that will lead to extreme measures. > > >> Having core team members that are judged solely on how they impact the >> core repo seems to me a better approach. Fostering more focused teams >> was one of the goals of tree splits, so I think we should take that >> gerrit advantage of having multiple repos more seriously. >> >> > I'm not disagreeing with you here, but to your point below about "areas of > focus", it's harder than it looks. We're working within the confines of the > tools we have. I'm not saying you're incorrect in your assumption here at > all. Going back to Russell and Brandon, if they don't start reviewing at a > decent pace, we should remove their merge capabilities, as we should any > core who doesn't review. > > >> >> also think that it's worth looking at the statement of what core >> >> reviewers do found here [1]. Particularly what common ideals all >> >> core reviewers across Neutron share. I'll copy them here: >> > >> >> 1. They share responsibility in the project’s success. 2. They >> >> have made a long-term, recurring time investment to improve the >> >> project. 3. They spend their time doing what needs to be done to >> >> ensure the projects success, not necessarily what is the most >> >> interesting or fun. >> > >> >> The list is indeed a great one, and a lot of us, including - if not >> especially! - me, sometimes lag on some of those points. >> >> > :) > > >> But doesn't the section talk about the big neutron tent, while voting >> permissions are still per-repo? >> >> > Yes, it does. > > >> Also, keep in mind how we nominate core reviewers now that we >> >> have a Lieutenant system [2]. >> >> That raises another interesting point that bothers me for some time. >> The section refers multiple times to 'Neutron core reviewers from the >> Lieutenant’s area of focus', but it does not say anything about >> reviewers [that I call 'obsolete'] who got into the core team before >> we had subteams and Lieutenants. Should they even have a say in >> subteam nominations? Everytime a nomination is proposed, I don't know >> whether I am in the position to put +1/-1. >> >> So the wording could be clarified here once we understand what the >> intended rules should be here. >> >> > In general, I want less rules. If I could do things over I'd wipe away > many of these rules and go with a system built solely on trust and > integrity, which is pretty much where we've landed. Have you noticed that > no one has gone and verified new cores are merging things only in their > area of focus? The reason for this is that I trust the Lieutenants, who > trust their new area of focus cores. If I or anyone else has to spend time > policing this stuff, the system is broken. We have to trust each other or > we've got nothing. > > >> > >> >> Finally, it's worth all core reviewers having a look at what's >> >> expected of core reviewers here. [3] I should point out that the >> >> team is severely lacking in weekly meeting attendance at this >> >> point, but it's not a good thread to do that. Instead, I'll just >> >> point out what we as a team have codified as expectations for >> >> core reviewers. >> >> Not that it's in the core of the matter for the thread, but I wonder >> what reasonable attendance is, considering we have shifted schedule >> that makes some team meetings occur at time when you usually prepare >> to sleep or order yet another beer in a pub. Is participation once per >> two weeks resonable, or should core reviewers strive to make it every >> week? >> >> > This is a cop out I'm afraid. The meeting has been rotating for quite a > while now, and I'm severely disappointed by the complete lack of attendance > by 75% of the core reviewers in Neutron. It could be that I'm getting tired > of running a meeting where the participation by people vested in the > project is very low, and maybe we should just stop having a meeting and > move to mailing list updates every week. I'm not going to police this, but > I find it hard to believe most core reviewers can stay up to date with the > happenings in Neutron by not attending and participating in this meeting > every week. > > Thanks for starting this thread, I look forward to replies from everyone > as we continue this healthy debate! > > Kyle > > >> > >> >> Thanks! Kyle >> > >> >> [1] >> >> http://docs.openstack.org/developer/neutron/policies/core-reviewers.h >> tml#neutron-core-reviewers >> <http://docs.openstack.org/developer/neutron/policies/core-reviewers.html#neutron-core-reviewers> >> >> >> >> >> [2] >> >> http://docs.openstack.org/developer/neutron/policies/core-reviewers.h >> tml#adding-or-removing-core-reviewers >> <http://docs.openstack.org/developer/neutron/policies/core-reviewers.html#adding-or-removing-core-reviewers> >> >> >> >> >> [3] >> >> http://docs.openstack.org/developer/neutron/policies/core-reviewers.h >> tml#neutron-core-reviewer-membership-expectations >> <http://docs.openstack.org/developer/neutron/policies/core-reviewers.html#neutron-core-reviewer-membership-expectations> >> > >> >> >> > Ihar >> > >> > ______________________________________________________________________ >> ____ >> > >> > >> OpenStack Development Mailing List (not for usage questions) >> > Unsubscribe: >> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> > <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> >> > >> > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > >> > >> > >> > >> > ______________________________________________________________________ >> ____ >> > >> > >> OpenStack Development Mailing List (not for usage questions) >> > Unsubscribe: >> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v2 >> >> iQEcBAEBCAAGBQJVzdD/AAoJEC5aWaUY1u57SHsH/2/oBqY4uJnfJxKnHI909mCn >> ttHu5j+Nvs7idb4opJm48UaHPcEGEea9ruzMz+usUtGY/vyYRhZ7svAENmAxKszR >> +d9Wkt0sxImpoCWkIEE7zS+EJNSxe+ps6F8vOpNnQO8RwuEOveQ0QXj85xgIToza >> LkFQiQUO+y4FIO0auXii/yAwwvj3euj+u2Q6oB1QnqVe+Mwf3xEnOrx5NPj4eLQ/ >> sA2vLZcAx1cDVQORqum7ZSYr5Xm799bhDNmGfCFSShQ3znar4At4MHqDn8jW0rFZ >> w3Wy9QVdr0QaY4xxSj1ktRh0SXbFGVD2pPCPPm4m/myJ3o5mnknhYe2mUiRLh88= >> =UJ1E >> -----END PGP SIGNATURE----- >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
