I agree with this. At the beginning we should focus on creating some knowledge base - a list of high quality libraries (not only Yii related) which solves some common problems and works fine with Yii stack. It should be much more useful and easier to maintain than grouping bunch of extensions under single org.
Grouping some extensions under community organization could be next step, when old popular extensions becomes abandoned and needs new maintainer.
I think it is a great idea that should mature more, for the moment if we want to reach the extension we should help more to develop the framework, because without it, we have nothing.
I think a typical awesome list would contain multiple implementations for ie. user management, I’d strictly avoid that for maintained extensions; just have one per type.
Yeah, I’d also link to see that.
The advantage of grouping the work under the same organization, is that repositories won’t go unmaintained if the original author isn’t available anymore.
Anyone from the org’s team could take care of merging & releasing fixes, avoiding countless & scattered forks.
btw: we have https://www.yiiframework.com/extensions with a tagging and rating system … but somehow I do not really use it anymore, actually that should work much better than an awesome list.
As long as everyone can submit his extension to this list, this is not even close to awesome list. Not mention than it is only about Yii extensions, while for Yii 3 we could also promote non-Yii packages (in many cases you should be able to use it directly without need for wrapper extension).
It’s a great proposal and I hope it will work. I have questions about community decision making.
First, I see a conflict between these two ideas
and
If three projects transfer to yiipeople a lib that implements foo then yiipeople has to reject two of them to achieve it’s primary intent. Not everyone can keep their projects there.
Hence this official Yii community initiative is an entity that decides what’s in and what’s not.
Second, the entity will in effect endorse its chosen projects with respect to quality, performance, reliability, trustworthiness, and the other dimensions of goodness that have been mentioned. To do so it needs its to establish its criteria and methods to decide what meets the criteria.
A project being in yiipeople has (at least by implication if not explicitly) its approval as meeting the criteria and being best in class.
How would the community organize to make these decisions?
No rule without exception 
But still the goal should be one per type.
It’s explicitly non-official.
What are good examples from the community?
Loving the feedback guys and girls. Let’s keep up the good work!
Here’s my two cents on some of the responses:
Just creating a list of the best extensions mostly just addresses the issue of visibility of extensions. Like @schmunk said, the extensions registry on the website could address this much better than any flat list could ever do. It does not necessarily address the issue of quality standards, preventing duplicate effort and, like @machour said, preventing unmaintained extensions.
You are right. There is friction between these two goals when it comes to the existing Yii 1.1 and 2.0 extensions. I’m sure this can be resolved when we run into it. But this is important to address in the next steps. Perhaps this is also a great opportunity to combine the collective idea and the AwesomeList idea?
Just a thought - of course open to suggestions - but YiiPeople’s first steps could be something like this:
yiipeople/awesomelist
We could also let YiiPeople adopt the other, non-preferred, duplicate extensions in a bugfix-only type maintenance mode if it is at risk of being unmaintained? Update the readme to explicitly notify users that development on it has seized and recommend migration to YiiPeople’s preferred extension?
Either way, let’s not forget that right now is also the moment to prevent creating this same issue for Yii 3.
I believe the Yii 3 decision making right here is a great example. Hence I would advocate a separate YiiPeople category on this forum with a “Policy discussions” subcategory where these kinds of decisions can be discussed openly.
It’s a good goal, obviously. All the stated objectives seem good to me.
That was a quote from
I honestly don’t know. Although I have a suggestion that could help how we think about it.
Let’s not put the cart before the horse. I mean, avoid bureaucracy (rule making, process, formal goals, guides, etc.) until it is clearly needed at which point the people actually doing the work decide what they need. This should come fairly easily in the Yii community because the Yii Framework project has a history of adding bureaucracy ad hoc like this.
The people who will actually do the work (on code/docs and organizing efforts etc.) are for the time being unknown. But once the project is rolling, they will know best what work lies ahead and how to organize it with the community resources available. It won’t help to constrain their policy space up front.
Now, this may seem at odds with my question about decision making. Not really. The question was intended to highlight that if you assign a lot of authority the project team in advance then you’ll need to address its decision making in advance too.
Maybe we need to sort that out 
To me official means: maintained by the core team.
Ah well that’s not what was intended with the use of the word official.
What I mean is that any framework benefits from having one - and only one - collective, community initiative. Some preferential treatment by giving it a dedicated category on this forum, a unique badge/tag/category on the extensions catalog page, et cetera would make it kind of official. But indeed, not maintained by the core team. They have plenty on their plate as it is, so this would by all accounts be up to the community!
I’m fine setting up dedicated forum caregory. Let me know about the structure you need.
I very glad to see this proposal.
I’ve been out for some days, and i am proud to see so much movement in all areas of YII, WOW.
for some who said it was confined to disappear, or dead…
i totally agree on @toMeloos overall idea of a comunity of certified developers who make some certified code, still i think it would be better as @hiqsol proposed, but one for yii3 specific packages a other more generic for the non directly yii, and the name shoud represent a contributer developper comunity who build yii extentions in a ‘certified environment’ following yii standards and sure that the code will be curated reviewed or else yii certified:
I suggest for the name (yiipeople seams to me, inspite to be a fine name, not very representative of the purpose, maybe to vague):
coDev - (co-developpers)
devCo - (dev comunity)
yesDev - (yii - developers)
yesCode - (yii - co- developers)
yesco - ( yii co members - developers)
extdev - (yii extension developers)
certdev - (Certified Developement)
yiiWorld - (Yii developers Comunity, world of developers members) *
I really like this last one,
We need also to establish how to be a contributing member, and what rules and standards to be followed.
I also think it would be a must to be part of yiisoft, and not totally apart.
Yiisoft/yiiworld/extension
Or it would be yiiworld as a vendor
Not very sure on that one…
I can do a logo for the one who will be choosed and i may contribute on graphic/web design if needed, just tell me. Would be happy to contribute.
Cheers to all
A logo would be cool
OK, let’s do a logo, the name have been chosen yet?
Working title is YiiPeople but it may be changed so a logo without text is preferred.