Exactly this.
I’m also glad you mentioned that one of the inclusion requests called out specifically that the collection was for a Chinese company, because I felt uncomfortable about the way that was presented, as though it should matter what country’s users a collection may serve.
As you pointed out, while perhaps none of us have had occasion to work with that company, it doesn’t mean it’s unworthy of being in the package. This is precisely the type of bias I am worried about.
@Andersson007 thank you very much for those explanations and hypotheticals, those are very helpful to understanding the root of the discussion!
some people might just not like the way things implemented on another level. And you can’t reject it because say “there’s a lot of boilerplate code” because it’s not a requirement not to have it written that way. It’s also subjective.
This may simply be an irreconcilable difference of opinion between us, but for me someone “just not liking it” without being able to give a concrete criteria that can be applied evenly is not a good reason to reject.
- If i wrote several services that only i use locally or 10-100 people in my company/customers, is it fine if i submit collections for them whatever reason, say if just because i don’t want to create and maintain my own website for my collections docs - I want to delegate it to ansible doc folks
I.e. the audience or motivation behind requesting the inclusion don’t fit the package scale.
@flowerysong already said what I would have (in better words), but I do want to briefly call out the docs thing, since we literally have had inclusion requests that were motivated more by documentation than their code being included (at least on the surface it seemed that way).
I still don’t think that motivation is a reason to reject it; presumably they think enough people are going to use it that they think there’s a point to having the documentation available.
But I think if we’re seeing this, then as a community we could put more effort into making it easy to publish your own docsite since that’s something people seem to want. Totally different discussion though 
Finally, I want to propose a slight change to your proposal. As @flowerysong pointed out:
The committee is currently allowed to exclude things if “presence of the collection will significantly deteriorate the Ansible package user experience or the package build process”
This could be expanded to allow the committee to veto inclusion for any reason as long as it’s put to a vote. I’m not thrilled about the idea, but I would suggest these differences from your current proposal:
- The default action is to accept if inclusion criteria are met.
- Having a vote to include is an exception that must be initiated by quorum of N members (could be as few as 1, that’s a detail).
- The vote may be initiated at any time during the inclusion process, in order to accommodate a wide range of concerns, but depending on the nature of the concerns, voting may be extended until after other inclusion criteria are evaluated.
- The member(s) who called the vote can explain their case and what they don’t like about the collection, and we can discuss and decide.
- The vote is a vote to include not exclude. I think it’s important to word it this way because inclusion is the default.
- During discussion, we may want to figure out if we think the issues raised are reconcilable by the maintainer (code style?), or if they are something we think could never be reconciled (???)
I am worried that if we have to vote to include on every collection, before the criteria process, we will tend toward not including. I have no evidence for that, it’s just a feeling, and I think that’s a negative outcome (my opinion).
tl;dr: if we make any change, I think it’s as a sort of escape hatch, and it’s an exception, but I think I’d prefer not doing this and sticking to criteria that are as objective and measurable as possible.
