Collection inclusion: vote on collections submitted for inclusion before starting the review process

Project Discussions
,
7

The discussion on what to include (and what not to include) is probably almost as old as the ansible package itself (even before the collection split) and I’m very sure this won’t be the last time we discuss this :wink:

Every time this comes up I go through some extreme ideas (like abolishing the package completely, or removing everything that’s too vendor-specific) and quickly throw each of them away again, since they all kind of suck. (Abolishing the package is a valid discussion, I don’t want to say that the idea itself sucks, just that starting that discussion in this context is not a good idea. Having that as a separate discussion is totally fine, in case someone wants to reboot that discussion.)

I’d like to have some criteria which allow to weight size of the included content vs. usefulness to the community at large, which I think would be a good metric (assuming the general quality of a collection is good enough, for which we already have criteria). But I don’t think it’s possible to come up with a objective way to judge this. Just measuring “usefulness to the community at large” is something that I think is impossible to judge - @flowerysong’s argument above is a very good indication for that. Looking at “objective” stats such as upvotes on the GH inclusion request or Galaxy download counts is a proxy that’s IMO not very close to the truth (and can easily be faked). Just restricting upvotes to a “trusted” set of community members (I’m not going to say how to find such a set, in fact I have no clue how to do that, but let’s assume we have it for some reason) isn’t that much more helpful either, since then we are building a package specific to the needs of this explicit set, and we might miss large parts of the community which happend to be not represented by this set. So I’m pretty sure it’s not possible to come up with truly objective and useful metrics.

So yeah, what we are left to do is probably things like (most of them already mentioned above):

  • make it easier to create your own collection docsite (BTW, antsibull-docs now has some docs: antsibull-docs – Ansible Documentation Build Scripts);
  • maybe even make it possible to have your collection being documented on docs.ansible.com without being part of the Ansible package (that comes with its own can of worms);
  • improve documentation rendering on galaxy.ansible.com (so most of the information is already there and you don’t need another place for the docs in many cases? there are a lot of things left now, like extra docs, role argument specs, or docs fragments from other collections which break rendering completely);
  • make it easier to not use the ansible package, but simply use the collections you need (EEs? your own specialized ansible package build? …?);
  • … more ideas?
4 Likes