Re: [openstack-dev] [neutron] What does being a neutron-core member mean? [WAS: Re: [neutron] I am pleased to propose two new Neutron API/DB/RPC core reviewers!]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/14/2015 05:25 PM, Russell Bryant wrote: While this includes me, I'm really not taking this personally. I'm thinking about it in the general sense. Thanks, and sorry for the thread, but I felt that we should clarify the matter asap if the new world does not completely stick to some minds in the team, like mine. On 08/14/2015 11:03 AM, Kyle Mestery wrote: I'd argue the system is built on a web of trust. If you trust me, and I trust Russell and Brandon, then you should likely trust Russell and Brandon as well. This is EXACTLY what the Lieutenant system was meant to convey, though I now feel like perhaps people missed this key ingredient of the new world we find ourselves in. This is a huge and important point. The N to N trust model we've been operating under doesn't scale. Neutron is trying to move to a different trust model that has proven to scale much further than we've been able to do within a single OpenStack project so far. Indeed that's the case, and I believe Kyle's efforts are the main reason we have a team that is so open to newcomers and different perspectives. That's why I feel that even if I am not completely bought in the new world doctrine, I should expect that if Kyle does something, he makes it for good. That's indeed trust, but based on past experience, not the potential future. If Kyle and others leading a section of Neutron trust me, I'm happy to jump in and do more reviews. If they trust me, I'd hope others not as familiar with me or my work can trust by proxy. The same applies to Brandon. I honestly don't know Brandon very well, but I have a high level of trust for Kyle. Kyle trusts him, so +1 from me. I tried to digest it these days, and I still have problems with it. In my world, trust indeed can be based on proxy referrals, but not solely. Usually whenever there are nominations sent, I already have a clue of how candidates contribute to the repo, their goods and bads. If not, I always have a source of truth to fix the lack of knowledge (stackalytics, git log, ...) If I have no ways to know, I don't feel like I'm in the position to +1 a nomination. If the vote is to be based solely on my trust in Kyle, then I'm better not to vote at all (that's what I did) and defer to Kyle alone to make a judgement. With this new world, do we even need to vote? Kyle has a tough role here. It means he gives up some control, but it's the way the project will scale. Kyle doesn't have to develop a close trust relationship with everyone merging code into the main neutron repo, much less all the other repos. He can delegate some of that. It only works if everyone buys into this way of thinking. Agreed, though there is still should be some kind of relationship between team members, if not with Kyle. I think the discussion is not about delegation though; but about criteria that we apply to core reviewers, both existing and new ones. Kyle removed several members from the core team before because of their low review stats (in the past, not in the future), and I believe it was the right thing to do. But then we should probably apply similar requirements to new candidates. Now, I see Kyle's point in trying to push for more proxy trust in neutron, and I also think that I may miss new developments in project governance, and indeed adding more cores in the team is a good thing, especially from those contributors that showed their effectiveness in other openstack projects (ovn, nova for Russell; lbaas for Brandon). I only want to make sure that by doing it we don't lower criteria to core reviewers in terms of number of reviews etc. I see we lag on it. And also I am concerned that we may suggest to others that non-core reviews are somehow insignificant and that collecting some review stats for several months or even weeks is considered a pointless effort unless it's done with a core hammer. I value reviews of multiple openstack folks who are not cores in neutron, f.e. @otherwiseguy and @gsagie for anything ovsdb related; or @zzzeek for all things sql-ish; or @salv-orlando for all things API/policy/how the world started to exist; or @jlibosva for anything python-esoteric; or @moshele for sr-iov... The list follows. I don't want them to feel their reviews are not that valuable if not +2. Ihar -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJV1L7sAAoJEC5aWaUY1u57rhYIAOCxX5K8HbHNcUYh33/rvTRc InqvoKKu5NWFU4s+iUZly1Fu5/3JXzLR5h8/+1b/gWR5EDYJ2Q6FRy5Bmn6Fduuw cHV6trqGfEmA+NJsvNSNeg1Ux8hQ0hjdcF0mcrMhM0li+DFDMwogHMxPUAzKF4Cm fcMDr+aZW3zkUDi0Y/iUjxqWwQFOBwPg0gWhKqhasVTqbOfd0W62z4gT9o6ZYkdn mJr6jU+qc1hV+St03qpgLN9h/S023Ha1PCnMBUfjldbthmVBtJEsgmyfHlqWpWmc UGSH7vTv6EmSSVcvZmAuCSZQKeG4UaodbApNusELFTA4zSK6GeKgJL9hr9MfkCs= =ZXGT -END PGP SIGNATURE- __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:
[openstack-dev] [neutron] What does being a neutron-core member mean? [WAS: Re: [neutron] I am pleased to propose two new Neutron API/DB/RPC core reviewers!]
-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. 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]. 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), 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. 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. 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? 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. 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? Thanks! Kyle [1] http://docs.openstack.org/developer/neutron/policies/core-reviewers.h tml#neutron-core-reviewers [2] http://docs.openstack.org/developer/neutron/policies/core-reviewers.h tml#adding-or-removing-core-reviewers [3] http://docs.openstack.org/developer/neutron/policies/core-reviewers.h tml#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/
Re: [openstack-dev] [neutron] What does being a neutron-core member mean? [WAS: Re: [neutron] I am pleased to propose two new Neutron API/DB/RPC core reviewers!]
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? 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
Re: [openstack-dev] [neutron] What does being a neutron-core member mean? [WAS: Re: [neutron] I am pleased to propose two new Neutron API/DB/RPC core reviewers!]
On Fri, Aug 14, 2015 at 10:00 AM, Flavio Percoco fla...@redhat.com wrote: On 14/08/15 10:42 -0400, Assaf Muller wrote: 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: 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'm not really familiar with Neutron's workflow but as an outsider and also based on my experience from other projects, the separation of concerns from a review perspective is very useful. Teams that govern several projects are be better off giving reviewing rights to folks in a per-project basis rather than doing it cross-team. I'd go as far as saying that folks with review rights in the server don't necessarily need to have review rights in smaller projects. The reason I'm saying this is because I believe that reviewer rights is not a prize but a volunteer job. The moment I'm asked whether I want to join a reviewers team in a project, I gotta be honest with what my available time will allow me to do. What you just said is what I've been trying to emphasize my entire time as PTL: Reviewing is a duty, not a prize. The thing we're discussing here is the issue of when to give someone +2 rights. I'm arguing in favor of a web of trust system, which is what we have with Lieutenants. I'm also saying that I'm a proponent of elevating folks who want to take on the duty and letting them do that before they spend a month building up stats. This is not an opinion shared by everyone I realize, but it's my opinion. Like I've said in this thread, the entire system is built on trust. We as a community need to trust more and rely on that trust. I feel as if I've spent my PTL time trying to build that up and instill this value into the Neutron community. The results speak for themselves at this point, but I'm proud of what *we* as a community have built here. Kyle To what I just said, I'd also add the familiarity with the code-base, etc. Just my $0.02, Flavio -- @flaper87 Flavio Percoco __ 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
Re: [openstack-dev] [neutron] What does being a neutron-core member mean? [WAS: Re: [neutron] I am pleased to propose two new Neutron API/DB/RPC core reviewers!]
On Fri, Aug 14, 2015 at 9:42 AM, Assaf Muller amul...@redhat.com wrote: 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'd argue the system is built on a web of trust. If you trust me, and I trust Russell and Brandon, then you should likely trust Russell and Brandon as well. This is EXACTLY what the Lieutenant system was meant to convey, though I now feel like perhaps people missed this key ingredient of the new world we find ourselves in. 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
Re: [openstack-dev] [neutron] What does being a neutron-core member mean? [WAS: Re: [neutron] I am pleased to propose two new Neutron API/DB/RPC core reviewers!]
On 14/08/15 10:14 -0500, Kyle Mestery wrote: On Fri, Aug 14, 2015 at 10:00 AM, Flavio Percoco fla...@redhat.com wrote: On 14/08/15 10:42 -0400, Assaf Muller wrote: 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: 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'm not really familiar with Neutron's workflow but as an outsider and also based on my experience from other projects, the separation of concerns from a review perspective is very useful. Teams that govern several projects are be better off giving reviewing rights to folks in a per-project basis rather than doing it cross-team. I'd go as far as saying that folks with review rights in the server don't necessarily need to have review rights in smaller projects. The reason I'm saying this is because I believe that reviewer rights is not a prize but a volunteer job. The moment I'm asked whether I want to join a reviewers team in a project, I gotta be honest with what my available time will allow me to do. What you just said is what I've been trying to emphasize my entire time as PTL: Reviewing is a duty, not a prize. The thing we're discussing here is the issue of when to give someone +2 rights. I'm arguing in favor of a web of trust system, which is what we have with Lieutenants. I'm also saying that I'm a proponent of elevating folks who want to take on the duty and letting them do that before they spend a month building up stats. This is not an opinion shared by everyone I realize, but it's my opinion. Like I've said in this thread, the entire system is built on trust. We as a community need to trust more and rely on that trust. I feel as if I've spent my PTL time trying to build that up and instill this value into the Neutron community. The results speak for themselves at this point, but I'm proud of what *we* as a community have built here. Different projects follow different rules. Some projects favor stats, others favor enthusiasm and try to build a stronger community based on that. I just wanted to say that I personally favor building a web of trust rather than relying *just* on stats! Flavio Kyle To what I just said, I'd also add the familiarity with the code-base, etc. Just my $0.02, Flavio -- @flaper87 Flavio Percoco __ 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 -- @flaper87 Flavio Percoco pgpqcBa2YEmN5.pgp Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
Re: [openstack-dev] [neutron] What does being a neutron-core member mean? [WAS: Re: [neutron] I am pleased to propose two new Neutron API/DB/RPC core reviewers!]
On 14/08/15 10:42 -0400, Assaf Muller wrote: 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: 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'm not really familiar with Neutron's workflow but as an outsider and also based on my experience from other projects, the separation of concerns from a review perspective is very useful. Teams that govern several projects are be better off giving reviewing rights to folks in a per-project basis rather than doing it cross-team. I'd go as far as saying that folks with review rights in the server don't necessarily need to have review rights in smaller projects. The reason I'm saying this is because I believe that reviewer rights is not a prize but a volunteer job. The moment I'm asked whether I want to join a reviewers team in a project, I gotta be honest with what my available time will allow me to do. To what I just said, I'd also add the familiarity with the code-base, etc. Just my $0.02, Flavio -- @flaper87 Flavio Percoco pgpGiXIqLqCmO.pgp Description: 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
Re: [openstack-dev] [neutron] What does being a neutron-core member mean? [WAS: Re: [neutron] I am pleased to propose two new Neutron API/DB/RPC core reviewers!]
While this includes me, I'm really not taking this personally. I'm thinking about it in the general sense. On 08/14/2015 11:03 AM, Kyle Mestery wrote: I'd argue the system is built on a web of trust. If you trust me, and I trust Russell and Brandon, then you should likely trust Russell and Brandon as well. This is EXACTLY what the Lieutenant system was meant to convey, though I now feel like perhaps people missed this key ingredient of the new world we find ourselves in. This is a huge and important point. The N to N trust model we've been operating under doesn't scale. Neutron is trying to move to a different trust model that has proven to scale much further than we've been able to do within a single OpenStack project so far. If Kyle and others leading a section of Neutron trust me, I'm happy to jump in and do more reviews. If they trust me, I'd hope others not as familiar with me or my work can trust by proxy. The same applies to Brandon. I honestly don't know Brandon very well, but I have a high level of trust for Kyle. Kyle trusts him, so +1 from me. Kyle has a tough role here. It means he gives up some control, but it's the way the project will scale. Kyle doesn't have to develop a close trust relationship with everyone merging code into the main neutron repo, much less all the other repos. He can delegate some of that. It only works if everyone buys into this way of thinking. -- Russell Bryant __ 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
Re: [openstack-dev] [neutron] What does being a neutron-core member mean? [WAS: Re: [neutron] I am pleased to propose two new Neutron API/DB/RPC core reviewers!]
I don't want to jump in where i am not suppose to, and i know everyone saying it isn't personal, but i have had the pleasure to work with Russell on the OVN project for the last couple of months, i think his dedication to the project and Neutron, his understanding of what open source community means and his proven experience make him exactly the type of people Neutron need. i think that for the rest he can pick up and probably experienced enough to pick his votes. Everyone are talking about reviews, i think there are other important duties and not only for core reviewers, but for every experienced person involved in Neutron and thats mentoring and helping bringing up more people to the project and understand the open source way. (this is not trivial as it takes time mentoring and not always a rewording job) I personally have had the pleasure to receive help on various topics from many of the core reviewers team and also trying to pass it forward when ever i can, so thanks everyone that helped :) (don't want to start mentioning names) I like the Neutron community, and very happy to be part of this project, lets help more people feel like that and join in. Gal. On Fri, Aug 14, 2015 at 6:14 PM, Kyle Mestery mest...@mestery.com wrote: On Fri, Aug 14, 2015 at 10:00 AM, Flavio Percoco fla...@redhat.com wrote: On 14/08/15 10:42 -0400, Assaf Muller wrote: 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: 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'm not really familiar with Neutron's workflow but as an outsider and also based on my experience from other projects, the separation of concerns from a review perspective is very useful. Teams that govern several projects are be better off giving reviewing rights to folks in a per-project basis rather than doing it cross-team. I'd go as far as saying that folks with review rights in the server don't necessarily need to have review rights in smaller projects. The reason I'm saying this is because I believe that reviewer rights is not a prize but a volunteer job. The moment I'm asked whether I want to join a reviewers team in a project, I gotta be honest with what my available time will allow me to do. What you just said is what I've been trying to emphasize my entire time as PTL: Reviewing is a duty, not a prize. The thing we're discussing here is the issue of when to give someone +2 rights. I'm arguing in favor of a web of trust system, which is what we have with Lieutenants. I'm also saying that I'm a proponent of elevating folks who want to take on the duty and letting them do that before they spend a month building up stats. This is not an opinion shared by everyone I realize, but it's my opinion. Like I've said in this thread, the entire system is built on trust. We as a community need to trust more and rely on that trust. I feel as if I've spent my PTL time trying to build that up and instill this value into the Neutron community. The results speak for themselves at this point, but I'm proud of what *we* as a community have built here. Kyle To what I just said, I'd also add the familiarity with the code-base, etc. Just my $0.02, Flavio -- @flaper87 Flavio Percoco
