Re: [openstack-dev] [tc] Organizational diversity tag
IMO, the goal is that we try to encourage the good, not to get in the way to those who can't reach that goal. A tag is a good way to encourage, but it also not a fair way for those projects who barely got enough core member to review (Think about those projects got less than four active cores). Wondering if anyone got ideas on how we can reach that goal (tag can be a way, just IMO need to provide a fair condition to all). How about we set policy and document to encourage people to join core reviewer (this can join forces with the Enterprise guideline we plan in Forum) if they wish to provide diversity to project. On the second idea, I think TC (or people who powered by TC) should provide (or guidance project to provide) a health check report for projects. TCs have been looking for Liaisons with projects ([1]). This definitely is a good report as a feedback from projects to TC. (also a good way to understand what each project been doing and is that project need any help). So to provide a guideline for projects to understand how they can do better. Guideline means both -1 and +1 (for who running projects for long enough to be a core/PTL, should at least understand that -1 only means since this project is under TC's guidance, we just try to help.). Therefore a -1 is important. As an alternative, we can also try to target problem when it occurred, but personally wonder who as a single core reviewer in team dear to speak out in this case. I think this is a hard issue to do, but we have to pick one action from all actions and try to run and see. And it's better than keep things the way they are and ignore things. [1] https://wiki.openstack.org/wiki/Technical_Committee_Tracker#Liaisons Michael Johnson 於 2018年6月7日 週四 上午2:48寫道： > Octavia also has an informal rule about two cores from the same > company merging patches. I support this because it makes sure we have > a diverse perspective on the patches. Specifically it has worked well > for us as all of the cores have different cloud designs, so it catches > anything that would limit/conflict with the different OpenStack > topologies. > > That said, we don't hard enforce this or police it, it is just an > informal policy to make sure we get input from the wider team. > Currently we only have one company with two cores. > > That said, my issue with the current diversity calculations is they > tend to be skewed by the PTL role. People have a tendency to defer to > the PTL to review/comment/merge patches, so if the PTL shares a > company with another core the diversity numbers get skewed heavily > towards that company. > > Michael > > On Wed, Jun 6, 2018 at 5:06 AM, wrote: > >> -Original Message- > >> From: Doug Hellmann > >> Sent: Monday, June 4, 2018 5:52 PM > >> To: openstack-dev > >> Subject: Re: [openstack-dev] [tc] Organizational diversity tag > >> > >> Excerpts from Zane Bitter's message of 2018-06-04 17:41:10 -0400: > >> > On 02/06/18 13:23, Doug Hellmann wrote: > >> > > Excerpts from Zane Bitter's message of 2018-06-01 15:19:46 -0400: > >> > >> On 01/06/18 12:18, Doug Hellmann wrote: > >> > > > >> > > [snip] > >> > Apparently enough people see it the way you described that this is > >> > probably not something we want to actively spread to other projects at > >> > the moment. > >> > >> I am still curious to know which teams have the policy. If it is more > >> widespread than I realized, maybe it's reasonable to extend it and use > it as > >> the basis for a health check after all. > >> > > > > A while back, Trove had this policy. When Rackspace, HP, and Tesora had > core reviewers, (at various times, eBay, IBM and Red Hat also had cores), > the agreement was that multiple cores from any one company would not merge > a change unless it was an emergency. It was not formally written down (to > my knowledge). > > > > It worked well, and ensured that the operators didn't get surprised by > some unexpected thing that took down their service. > > > > -amrith > > > > > > > __ > > 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 > -- May The Force of OpenStack Be With You, *Rico Lin*irc: ricolin __ 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] [tc] Organizational diversity tag
Octavia also has an informal rule about two cores from the same company merging patches. I support this because it makes sure we have a diverse perspective on the patches. Specifically it has worked well for us as all of the cores have different cloud designs, so it catches anything that would limit/conflict with the different OpenStack topologies. That said, we don't hard enforce this or police it, it is just an informal policy to make sure we get input from the wider team. Currently we only have one company with two cores. That said, my issue with the current diversity calculations is they tend to be skewed by the PTL role. People have a tendency to defer to the PTL to review/comment/merge patches, so if the PTL shares a company with another core the diversity numbers get skewed heavily towards that company. Michael On Wed, Jun 6, 2018 at 5:06 AM, wrote: >> -Original Message- >> From: Doug Hellmann >> Sent: Monday, June 4, 2018 5:52 PM >> To: openstack-dev >> Subject: Re: [openstack-dev] [tc] Organizational diversity tag >> >> Excerpts from Zane Bitter's message of 2018-06-04 17:41:10 -0400: >> > On 02/06/18 13:23, Doug Hellmann wrote: >> > > Excerpts from Zane Bitter's message of 2018-06-01 15:19:46 -0400: >> > >> On 01/06/18 12:18, Doug Hellmann wrote: >> > > >> > > [snip] >> > Apparently enough people see it the way you described that this is >> > probably not something we want to actively spread to other projects at >> > the moment. >> >> I am still curious to know which teams have the policy. If it is more >> widespread than I realized, maybe it's reasonable to extend it and use it as >> the basis for a health check after all. >> > > A while back, Trove had this policy. When Rackspace, HP, and Tesora had core > reviewers, (at various times, eBay, IBM and Red Hat also had cores), the > agreement was that multiple cores from any one company would not merge a > change unless it was an emergency. It was not formally written down (to my > knowledge). > > It worked well, and ensured that the operators didn't get surprised by some > unexpected thing that took down their service. > > -amrith > > > __ > 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] [tc] Organizational diversity tag
> -Original Message- > From: Doug Hellmann > Sent: Monday, June 4, 2018 5:52 PM > To: openstack-dev > Subject: Re: [openstack-dev] [tc] Organizational diversity tag > > Excerpts from Zane Bitter's message of 2018-06-04 17:41:10 -0400: > > On 02/06/18 13:23, Doug Hellmann wrote: > > > Excerpts from Zane Bitter's message of 2018-06-01 15:19:46 -0400: > > >> On 01/06/18 12:18, Doug Hellmann wrote: > > > > > > [snip] > > Apparently enough people see it the way you described that this is > > probably not something we want to actively spread to other projects at > > the moment. > > I am still curious to know which teams have the policy. If it is more > widespread than I realized, maybe it's reasonable to extend it and use it as > the basis for a health check after all. > A while back, Trove had this policy. When Rackspace, HP, and Tesora had core reviewers, (at various times, eBay, IBM and Red Hat also had cores), the agreement was that multiple cores from any one company would not merge a change unless it was an emergency. It was not formally written down (to my knowledge). It worked well, and ensured that the operators didn't get surprised by some unexpected thing that took down their service. -amrith __ 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] [tc] Organizational diversity tag
Excerpts from Fox, Kevin M's message of 2018-06-05 16:09:24 +: > That might not be a good idea. That may just push the problem underground as > people are afraid to speak up publicly. > > Perhaps an anonymous poll kind of thing, so that it can be counted publicly > but doesn't cause people to fear retaliation? I have no idea how to judge the outcome of any sort of anonymous poll. And I really don't want my inbox to become one. :-) We do our best to make governance decisions openly, based on the information we have. But in more cases than I like we end up making assumptions based on extrapolating from a small number of experiences relayed privately. I don't want to base a review diversity policy that may end up making it harder to accept contribution on assumptions. Maybe if folks aren't comfortable talking publicly, they can talk to their PTLs privately? Then we can get a sense of which teams feel this sort of pressure, overall, instead of individuals. > > Thanks, > Kevin > > From: Doug Hellmann [d...@doughellmann.com] > Sent: Tuesday, June 05, 2018 7:39 AM > To: openstack-dev > Subject: Re: [openstack-dev] [tc] Organizational diversity tag > > Excerpts from Doug Hellmann's message of 2018-06-02 15:08:28 -0400: > > Excerpts from Jeremy Stanley's message of 2018-06-02 18:51:47 +: > > > On 2018-06-02 13:23:24 -0400 (-0400), Doug Hellmann wrote: > > > [...] > > > > It feels like we would be saying that we don't trust 2 core reviewers > > > > from the same company to put the project's goals or priorities over > > > > their employer's. And that doesn't feel like an assumption I would > > > > want us to encourage through a tag meant to show the health of the > > > > project. > > > [...] > > > > > > That's one way of putting it. On the other hand, if we ostensibly > > > have that sort of guideline (say, two core reviewers shouldn't be > > > the only ones to review a change submitted by someone else from > > > their same organization if the team is large and diverse enough to > > > support such a pattern) then it gives our reviewers a better > > > argument to push back on their management _if_ they're being > > > strongly urged to review/approve certain patches. At least then they > > > can say, "this really isn't going to fly because we have to get a > > > reviewer from another organization to agree it's in the best > > > interests of the project" rather than "fire me if you want but I'm > > > not approving that change, no matter how much your product launch is > > > going to be delayed." > > > > Do we have that problem? I honestly don't know how much pressure other > > folks are feeling. My impression is that we've mostly become good at > > finding the necessary compromises, but my experience doesn't cover all > > of our teams. > > To all of the people who have replied to me privately that they have > experienced this problem: > > We can't really start to address it until it's out here in the open. > Please post to the list. > > Doug > __ 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] [tc] Organizational diversity tag
That might not be a good idea. That may just push the problem underground as people are afraid to speak up publicly. Perhaps an anonymous poll kind of thing, so that it can be counted publicly but doesn't cause people to fear retaliation? Thanks, Kevin From: Doug Hellmann [d...@doughellmann.com] Sent: Tuesday, June 05, 2018 7:39 AM To: openstack-dev Subject: Re: [openstack-dev] [tc] Organizational diversity tag Excerpts from Doug Hellmann's message of 2018-06-02 15:08:28 -0400: > Excerpts from Jeremy Stanley's message of 2018-06-02 18:51:47 +: > > On 2018-06-02 13:23:24 -0400 (-0400), Doug Hellmann wrote: > > [...] > > > It feels like we would be saying that we don't trust 2 core reviewers > > > from the same company to put the project's goals or priorities over > > > their employer's. And that doesn't feel like an assumption I would > > > want us to encourage through a tag meant to show the health of the > > > project. > > [...] > > > > That's one way of putting it. On the other hand, if we ostensibly > > have that sort of guideline (say, two core reviewers shouldn't be > > the only ones to review a change submitted by someone else from > > their same organization if the team is large and diverse enough to > > support such a pattern) then it gives our reviewers a better > > argument to push back on their management _if_ they're being > > strongly urged to review/approve certain patches. At least then they > > can say, "this really isn't going to fly because we have to get a > > reviewer from another organization to agree it's in the best > > interests of the project" rather than "fire me if you want but I'm > > not approving that change, no matter how much your product launch is > > going to be delayed." > > Do we have that problem? I honestly don't know how much pressure other > folks are feeling. My impression is that we've mostly become good at > finding the necessary compromises, but my experience doesn't cover all > of our teams. To all of the people who have replied to me privately that they have experienced this problem: We can't really start to address it until it's out here in the open. Please post to the list. Doug __ 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] [tc] Organizational diversity tag
Excerpts from Doug Hellmann's message of 2018-06-02 15:08:28 -0400: > Excerpts from Jeremy Stanley's message of 2018-06-02 18:51:47 +: > > On 2018-06-02 13:23:24 -0400 (-0400), Doug Hellmann wrote: > > [...] > > > It feels like we would be saying that we don't trust 2 core reviewers > > > from the same company to put the project's goals or priorities over > > > their employer's. And that doesn't feel like an assumption I would > > > want us to encourage through a tag meant to show the health of the > > > project. > > [...] > > > > That's one way of putting it. On the other hand, if we ostensibly > > have that sort of guideline (say, two core reviewers shouldn't be > > the only ones to review a change submitted by someone else from > > their same organization if the team is large and diverse enough to > > support such a pattern) then it gives our reviewers a better > > argument to push back on their management _if_ they're being > > strongly urged to review/approve certain patches. At least then they > > can say, "this really isn't going to fly because we have to get a > > reviewer from another organization to agree it's in the best > > interests of the project" rather than "fire me if you want but I'm > > not approving that change, no matter how much your product launch is > > going to be delayed." > > Do we have that problem? I honestly don't know how much pressure other > folks are feeling. My impression is that we've mostly become good at > finding the necessary compromises, but my experience doesn't cover all > of our teams. To all of the people who have replied to me privately that they have experienced this problem: We can't really start to address it until it's out here in the open. Please post to the list. Doug __ 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] [tc] Organizational diversity tag
Sorry if I missed/repeat something already said in this thread... When I am looking at diversity, I generally like to know: 1) what's going on "right now", and 2) what happened in the cycle x. I think these 2 are different problems to solve. And tags are, IMO, best applied to the second case. So if I focus on the second: What if we are only tagging once per cycle, after the release? (I am pushing the idea further than the quarter basically). It would avoid flappiness (if that's a proper term?). For me, a cycle has a clear meaning. And involvements can balance out in a cycle. This would be, IMO, good enough to promote/declare diversity after the facts (and is an answer to the "what happened during the cycle"). Jean-Philippe Evrard (evrardjp) __ 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] [tc] Organizational diversity tag
On Jun 4, 2018, at 2:10 PM, Doug Hellmann wrote: > >> Those rules were added because we wanted to avoid the appearance of one >> company implementing features that would only be beneficial to it. This >> arose from concerns in the early days when Rackspace was the dominant >> contributor: many of the other companies involved in OpenStack were worried >> that they would be investing their workers in a project that would only >> benefit Rackspace. As far as I know, there were never specific cases where >> Rackspace or any other company tried to push features in that no one else >> supported.. >> >> So even if now it doesn't seem that there is a problem, and we could remove >> these restrictions without ill effect, it just seems prudent to keep them. >> If a project is so small that the majority of its contributors/cores are >> from one company, maybe it should be an internal project for that company, >> and not a community project. >> >> -- Ed Leafe > > Where was the rule added, though? I am aware of some individual teams > with the rule, but AFAIK it was never a global rule. It's certainly not > in any of the projects for which I am currently a core reviewer. If you're looking for a reference to a particular bit of governance, I can't help you there. But being one of the Nova cores who worked for Rackspace back then, I was part of many such discussions, and can tell you that Rackspace was very conscious of not wanting to appear to be dictating the direction, and that this agreement not to approve code committed by other Rackers was an important part of that. -- Ed Leafe signature.asc Description: Message signed with OpenPGP __ 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] [tc] Organizational diversity tag
On 2018-06-04 17:52:28 -0400 (-0400), Doug Hellmann wrote: [...] > I am still curious to know which teams have the policy. If it is more > widespread than I realized, maybe it's reasonable to extend it and use > it as the basis for a health check after all. [...] Not team-wide, but I have a personal policy that I try to avoid approving a change if both the author and any other core reviews on that change are from people paid by the same organization which funds my time (unless I have a very good reason, and then I leave a clear review comment when approving in such situations). It's not so much a matter of a lack of trust on anyone's part, as a desire for me to keep and further improve on that trust I've already built. -- Jeremy Stanley signature.asc 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] [tc] Organizational diversity tag
On 04/06/18 17:52, Doug Hellmann wrote: Excerpts from Zane Bitter's message of 2018-06-04 17:41:10 -0400: On 02/06/18 13:23, Doug Hellmann wrote: Excerpts from Zane Bitter's message of 2018-06-01 15:19:46 -0400: On 01/06/18 12:18, Doug Hellmann wrote: [snip] Is that rule a sign of a healthy team dynamic, that we would want to spread to the whole community? Yeah, this part I am pretty unsure about too. For some projects it probably is. For others it may just be an unnecessary obstacle, although I don't think it'd actually be *un*healthy for any project, assuming a big enough and diverse enough team (which should be a goal for the whole community). It feels like we would be saying that we don't trust 2 core reviewers from the same company to put the project's goals or priorities over their employer's. And that doesn't feel like an assumption I would want us to encourage through a tag meant to show the health of the project. Another way to look at it would be that the perception of a conflict of interest can be just as damaging to a community as somebody actually acting on a conflict of interest, and thus having clearly-defined rules to manage conflicts of interest helps protect everybody (and especially the people who could be perceived to have a conflict of interest but aren't, in fact, acting on it). That's a reasonable perspective. Thanks for expanding on your original statement. Apparently enough people see it the way you described that this is probably not something we want to actively spread to other projects at the moment. I am still curious to know which teams have the policy. If it is more widespread than I realized, maybe it's reasonable to extend it and use it as the basis for a health check after all. At least Nova still does, judging by this comment from Matt Riedemann in January: "For the record, it's not cool for two cores from the same company to be the sole +2s on a change contributed by the same company. Pretty standard operating procedure." (on https://review.openstack.org/#/c/523958/18) When this thread started I looked for somewhere that was documented more permanently, but I didn't find it. The appealing part of the idea to me was that we could stop pretending that the results of our mindless script are objective - despite the fact that both the subset of information to rely on and the limits in the script were chosen by someone, in an essentially arbitrary way - and let the decision rest on the expertise of those who are closest to the project (and therefore have the most information), while aligning their incentives with the needs of users so that they're not being asked to keep their own score. I'm always on the lookout for opportunities to do that, so I felt like I had to at least float it. The alignment goes both ways though, and if we'd be creating an incentive to extend the coverage of a policy that is already controversial then this is not the way forward. cheers, Zane. __ 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] [tc] Organizational diversity tag
On 04/06/18 17:52 -0400, Doug Hellmann wrote: Excerpts from Zane Bitter's message of 2018-06-04 17:41:10 -0400: On 02/06/18 13:23, Doug Hellmann wrote: > Excerpts from Zane Bitter's message of 2018-06-01 15:19:46 -0400: >> On 01/06/18 12:18, Doug Hellmann wrote: > > [snip] > >>> Is that rule a sign of a healthy team dynamic, that we would want >>> to spread to the whole community? >> >> Yeah, this part I am pretty unsure about too. For some projects it >> probably is. For others it may just be an unnecessary obstacle, although >> I don't think it'd actually be *un*healthy for any project, assuming a >> big enough and diverse enough team (which should be a goal for the whole >> community). > > It feels like we would be saying that we don't trust 2 core reviewers > from the same company to put the project's goals or priorities over > their employer's. And that doesn't feel like an assumption I would > want us to encourage through a tag meant to show the health of the > project. Another way to look at it would be that the perception of a conflict of interest can be just as damaging to a community as somebody actually acting on a conflict of interest, and thus having clearly-defined rules to manage conflicts of interest helps protect everybody (and especially the people who could be perceived to have a conflict of interest but aren't, in fact, acting on it). That's a reasonable perspective. Thanks for expanding on your original statement. Apparently enough people see it the way you described that this is probably not something we want to actively spread to other projects at the moment. I am still curious to know which teams have the policy. If it is more widespread than I realized, maybe it's reasonable to extend it and use it as the basis for a health check after all. Just some data. Manila has the policy (except for very trivial or urgent commits, where one +2 +W can be sufficient). When the project originated NetApp cores and a Mirantis core who was a contractor for NetApp predominated. I doubt that there was any perception of biased decisions -- the PTL at the time, Ben Swartzlander, is the kind of guy who is quite good at doing what he thinks is best for the project and not listening to any folks within his own company who might suggest otherwise, not that I have any evidence of anything like that either :). But at some point someone suggested that our +2 +W rule, already in place, be augmented with a requirement that the two +2s come from different affiliations and the rule was adopted. So far that seems to work OK though affiliations have shifted and NetApp cores are no longer quantitatively dominant in the project. There are three companies with two cores and so far as I can see they don't tend to vote together more than any other two cores, on the one hand, but on the other hand it isn't hard to get another core +2 if a change is ready to be merged. None of this is intended as an argument that this rule be expanded to other projects, it's just data as I said. -- Tom __ 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] [tc] Organizational diversity tag
I am still curious to know which teams have the policy. If it is more widespread than I realized, maybe it's reasonable to extend it and use it as the basis for a health check after all. I think it's been an unwritten "guideline" in Cinder, but not a hard rule. __ 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] [tc] Organizational diversity tag
Excerpts from Zane Bitter's message of 2018-06-04 17:41:10 -0400: > On 02/06/18 13:23, Doug Hellmann wrote: > > Excerpts from Zane Bitter's message of 2018-06-01 15:19:46 -0400: > >> On 01/06/18 12:18, Doug Hellmann wrote: > > > > [snip] > > > >>> Is that rule a sign of a healthy team dynamic, that we would want > >>> to spread to the whole community? > >> > >> Yeah, this part I am pretty unsure about too. For some projects it > >> probably is. For others it may just be an unnecessary obstacle, although > >> I don't think it'd actually be *un*healthy for any project, assuming a > >> big enough and diverse enough team (which should be a goal for the whole > >> community). > > > > It feels like we would be saying that we don't trust 2 core reviewers > > from the same company to put the project's goals or priorities over > > their employer's. And that doesn't feel like an assumption I would > > want us to encourage through a tag meant to show the health of the > > project. > > Another way to look at it would be that the perception of a conflict of > interest can be just as damaging to a community as somebody actually > acting on a conflict of interest, and thus having clearly-defined rules > to manage conflicts of interest helps protect everybody (and especially > the people who could be perceived to have a conflict of interest but > aren't, in fact, acting on it). That's a reasonable perspective. Thanks for expanding on your original statement. > Apparently enough people see it the way you described that this is > probably not something we want to actively spread to other projects at > the moment. I am still curious to know which teams have the policy. If it is more widespread than I realized, maybe it's reasonable to extend it and use it as the basis for a health check after all. > The appealing part of the idea to me was that we could stop pretending > that the results of our mindless script are objective - despite the fact > that both the subset of information to rely on and the limits in the > script were chosen by someone, in an essentially arbitrary way - and let > the decision rest on the expertise of those who are closest to the > project (and therefore have the most information), while aligning their > incentives with the needs of users so that they're not being asked to > keep their own score. I'm always on the lookout for opportunities to do > that, so I felt like I had to at least float it. > > The alignment goes both ways though, and if we'd be creating an > incentive to extend the coverage of a policy that is already > controversial then this is not the way forward. > > cheers, > Zane. > __ 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] [tc] Organizational diversity tag
On 02/06/18 13:23, Doug Hellmann wrote: Excerpts from Zane Bitter's message of 2018-06-01 15:19:46 -0400: On 01/06/18 12:18, Doug Hellmann wrote: [snip] Is that rule a sign of a healthy team dynamic, that we would want to spread to the whole community? Yeah, this part I am pretty unsure about too. For some projects it probably is. For others it may just be an unnecessary obstacle, although I don't think it'd actually be *un*healthy for any project, assuming a big enough and diverse enough team (which should be a goal for the whole community). It feels like we would be saying that we don't trust 2 core reviewers from the same company to put the project's goals or priorities over their employer's. And that doesn't feel like an assumption I would want us to encourage through a tag meant to show the health of the project. Another way to look at it would be that the perception of a conflict of interest can be just as damaging to a community as somebody actually acting on a conflict of interest, and thus having clearly-defined rules to manage conflicts of interest helps protect everybody (and especially the people who could be perceived to have a conflict of interest but aren't, in fact, acting on it). Apparently enough people see it the way you described that this is probably not something we want to actively spread to other projects at the moment. The appealing part of the idea to me was that we could stop pretending that the results of our mindless script are objective - despite the fact that both the subset of information to rely on and the limits in the script were chosen by someone, in an essentially arbitrary way - and let the decision rest on the expertise of those who are closest to the project (and therefore have the most information), while aligning their incentives with the needs of users so that they're not being asked to keep their own score. I'm always on the lookout for opportunities to do that, so I felt like I had to at least float it. The alignment goes both ways though, and if we'd be creating an incentive to extend the coverage of a policy that is already controversial then this is not the way forward. cheers, Zane. __ 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] [tc] Organizational diversity tag
Excerpts from Ed Leafe's message of 2018-06-04 13:41:36 -0500: > On Jun 4, 2018, at 7:05 AM, Jay S Bryant wrote: > > >> Do we have that problem? I honestly don't know how much pressure other > >> folks are feeling. My impression is that we've mostly become good at > >> finding the necessary compromises, but my experience doesn't cover all > >> of our teams. > > In my experience this hasn't been a problem for quite some time. In the > > past, at least for Cinder, there were some minor cases of this but as > > projects have matured this has been less of an issue. > > Those rules were added because we wanted to avoid the appearance of one > company implementing features that would only be beneficial to it. This arose > from concerns in the early days when Rackspace was the dominant contributor: > many of the other companies involved in OpenStack were worried that they > would be investing their workers in a project that would only benefit > Rackspace. As far as I know, there were never specific cases where Rackspace > or any other company tried to push features in that no one else supported.. > > So even if now it doesn't seem that there is a problem, and we could remove > these restrictions without ill effect, it just seems prudent to keep them. If > a project is so small that the majority of its contributors/cores are from > one company, maybe it should be an internal project for that company, and not > a community project. > > -- Ed Leafe Where was the rule added, though? I am aware of some individual teams with the rule, but AFAIK it was never a global rule. It's certainly not in any of the projects for which I am currently a core reviewer. Doug __ 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] [tc] Organizational diversity tag
On Jun 4, 2018, at 7:05 AM, Jay S Bryant wrote: >> Do we have that problem? I honestly don't know how much pressure other >> folks are feeling. My impression is that we've mostly become good at >> finding the necessary compromises, but my experience doesn't cover all >> of our teams. > In my experience this hasn't been a problem for quite some time. In the > past, at least for Cinder, there were some minor cases of this but as > projects have matured this has been less of an issue. Those rules were added because we wanted to avoid the appearance of one company implementing features that would only be beneficial to it. This arose from concerns in the early days when Rackspace was the dominant contributor: many of the other companies involved in OpenStack were worried that they would be investing their workers in a project that would only benefit Rackspace. As far as I know, there were never specific cases where Rackspace or any other company tried to push features in that no one else supported.. So even if now it doesn't seem that there is a problem, and we could remove these restrictions without ill effect, it just seems prudent to keep them. If a project is so small that the majority of its contributors/cores are from one company, maybe it should be an internal project for that company, and not a community project. -- Ed Leafe signature.asc Description: Message signed with OpenPGP __ 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] [tc] Organizational diversity tag
On 6/2/2018 2:08 PM, Doug Hellmann wrote: Excerpts from Jeremy Stanley's message of 2018-06-02 18:51:47 +: On 2018-06-02 13:23:24 -0400 (-0400), Doug Hellmann wrote: [...] It feels like we would be saying that we don't trust 2 core reviewers from the same company to put the project's goals or priorities over their employer's. And that doesn't feel like an assumption I would want us to encourage through a tag meant to show the health of the project. [...] That's one way of putting it. On the other hand, if we ostensibly have that sort of guideline (say, two core reviewers shouldn't be the only ones to review a change submitted by someone else from their same organization if the team is large and diverse enough to support such a pattern) then it gives our reviewers a better argument to push back on their management _if_ they're being strongly urged to review/approve certain patches. At least then they can say, "this really isn't going to fly because we have to get a reviewer from another organization to agree it's in the best interests of the project" rather than "fire me if you want but I'm not approving that change, no matter how much your product launch is going to be delayed." Do we have that problem? I honestly don't know how much pressure other folks are feeling. My impression is that we've mostly become good at finding the necessary compromises, but my experience doesn't cover all of our teams. In my experience this hasn't been a problem for quite some time. In the past, at least for Cinder, there were some minor cases of this but as projects have matured this has been less of an issue. While I'd like to think a lot of us have the ability to push back on those sorts of adverse influences directly, I have a feeling not everyone can comfortably do so. On the other hand, it might also just be easy enough to give one of your fellow reviewers in another org a heads up that maybe they should take a look at that patch over there and provide some quick feedback... __ 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] [tc] Organizational diversity tag
amrith.ku...@gmail.com wrote: -Original Message- From: Doug Hellmann Sent: Saturday, June 2, 2018 4:26 PM To: openstack-dev Subject: Re: [openstack-dev] [tc] Organizational diversity tag Excerpts from amrith.kumar's message of 2018-06-02 15:06:27 -0400: Every project on the one-way-trip to inactivity starts with what some people will wishfully call a 'transient period' of reduced activity. Once the transient nature is no longer the case (either it becomes active or the transient becomes permanent) the normal process of eviction can begin. As the guy who came up with the maintenance-mode tag, so as to apply it to Trove, I believe that both the diversity tag and the maintenance mode tag have a good reason to exist, and should both be retained independent of each other. The logic always was, and should remain, that diversity is a measure of wide multi-organizational support for a project; not measured in the total volume of commits but the fraction of commits. There was much discussion about the knobs in the diversity tag measurement when Flavio made the changes some years back. I'm sorry I didn't attend the session in Vancouver but I'll try and tune in to a TC office hours session and maybe get a rundown of what precipitated this decision to move away from the diversity tag. We're talking about how to improve reporting on diversity, not stop doing it. Why not just automate the thing that we have right now and have something kick a review automatically if the diversity in a team changes (per current formula)? That is what we did: get the thing we have right now to propose changes. But we always had a quick human pass to check that what the script proposed corresponded to a reality. Lately (with lower activity in a number of teams), more and more automatically-proposed changes did not match a reality anymore, to the point where a majority of the proposed changes need to be dropped. Example: a low-activity single-vendor project team suddenly loses the tag because one person pushes a patch to fix zuul jobs and another pushes a doc build fix. Example 2: a team with 3 core reveiwers flaps between diverse affiliation and single-vendor depending on who does the core reviewing on its 3 patches per month. Hence the suggestion to either improve our metrics to better support low-activity teams, or switch to a more qualitative/prose report instead of quantitative/tags. -- Thierry Carrez (ttx) __ 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] [tc] Organizational diversity tag
> -Original Message- > From: Doug Hellmann > Sent: Saturday, June 2, 2018 4:26 PM > To: openstack-dev > Subject: Re: [openstack-dev] [tc] Organizational diversity tag > > Excerpts from amrith.kumar's message of 2018-06-02 15:06:27 -0400: > > Every project on the one-way-trip to inactivity starts with what some > > people will wishfully call a 'transient period' of reduced activity. > > Once the transient nature is no longer the case (either it becomes > > active or the transient becomes permanent) the normal process of > > eviction can begin. As the guy who came up with the maintenance-mode > > tag, so as to apply it to Trove, I believe that both the diversity tag > > and the maintenance mode tag have a good reason to exist, and should > > both be retained independent of each other. > > > > The logic always was, and should remain, that diversity is a measure > > of wide multi-organizational support for a project; not measured in > > the total volume of commits but the fraction of commits. There was > > much discussion about the knobs in the diversity tag measurement when > > Flavio made the changes some years back. I'm sorry I didn't attend the > > session in Vancouver but I'll try and tune in to a TC office hours > > session and maybe get a rundown of what precipitated this decision to > move away from the diversity tag. > > We're talking about how to improve reporting on diversity, not stop doing it. Why not just automate the thing that we have right now and have something kick a review automatically if the diversity in a team changes (per current formula)? > > Doug > > __ > > 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] [tc] Organizational diversity tag
Excerpts from amrith.kumar's message of 2018-06-02 15:06:27 -0400: > Every project on the one-way-trip to inactivity starts with what some people > will wishfully call a 'transient period' of reduced activity. Once the > transient nature is no longer the case (either it becomes active or the > transient becomes permanent) the normal process of eviction can begin. As > the guy who came up with the maintenance-mode tag, so as to apply it to > Trove, I believe that both the diversity tag and the maintenance mode tag > have a good reason to exist, and should both be retained independent of each > other. > > The logic always was, and should remain, that diversity is a measure of wide > multi-organizational support for a project; not measured in the total volume > of commits but the fraction of commits. There was much discussion about the > knobs in the diversity tag measurement when Flavio made the changes some > years back. I'm sorry I didn't attend the session in Vancouver but I'll try > and tune in to a TC office hours session and maybe get a rundown of what > precipitated this decision to move away from the diversity tag. We're talking about how to improve reporting on diversity, not stop doing it. Doug __ 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] [tc] Organizational diversity tag
Excerpts from Jeremy Stanley's message of 2018-06-02 18:51:47 +: > On 2018-06-02 13:23:24 -0400 (-0400), Doug Hellmann wrote: > [...] > > It feels like we would be saying that we don't trust 2 core reviewers > > from the same company to put the project's goals or priorities over > > their employer's. And that doesn't feel like an assumption I would > > want us to encourage through a tag meant to show the health of the > > project. > [...] > > That's one way of putting it. On the other hand, if we ostensibly > have that sort of guideline (say, two core reviewers shouldn't be > the only ones to review a change submitted by someone else from > their same organization if the team is large and diverse enough to > support such a pattern) then it gives our reviewers a better > argument to push back on their management _if_ they're being > strongly urged to review/approve certain patches. At least then they > can say, "this really isn't going to fly because we have to get a > reviewer from another organization to agree it's in the best > interests of the project" rather than "fire me if you want but I'm > not approving that change, no matter how much your product launch is > going to be delayed." Do we have that problem? I honestly don't know how much pressure other folks are feeling. My impression is that we've mostly become good at finding the necessary compromises, but my experience doesn't cover all of our teams. > > While I'd like to think a lot of us have the ability to push back on > those sorts of adverse influences directly, I have a feeling not > everyone can comfortably do so. On the other hand, it might also > just be easy enough to give one of your fellow reviewers in another > org a heads up that maybe they should take a look at that patch over > there and provide some quick feedback... __ 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] [tc] Organizational diversity tag
> -Original Message- > From: Zane Bitter > Sent: Friday, June 1, 2018 10:11 AM > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] [tc] Organizational diversity tag > > On 26/05/18 17:46, Mohammed Naser wrote: > > Hi everyone! > > > > During the TC retrospective at the OpenStack summit last week, the > > topic of the organizational diversity tag is becoming irrelevant was > > brought up by Thierry (ttx)[1]. It seems that for projects that are > > not very active, they can easily lose this tag with a few changes by > > perhaps the infrastructure team for CI related fixes. > > > > As an action item, Thierry and I have paired up in order to look into > > a way to resolve this issue. There have been ideas to switch this to > > a report that is published at the end of the cycle rather than > > continuously. Julia (TheJulia) suggested that we change or track > > different types of diversity. > > > > Before we start diving into solutions, I wanted to bring this topic up > > to the mailing list and ask for any suggestions. In digging the > > codebase behind this[2], I've found that there are some knobs that we > > can also tweak if need-be, or perhaps we can adjust those numbers > > depending on the number of commits. > > Crazy idea: what if we dropped the idea of measuring the diversity and > allowed teams to decide when they applied the tag to themselves like we do > for other tags. (No wait! Come back!) > > Some teams enforce a requirement that the 2 core +2s come from reviewers > with different affiliations. We would say that any project that enforces that > rule would get the diversity tag. Then it's actually attached to something > concrete, and teams could decide for themselves when to drop it (because > they would start having difficulty merging stuff otherwise). > [Amrith Kumar] Isn't that what the current formula would flag as being a diverse project 😊 > I'm not entirely sold on this, but it's an idea I had that I wanted to throw > out > there :) > > cheers, > Zane. > > __ > > 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] [tc] Organizational diversity tag
Every project on the one-way-trip to inactivity starts with what some people will wishfully call a 'transient period' of reduced activity. Once the transient nature is no longer the case (either it becomes active or the transient becomes permanent) the normal process of eviction can begin. As the guy who came up with the maintenance-mode tag, so as to apply it to Trove, I believe that both the diversity tag and the maintenance mode tag have a good reason to exist, and should both be retained independent of each other. The logic always was, and should remain, that diversity is a measure of wide multi-organizational support for a project; not measured in the total volume of commits but the fraction of commits. There was much discussion about the knobs in the diversity tag measurement when Flavio made the changes some years back. I'm sorry I didn't attend the session in Vancouver but I'll try and tune in to a TC office hours session and maybe get a rundown of what precipitated this decision to move away from the diversity tag. -amrith > -Original Message- > From: Jeremy Stanley > Sent: Tuesday, May 29, 2018 5:43 PM > To: OpenStack Development Mailing List (not for usage questions) > > Subject: Re: [openstack-dev] [tc] Organizational diversity tag > > On 2018-05-29 13:17:50 -0400 (-0400), Doug Hellmann wrote: > [...] > > We have the status:maintenance-mode tag[3] today. How would a new > > "low-activity" tag be differentiated from the existing one? > [...] > > status:maintenance-mode is (as it says on the tin) a subjective indicator that > a team has entered a transient period of reduced activity. By contrast, a low- > activity tag (maybe it should be something more innocuous like low-churn?) > would be an objective indicator that attempts to make contributor diversity > assertions are doomed to fail the statistical significance test. We could > consider overloading status:maintenance-mode for this purpose, but some > teams perhaps simply don't have large amounts of code change ever and > that's just a normal effect of how they operate. > -- > Jeremy Stanley __ 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] [tc] Organizational diversity tag
On 2018-06-02 13:23:24 -0400 (-0400), Doug Hellmann wrote: [...] > It feels like we would be saying that we don't trust 2 core reviewers > from the same company to put the project's goals or priorities over > their employer's. And that doesn't feel like an assumption I would > want us to encourage through a tag meant to show the health of the > project. [...] That's one way of putting it. On the other hand, if we ostensibly have that sort of guideline (say, two core reviewers shouldn't be the only ones to review a change submitted by someone else from their same organization if the team is large and diverse enough to support such a pattern) then it gives our reviewers a better argument to push back on their management _if_ they're being strongly urged to review/approve certain patches. At least then they can say, "this really isn't going to fly because we have to get a reviewer from another organization to agree it's in the best interests of the project" rather than "fire me if you want but I'm not approving that change, no matter how much your product launch is going to be delayed." While I'd like to think a lot of us have the ability to push back on those sorts of adverse influences directly, I have a feeling not everyone can comfortably do so. On the other hand, it might also just be easy enough to give one of your fellow reviewers in another org a heads up that maybe they should take a look at that patch over there and provide some quick feedback... -- Jeremy Stanley signature.asc 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] [tc] Organizational diversity tag
On 06/02/2018 12:23 PM, Doug Hellmann wrote: Excerpts from Zane Bitter's message of 2018-06-01 15:19:46 -0400: On 01/06/18 12:18, Doug Hellmann wrote: [snip] Is that rule a sign of a healthy team dynamic, that we would want to spread to the whole community? Yeah, this part I am pretty unsure about too. For some projects it probably is. For others it may just be an unnecessary obstacle, although I don't think it'd actually be *un*healthy for any project, assuming a big enough and diverse enough team (which should be a goal for the whole community). It feels like we would be saying that we don't trust 2 core reviewers from the same company to put the project's goals or priorities over their employer's. And that doesn't feel like an assumption I would want us to encourage through a tag meant to show the health of the project. I have to agree. In general, I have tried to at least give the opportunity for other cores from other companies to review patches before approving, but there have been times where I have approved patches in Cinder where the only other +2 was someone from the same company. I don't see anything wrong with this in most cases. As an exceptional example, I'm actually happy to see two +2's from Red Hat cores on Ceph related patches. I think it's a good thing to encourage a mix, but I have never considered it a hard and fast rule. Maybe I'm reading too much into it? Or it is more of a problem than I have experienced? Doug __ 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] [tc] Organizational diversity tag
Excerpts from Zane Bitter's message of 2018-06-01 15:19:46 -0400: > On 01/06/18 12:18, Doug Hellmann wrote: [snip] > > Is that rule a sign of a healthy team dynamic, that we would want > > to spread to the whole community? > > Yeah, this part I am pretty unsure about too. For some projects it > probably is. For others it may just be an unnecessary obstacle, although > I don't think it'd actually be *un*healthy for any project, assuming a > big enough and diverse enough team (which should be a goal for the whole > community). It feels like we would be saying that we don't trust 2 core reviewers from the same company to put the project's goals or priorities over their employer's. And that doesn't feel like an assumption I would want us to encourage through a tag meant to show the health of the project. Maybe I'm reading too much into it? Or it is more of a problem than I have experienced? Doug __ 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] [tc] Organizational diversity tag
I agree with Zane's proposal here, it is a good rule to have 2 core reviewer from different companies to provide +2 for a patch. However it should not be very strict given that project in early stage usually have to rely on devs from one or two companies. But it should be recommended that project apply for the diversity-tag should at least expressed that they have adopted this rule. On Sat, Jun 2, 2018 at 3:19 AM, Zane Bitter wrote: > On 01/06/18 12:18, Doug Hellmann wrote: > >> Excerpts from Zane Bitter's message of 2018-06-01 10:10:31 -0400: >> >>> Crazy idea: what if we dropped the idea of measuring the diversity and >>> allowed teams to decide when they applied the tag to themselves like we >>> do for other tags. (No wait! Come back!) >>> >>> Some teams enforce a requirement that the 2 core +2s come from reviewers >>> with different affiliations. We would say that any project that enforces >>> that rule would get the diversity tag. Then it's actually attached to >>> something concrete, and teams could decide for themselves when to drop >>> it (because they would start having difficulty merging stuff otherwise). >>> >>> I'm not entirely sold on this, but it's an idea I had that I wanted to >>> throw out there :) >>> >>> cheers, >>> Zane. >>> >>> >> The point of having the tags is to help consumers of the projects >> understand their health in some capacity. In this case we were >> trying to use measures of actual activity within the project to >> help spot projects that are really only maintained by one company, >> with the assumption that such projects are less healthy than others >> being maintained by contributors with more diverse backing. >> > > (Clarification for readers: there are actually 3 levels; getting the > diverse-affiliations tag has a higher bar than dropping the single-vendor > tag.) > > Does basing the tag definition on whether approvals need to come >> from people with diverse affiliation provide enough project health >> information that it would let us use it to replace the current tag? >> > > Yes. Project teams will soon drop this rule if it's the only way to get > patches in. A single-vendor project by definition cannot adopt this rule > and continue to... exist as a project, really. > > It would tell potential users that if one organisation drops out it there > is at least somebody left to review patches, and also guarantee that the > project's direction is not down to the whim of one organisation. > > How many teams enforce the rule you describe? >> > > I don't know. > > I do know that in Heat we never enforced it - at first because it was a > single-vendor project, and then later because it was so diverse (and not > subject to any particular cross-company animosity) that nobody particularly > saw the need to change, and now that many of those vendors have pulled out > of OpenStack because it would be an obstacle to getting patches approved > again. > > I was kind of under the impression that all of the projects used this rule > prior to Heat and Ceilometer being incubated. That may be incorrect. At > least Nova and the projects that have a lot of vendor drivers (and are thus > susceptible to suspicions of bias) - i.e. Cinder & Neutron mainly - may > still follow this rule? I haven't yet found a mention of it in any of the > contributor guides though, so possibly it was dropped OpenStack-wide and I > never noticed. > > Is that rule a sign of a healthy team dynamic, that we would want >> to spread to the whole community? >> > > Yeah, this part I am pretty unsure about too. For some projects it > probably is. For others it may just be an unnecessary obstacle, although I > don't think it'd actually be *un*healthy for any project, assuming a big > enough and diverse enough team (which should be a goal for the whole > community). > > For most projects with small core teams it would obviously be a > showstopper, but the idea would be for them to continue to opt out. > > cheers, > Zane. > > > __ > 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 > -- Zhipeng (Howard) Huang Standard Engineer IT Standard & Patent/IT Product Line Huawei Technologies Co,. Ltd Email: huangzhip...@huawei.com Office: Huawei Industrial Base, Longgang, Shenzhen (Previous) Research Assistant Mobile Ad-Hoc Network Lab, Calit2 University of California, Irvine Email: zhipe...@uci.edu Office: Calit2 Building Room 2402 OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado __ 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] [tc] Organizational diversity tag
On 01/06/18 12:18, Doug Hellmann wrote: Excerpts from Zane Bitter's message of 2018-06-01 10:10:31 -0400: Crazy idea: what if we dropped the idea of measuring the diversity and allowed teams to decide when they applied the tag to themselves like we do for other tags. (No wait! Come back!) Some teams enforce a requirement that the 2 core +2s come from reviewers with different affiliations. We would say that any project that enforces that rule would get the diversity tag. Then it's actually attached to something concrete, and teams could decide for themselves when to drop it (because they would start having difficulty merging stuff otherwise). I'm not entirely sold on this, but it's an idea I had that I wanted to throw out there :) cheers, Zane. The point of having the tags is to help consumers of the projects understand their health in some capacity. In this case we were trying to use measures of actual activity within the project to help spot projects that are really only maintained by one company, with the assumption that such projects are less healthy than others being maintained by contributors with more diverse backing. (Clarification for readers: there are actually 3 levels; getting the diverse-affiliations tag has a higher bar than dropping the single-vendor tag.) Does basing the tag definition on whether approvals need to come from people with diverse affiliation provide enough project health information that it would let us use it to replace the current tag? Yes. Project teams will soon drop this rule if it's the only way to get patches in. A single-vendor project by definition cannot adopt this rule and continue to... exist as a project, really. It would tell potential users that if one organisation drops out it there is at least somebody left to review patches, and also guarantee that the project's direction is not down to the whim of one organisation. How many teams enforce the rule you describe? I don't know. I do know that in Heat we never enforced it - at first because it was a single-vendor project, and then later because it was so diverse (and not subject to any particular cross-company animosity) that nobody particularly saw the need to change, and now that many of those vendors have pulled out of OpenStack because it would be an obstacle to getting patches approved again. I was kind of under the impression that all of the projects used this rule prior to Heat and Ceilometer being incubated. That may be incorrect. At least Nova and the projects that have a lot of vendor drivers (and are thus susceptible to suspicions of bias) - i.e. Cinder & Neutron mainly - may still follow this rule? I haven't yet found a mention of it in any of the contributor guides though, so possibly it was dropped OpenStack-wide and I never noticed. Is that rule a sign of a healthy team dynamic, that we would want to spread to the whole community? Yeah, this part I am pretty unsure about too. For some projects it probably is. For others it may just be an unnecessary obstacle, although I don't think it'd actually be *un*healthy for any project, assuming a big enough and diverse enough team (which should be a goal for the whole community). For most projects with small core teams it would obviously be a showstopper, but the idea would be for them to continue to opt out. cheers, Zane. __ 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] [tc] Organizational diversity tag
Excerpts from Zane Bitter's message of 2018-06-01 10:10:31 -0400: > On 26/05/18 17:46, Mohammed Naser wrote: > > Hi everyone! > > > > During the TC retrospective at the OpenStack summit last week, the > > topic of the organizational diversity tag is becoming irrelevant was > > brought up by Thierry (ttx)[1]. It seems that for projects that are > > not very active, they can easily lose this tag with a few changes by > > perhaps the infrastructure team for CI related fixes. > > > > As an action item, Thierry and I have paired up in order to look into > > a way to resolve this issue. There have been ideas to switch this to > > a report that is published at the end of the cycle rather than > > continuously. Julia (TheJulia) suggested that we change or track > > different types of diversity. > > > > Before we start diving into solutions, I wanted to bring this topic up > > to the mailing list and ask for any suggestions. In digging the > > codebase behind this[2], I've found that there are some knobs that we > > can also tweak if need-be, or perhaps we can adjust those numbers > > depending on the number of commits. > > Crazy idea: what if we dropped the idea of measuring the diversity and > allowed teams to decide when they applied the tag to themselves like we > do for other tags. (No wait! Come back!) > > Some teams enforce a requirement that the 2 core +2s come from reviewers > with different affiliations. We would say that any project that enforces > that rule would get the diversity tag. Then it's actually attached to > something concrete, and teams could decide for themselves when to drop > it (because they would start having difficulty merging stuff otherwise). > > I'm not entirely sold on this, but it's an idea I had that I wanted to > throw out there :) > > cheers, > Zane. > The point of having the tags is to help consumers of the projects understand their health in some capacity. In this case we were trying to use measures of actual activity within the project to help spot projects that are really only maintained by one company, with the assumption that such projects are less healthy than others being maintained by contributors with more diverse backing. Does basing the tag definition on whether approvals need to come from people with diverse affiliation provide enough project health information that it would let us use it to replace the current tag? How many teams enforce the rule you describe? Is that rule a sign of a healthy team dynamic, that we would want to spread to the whole community? Doug __ 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] [tc] Organizational diversity tag
On 26/05/18 17:46, Mohammed Naser wrote: Hi everyone! During the TC retrospective at the OpenStack summit last week, the topic of the organizational diversity tag is becoming irrelevant was brought up by Thierry (ttx)[1]. It seems that for projects that are not very active, they can easily lose this tag with a few changes by perhaps the infrastructure team for CI related fixes. As an action item, Thierry and I have paired up in order to look into a way to resolve this issue. There have been ideas to switch this to a report that is published at the end of the cycle rather than continuously. Julia (TheJulia) suggested that we change or track different types of diversity. Before we start diving into solutions, I wanted to bring this topic up to the mailing list and ask for any suggestions. In digging the codebase behind this[2], I've found that there are some knobs that we can also tweak if need-be, or perhaps we can adjust those numbers depending on the number of commits. Crazy idea: what if we dropped the idea of measuring the diversity and allowed teams to decide when they applied the tag to themselves like we do for other tags. (No wait! Come back!) Some teams enforce a requirement that the 2 core +2s come from reviewers with different affiliations. We would say that any project that enforces that rule would get the diversity tag. Then it's actually attached to something concrete, and teams could decide for themselves when to drop it (because they would start having difficulty merging stuff otherwise). I'm not entirely sold on this, but it's an idea I had that I wanted to throw out there :) cheers, Zane. __ 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] [tc] Organizational diversity tag
On Tue, 29 May 2018, Samuel Cassiba wrote: The moniker of 'low-activity' does give the very real, negative perception that things are just barely hanging on. It conveys the subconscious, officiated statement (!!!whether or not this was intended!!!) that nobody in their right mind should consider using the subproject, let alone develop on or against it, for fear that it wind up some poor end-user's support nightmare. Yeah. Which is really unfortunate because to some extent all projects ought to be striving to be low activity in the sense of mature, stable, (nearly) bug-free. If our metrics are biased towards always committing then we are encouraging unfettered growth which means we can never have any sense of complete-ness or done-ness in any domains. It should be okay to say a sub-domain of activity is done and move on to improving the wider domain. -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent__ 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] [tc] Organizational diversity tag
Samuel Cassiba wrote: [...] The moniker of 'low-activity' does give the very real, negative perception that things are just barely hanging on. It conveys the subconscious, officiated statement (!!!whether or not this was intended!!!) that nobody in their right mind should consider using the subproject, let alone develop on or against it, for fear that it wind up some poor end-user's support nightmare. [...] Yes, that's fair... and why my original suggestion was to do a (regular) qualitative report that would use words rather than binary tags. -- Thierry Carrez (ttx) __ 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] [tc] Organizational diversity tag
On 2018-05-29 13:17:50 -0400 (-0400), Doug Hellmann wrote: [...] > We have the status:maintenance-mode tag[3] today. How would a new > "low-activity" tag be differentiated from the existing one? [...] status:maintenance-mode is (as it says on the tin) a subjective indicator that a team has entered a transient period of reduced activity. By contrast, a low-activity tag (maybe it should be something more innocuous like low-churn?) would be an objective indicator that attempts to make contributor diversity assertions are doomed to fail the statistical significance test. We could consider overloading status:maintenance-mode for this purpose, but some teams perhaps simply don't have large amounts of code change ever and that's just a normal effect of how they operate. -- Jeremy Stanley signature.asc 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] [tc] Organizational diversity tag
On 2018-05-29 13:59:27 +0200 (+0200), Thierry Carrez wrote: [...] > Alternatively (if that's too much work), we could add a new team > tag (low-activity ?) that would appear for all projects where the > activity is so low that the team diversity tags no longer really > apply. As others have also said, this seems like a potentially useful metric on its own anyway. We could simply avoid including low-activity tagged teams in diversity reporting and not associate any diversity tags with them. -- Jeremy Stanley signature.asc 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] [tc] Organizational diversity tag
On Tue, May 29, 2018 at 5:51 AM, Mohammed Naser wrote: > On Tue, May 29, 2018 at 7:59 AM, Thierry Carrez > wrote: > > Mohammed Naser wrote: > >> > >> During the TC retrospective at the OpenStack summit last week, the > >> topic of the organizational diversity tag is becoming irrelevant was > >> brought up by Thierry (ttx)[1]. It seems that for projects that are > >> not very active, they can easily lose this tag with a few changes by > >> perhaps the infrastructure team for CI related fixes. > >> > >> As an action item, Thierry and I have paired up in order to look into > >> a way to resolve this issue. There have been ideas to switch this to > >> a report that is published at the end of the cycle rather than > >> continuously. Julia (TheJulia) suggested that we change or track > >> different types of diversity. > >> > >> Before we start diving into solutions, I wanted to bring this topic up > >> to the mailing list and ask for any suggestions. In digging the > >> codebase behind this[2], I've found that there are some knobs that we > >> can also tweak if need-be, or perhaps we can adjust those numbers > >> depending on the number of commits. > > > > > > Right, the issue is that under a given level of team activity, there is a > > lot of state flapping between single-vendor, no tag, and > > diverse-affiliation. Some isolated events (someone changing affiliation, > a > > dozen of infra-related changes) end up having a significant impact. > > > > My current thinking was that rather than apply a mathematical rule to > > produce quantitative results every month, we could take the time for a > > deeper analysis and produce a qualitative report every quarter. > > I like this idea, however... > > > Alternatively (if that's too much work), we could add a new team tag > > (low-activity ?) that would appear for all projects where the activity > is so > > low that the team diversity tags no longer really apply. > > I think as a first step, it would be better to look into adding a > low-activity team that so that anything under X number of commits > would fall under that tag. I personally lean towards this because > it'll be a useful indication for consumers of deliverables of these > projects, because I think low activity is just as important as > diversity/single-vendor driven projects. > > The only thing I have in mind is the possible 'feeling' for projects > which are very stable, quiet and functioning to end up with > low-activity tag, giving an impression that they are unmaintained. I > think in general most associate low activity = unmaintained.. but I > can't come up with any better options either. > This seems like my cue. It's unfortunate that I could not be in Vancouver last week to discuss this, and I don't want to give the wrong impression, but here goes. Putting my own interests up front: if openstack-chef, a relatively quiet subproject, with a reasonably stable codebase and measurable user base, were to be suddenly be labeled with 'low-activity', then openstack-chef, and I imagine others in a similar situation, surely would be considered as dead as some perceptions have suggested in the past. The wrong perceptions can make open source contributions increasingly more difficult to obtain and maintain over time, making 'low-activity' a self-fulfilling prophecy and not a particularly helpful metric. For the record, openstack-chef has no tags at all, even though we may have at some point qualified for organizational diversity on paper. The problem with any label close to the idea of things declining is that the perception would be more overt than it is if we were to put our collective heads in the sand, unable to come to an accord. Hearken to Glance (a core project!) being barely able to make a release due to rapid developer decline over a cycle. Consider the more recently talked about people-formerly-known-as-docs-team, or the lesser known projects with contributors from a couple of companies struggling to get and maintain exposure, and the ones that lag behind core by a release (hi!) just because it takes that long to get to the next one. Brand any or all of them 'low-activity' with the best of intentions of identifying the ones that need love, and that's more or less signaling their end of life, since 'nobody' wants to touch that janky, unmaintained abandonware with 'no activity'. The moniker of 'low-activity' does give the very real, negative perception that things are just barely hanging on. It conveys the subconscious, officiated statement (!!!whether or not this was intended!!!) that nobody in their right mind should consider using the subproject, let alone develop on or against it, for fear that it wind up some poor end-user's support nightmare. Having quietly served as PTL for four cycles -- sometimes not as quietly as others -- I've struggled with the notions of contributorship versus maintainership. After this long at it, experience says a bunch of well-intended contributors does not a
Re: [openstack-dev] [tc] Organizational diversity tag
Excerpts from Mohammed Naser's message of 2018-05-29 08:51:16 -0400: > On Tue, May 29, 2018 at 7:59 AM, Thierry Carrez wrote: > > Mohammed Naser wrote: > >> > >> During the TC retrospective at the OpenStack summit last week, the > >> topic of the organizational diversity tag is becoming irrelevant was > >> brought up by Thierry (ttx)[1]. It seems that for projects that are > >> not very active, they can easily lose this tag with a few changes by > >> perhaps the infrastructure team for CI related fixes. > >> > >> As an action item, Thierry and I have paired up in order to look into > >> a way to resolve this issue. There have been ideas to switch this to > >> a report that is published at the end of the cycle rather than > >> continuously. Julia (TheJulia) suggested that we change or track > >> different types of diversity. > >> > >> Before we start diving into solutions, I wanted to bring this topic up > >> to the mailing list and ask for any suggestions. In digging the > >> codebase behind this[2], I've found that there are some knobs that we > >> can also tweak if need-be, or perhaps we can adjust those numbers > >> depending on the number of commits. > > > > > > Right, the issue is that under a given level of team activity, there is a > > lot of state flapping between single-vendor, no tag, and > > diverse-affiliation. Some isolated events (someone changing affiliation, a > > dozen of infra-related changes) end up having a significant impact. > > > > My current thinking was that rather than apply a mathematical rule to > > produce quantitative results every month, we could take the time for a > > deeper analysis and produce a qualitative report every quarter. > > I like this idea, however... > > > Alternatively (if that's too much work), we could add a new team tag > > (low-activity ?) that would appear for all projects where the activity is so > > low that the team diversity tags no longer really apply. > > I think as a first step, it would be better to look into adding a > low-activity team that so that anything under X number of commits > would fall under that tag. I personally lean towards this because > it'll be a useful indication for consumers of deliverables of these > projects, because I think low activity is just as important as > diversity/single-vendor driven projects. > > The only thing I have in mind is the possible 'feeling' for projects > which are very stable, quiet and functioning to end up with > low-activity tag, giving an impression that they are unmaintained. I > think in general most associate low activity = unmaintained.. but I > can't come up with any better options either. We have the status:maintenance-mode tag[3] today. How would a new "low-activity" tag be differentiated from the existing one? [3] https://governance.openstack.org/tc/reference/tags/status_maintenance-mode.html > > > -- > > Thierry Carrez (ttx) > > > > __ > > 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] [tc] Organizational diversity tag
On Tue, May 29, 2018 at 7:59 AM, Thierry Carrez wrote: > Mohammed Naser wrote: >> >> During the TC retrospective at the OpenStack summit last week, the >> topic of the organizational diversity tag is becoming irrelevant was >> brought up by Thierry (ttx)[1]. It seems that for projects that are >> not very active, they can easily lose this tag with a few changes by >> perhaps the infrastructure team for CI related fixes. >> >> As an action item, Thierry and I have paired up in order to look into >> a way to resolve this issue. There have been ideas to switch this to >> a report that is published at the end of the cycle rather than >> continuously. Julia (TheJulia) suggested that we change or track >> different types of diversity. >> >> Before we start diving into solutions, I wanted to bring this topic up >> to the mailing list and ask for any suggestions. In digging the >> codebase behind this[2], I've found that there are some knobs that we >> can also tweak if need-be, or perhaps we can adjust those numbers >> depending on the number of commits. > > > Right, the issue is that under a given level of team activity, there is a > lot of state flapping between single-vendor, no tag, and > diverse-affiliation. Some isolated events (someone changing affiliation, a > dozen of infra-related changes) end up having a significant impact. > > My current thinking was that rather than apply a mathematical rule to > produce quantitative results every month, we could take the time for a > deeper analysis and produce a qualitative report every quarter. I like this idea, however... > Alternatively (if that's too much work), we could add a new team tag > (low-activity ?) that would appear for all projects where the activity is so > low that the team diversity tags no longer really apply. I think as a first step, it would be better to look into adding a low-activity team that so that anything under X number of commits would fall under that tag. I personally lean towards this because it'll be a useful indication for consumers of deliverables of these projects, because I think low activity is just as important as diversity/single-vendor driven projects. The only thing I have in mind is the possible 'feeling' for projects which are very stable, quiet and functioning to end up with low-activity tag, giving an impression that they are unmaintained. I think in general most associate low activity = unmaintained.. but I can't come up with any better options either. > -- > Thierry Carrez (ttx) > > __ > 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] [tc] Organizational diversity tag
Mohammed Naser wrote: During the TC retrospective at the OpenStack summit last week, the topic of the organizational diversity tag is becoming irrelevant was brought up by Thierry (ttx)[1]. It seems that for projects that are not very active, they can easily lose this tag with a few changes by perhaps the infrastructure team for CI related fixes. As an action item, Thierry and I have paired up in order to look into a way to resolve this issue. There have been ideas to switch this to a report that is published at the end of the cycle rather than continuously. Julia (TheJulia) suggested that we change or track different types of diversity. Before we start diving into solutions, I wanted to bring this topic up to the mailing list and ask for any suggestions. In digging the codebase behind this[2], I've found that there are some knobs that we can also tweak if need-be, or perhaps we can adjust those numbers depending on the number of commits. Right, the issue is that under a given level of team activity, there is a lot of state flapping between single-vendor, no tag, and diverse-affiliation. Some isolated events (someone changing affiliation, a dozen of infra-related changes) end up having a significant impact. My current thinking was that rather than apply a mathematical rule to produce quantitative results every month, we could take the time for a deeper analysis and produce a qualitative report every quarter. Alternatively (if that's too much work), we could add a new team tag (low-activity ?) that would appear for all projects where the activity is so low that the team diversity tags no longer really apply. -- Thierry Carrez (ttx) __ 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
