We are already responsible for awesome ansible. We brought it into our github org for that purpose. The fact that we aren’t is a fail on our side, not an indication of a list we aren’t responsible already for maintaining.
I should’ve given the context. There are many projects under RH orgs now. They are in a different state in terms of quality including cross-project contributor experience. We are thinking of making the differences and improve overall state of things there by making the contributor environments there familiar, predictable and smooth, typically needed information full and easy to find. One of solutions is to make their READMEs contain a minimal set of sections and their docsites have similar structure with also a minimal required set of sections. Those projects should try to be best. Extreme case: It would be IMO not good to have a project on the ecosystem page with even no user docs and having only TODO written on every page on their docsite (we unfortunately have such projects).
That’s why i think it’s worth having some extra requirements (in addition to the requirements for all the project) for RH projects. It’s another topic though, just the context. I think at some point, a dedicated topic will be created here.
Then next time we should think twice before doing that 
It’s another topic but I would suggest declaring that repo a community one, i.e. maintained by the community making the community team responsible for granting access to community maintainers / merging updates submitted by the community there, not for keeping the list relevant.
Anyway, I would suggest not referring to any other lists from the ecosystem page(s) instead saying that the list of project is not exhaustive and there can be other ansible-related projects on the internet. Also there can be an invite to the inclusion submission (once it’s developed).
1 Like
You touched on my question from yesterday’s DaWGs meeting, which was basically how does one submit a project for consideration. I asked because I have a tiny project that seems to fit the description and requirements we’ve been talking about here. But…
That’s when I learned about the existence of the ansible awesome page/project. (And reading that is when I learned about - or was reminded of - the Ansible subreddit. But I digress.)
That is a truly awesome, and virtually unmaintained, list. It doesn’t contain any mention of https://forum.ansible.com/ for example. Yet it seems more approachable to a single third-party person with a tiny project to share than does the ecosystem page.
And here I’m stymied by the same dilemma: there is such a proliferation of X (where X is “lists of Ansible projects”, or “community communication channels”, or “sets of similar-but-not-quite-the-same docs”, etc.) that there’s no way to decide where to start. Just when you think you’re through pealing the onion somebody dumps another bag of onions in front of you. I want to cry, and I don’t think it’s the onions. Too many choices!*
“We are confronted with insurmountable opportunities.” — Walt Kelly
2 Likes
It’s starting to feel like the awesome ansible list, and this project ecosystem page, are maybe trying to do (nearly) the same thing.
Maybe combine the efforts? Either make awesome ansible the ecosystem page (and subsequently maintain it!), or convert/replace awesome ansible with the ecosystem page, merging its current information and and such?
1 Like
Hey @utoddl thanks for sharing your experience! Not sure if this is any consolation but that dilemma is quite common. Myself and the community team have been trying to bring down the level of fragmentation for the past year and that, in itself, has been a journey of many twists and turns.
Yet it seems more approachable to a single third-party person with a tiny project to share than does the ecosystem page.
Good point. I suppose my perspective on things has been different so it’s very helpful to hear this, even if it seems a lot more obvious to folks who are long-time contributors or regular community users.
At the heart of all this discussion is the goal the community team has - and has carried over from last year - to help everyone stop peeling onions to get to where they want to go. We want everyone to succeed with their automation!
“Let your soul stand cool and composed before a million universes.” - Walt Whitman (my favourite Walt)
Maybe combine the efforts? Either make awesome ansible the ecosystem page (and subsequently maintain it!), or convert/replace awesome ansible with the ecosystem page, merging its current information and and such?
Yeah it seems to be heading that way. Maybe it has just been like that all along and we need to sort out maintenance. I’ve had a couple of thoughts in that direction myself but I’d kind of like to hear from others to avoid rushing.
One question I’ve had about the awesome ansible list, should that always just be a README in GitHub or would we be breaking some kind of awesome X list convention by making it more like the docsite?
i would let the awesome ansible be to give the community a chance to have their projects listed somewhere even if they don’t satisfy the requirements (like OSS licence, available issue tracker, etc.). I see people submitted PRs there
1 Like
Thanks to everyone who provided their input on this topic so far. Maybe it seems like it has gone a little cold here in the forum but we, the community team at Red Hat, have been discussing criteria for ecosystem inclusion in the background. As a lot of the discussion here indicates, it is a tricky one to get right for all and also highlights, once again, the need for a more robust community governance strategy. However that is well beyond the scope of the topic at hand.
So where are we? It seems that if we want to start including community projects in the ecosystem, not only do we need a set of criteria, we also need an inclusion process in some form. From the collection inclusion process in the Ansible package we’ve seen that participation can put burden on already dedicated, amazing contributors. We kind of feel like adding to that burden risks overloading folks who are already doing superhero-level workloads.
It’s questionable if the outcome is worth the effort. In the end we’d basically have the same thing that we have right now. Sure, we could combine the list of RH-managed projects with some of the projects in the Awesome Ansible list. But it’s unlikely the Awesome Ansible list would go away completely because there would still be projects that don’t meet the “table stakes” criteria.
Another factor that is influencing outcome here is that the new “ansible.com” website has its own ecosystem page. Putting the ecosystem page on the docs subdomain was always intended to be a temporary thing. The community team created that page on the docs subdomain because it was the best place for it to go, within the bounds of what we could control. And, while we did write the code for the new ecosystem page on ansible.com, the community team doesn’t have ownership of the actual content.
The point here is that it doesn’t make sense to have two ecosystem pages and an Awesome Ansible list. That’s fragmentation that doesn’t help anyone. And you’re welcome to open PRs against the new website and request projects be included in the ecosystem page, but that’s not something the community team can approve or merge.
We, the community team, feel like the best thing is to update the ecosystem page on the docsite so that it points to ansible.com/ecosystem and the Awesome Ansible list. That seems like it sort of solves the problem for the most part. From the docsite ecosystem, users will be able to find both Red Hat-managed projects as well as everything the Ansible community has to offer.
At some point in future we’ll probably have that broader governance issue figured out (which should also encompass “ansible.com”) and we can revisit the “table stakes” conversation. For now, it seems like a simpler approach is the right one. It might not be the ideal outcome but hopefully it’s a step in the right direction.
EDIT: Somehow the first part of this message got truncated. 
1 Like