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
> -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
> -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
