Neil Jerram wrote:
The issue is that the current method (which uses a formula to apply single-vendor and diverse-affiliation tags) is not working so well anymore, with lots of low-activity projects quickly flapping between states.I think you need to explore and state much more explicitly why this is a problem, before you will be able to evaluate possible changes.
Right, this was just a summary, we discussed it in more details in the thread and during that Forum session.
For example, a single-vendor project would suddenly lose the tag due to a combination of low activity and infra people pushing boilerplate change to their test jobs. Yet the project is still very much single-vendor (and not seeing much activity).
The way we ended up working around that in past cycles is by doing a human pass on the calculated results and assess whether the change is more of a data artifact due to low activity, or a real trends. If it was deemed an artifact, we'd not commit that change. But lately most of the changes had to be filtered by a human, which basically makes the calculation useless.
One important thing to remember is that the diversity tags are supposed to inform deployers, so that they can make informed choices on which component they are comfortable to deploy. So whatever we come up with, it needs to be useful information for deployers, not just a badge of honor for developers, or a statement of team internal policy.It sounds like this might be part of that 'why'. How sure are you about it?
How sure am I about... what? That tags are meant to be useful to deployers and the rest of our downstream consumers ? That is part of the original definition[1] of a tag. The template to define tags even includes a "rationale" section that is meant to justify how the ecosystem benefits from having this tag defined.
[1] https://governance.openstack.org/tc/resolutions/20141202-project-structure-reform-spec.html#provide-a-precise-taxonomy-to-help-navigating-the-ecosystem
-- 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
