I think this would be great.
I’m a basic user who has created some simple apps.
Sometimes I need things like rbac but don’t know enough to properly sort it within code. When I look for extensions there are some that have stalled in development and have been taken over or forked ,or other ones that don’t quite do what I need.
Having one good extension that you could rely on being updated would be great. In a way, a bit like Laravel passport in that’s it’s developed closely with the core.
When I say developed closely with the core: I don’t know if passport is part of the core or not. I’ve just seen it in the documentation.
That seems like a good thing when the main docs can point to an extension which will sort a certain issue.
Great proposal
‘yiipeople’ is not yet the finalized name, i suggest to keep some generic name like ‘fosspeople’ or something that doen not have PHP, Yii or similar keyword to encourage anyone to contribute to this org.
Names like thephpleague, react-native-community sometime gives feeling to guest contributor that this org has enought number of contributors so my contributions are not needed or already implemented.
Generic names invites contributors who don’t use PHP as primay lang but have knowledge of PHP
these are my opinions
Worth note that extensions ecosystem for Yii 3 will be quite different than for Yii 2 or Yii 1. Yii 3 is no longer a framework in the old meaning of this word (big group of components coupled with each other), it is ecosystem of separate libraries which could be used separately in framework-agnostic applications. Many extensions for Yii 1 and Yii 2 will be completely obsolete in context of Yii 3 or becomes generic PHP packages with some Yii dependencies.
Just to clarify: this proposed initiative is not intended to fix everything for everyone, it’s to improve quality, continuity and efficiency for Yii’s extensions. I’m afraid that it will end up becoming stuck in discussion about scope and standards forever if we make too generic. Of course everyone is welcome and encouraged to contribute, and that can be accomplished in other ways than not referencing to Yii. In fact, I hope it aligns closely to Yii when it comes to standards, practices and governance as I quite like it. The core framework has high quality, applies best practices wherever it can and embraced transparent and democratic decision making - what’s not to love?
Good point, and I’d love to get the opinion of a Yii 3 core developer like @samdark on this. From where I stand it still looks like we’ve got extensions in a Yii 3 world, which means we have core framework (yiisoft) and non-core feature (yiipeople) packages. I like that following Symfony’s footsteps Yii is now building modules for Yii 3 that are also usable without Yii’s framework. The same could apply for the packages produced/maintained by this community initiative, if that’s something this community finds important.
By the way, there are also many best-in-class generic PHP libraries by communities like thephpleague which just require an elegant Yii 1.1, 2 and 3 wrapper to hook it in to the framework in a convenient and easy to understand way. These could also be embraced whenever possible in stead of reinventing the wheel as a matter of principle, so the community maintained extension for this would be that wrapper and contain a composer dependency on the upstream library.
I love the proposal and I agree completely. My small suggestion, instead of saying yiipeople why can’t we use yiiextensions as organization?
There is no reason why we can’t. yiipeople was a working title and it kind of stuck, but not necessarily the final name. I would argue against yiiextensions though, as it doesn’t contain and relay a vital message: the community effort. From a communications perspective, a name containing people, community, collective, or something similar would probably be preferential. First impressions matter, don’t you agree?
Besides, yiiextensions might give the impression that Yii extensions are only allowed to reside there, and while it’s preferential to collaboratively work on extensions I don’t believe its anyone’s intention to forbid creating and maintaining your own and publish them under your own name.
I agree to your point of view. But I feel yiiextensions as more professional.
Actually I hope we get rid of these wrappers and Yii 3 design allow to use generic PHP libraries directly in convenient way. This was a pain in Yii 1 and Yii 2, since you need a wrapper for everything and usually it was easier to write it yourself than find a nice one and learn ho to use it - this is why you get 20 extensions doing the same thing.
I would avoid “Yii extension” term in the first place. If we think about it more like “php library with some dependencies” you usually get cleaner design and ability to promote Yii in non-Yii projects (you “can’t” use Yii extension in non-Yii project, but usually there is no such mental blockade in case of using generic package with some dependencies).
That’s one of the goals.
There still will be some Yii-specific packages such as, for example, drivers for Cache or RBAC that won’t be able to work w/o corresponding libraries.
But yes, overall, the idea is “let’s cooperatively develop/maintain some high quality packages we use”.
This one slipped off my face but great Idea. Am not sure how much far it have gone.
I was upset to find a lot of Yii2 User extensions each with its own maintainer. It was a good waste of scarce resources
The general idea to have cool Yii extensions is really great!
But is it really required to have a dedicated organization for it?
Why can’t we simply keep an actual and thoroughly selected yiisoft/awesome list with all the proposed requirements?
What are advantages/disadvantages?
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.