Community extension collective

Yii 3.0 Design discussions
1

Problem

Yii’s current way of handling extension has several downsides:

  1. Yii’s extension ecosystem for Yii v1 and v2 is not very impressive. Yes there are many extensions. But many of those are unmaintained, poorly documented, poorly coded, hardly supported or have other issues. Most developers also end up searching and comparing the Yii site, Packagist and GitHub to find the best one.

  2. The Yii community is small yet there are many duplicate extensions aimed at providing the same feature. While we all appreciate freedom of choice, most developers would probably prefer one excellent extension over the choice between five average ones. The community would probably be better served by focusing on fewer extensions that cover more features.

  3. The release of Yii v3 will create the challenge of having to build a new collection of v3-compatible extensions. Given the scattered nature of extensions, this will be a substantial undertaking and many will likely not be ported from v2 to v3 by their original authors. On the other hand, given Yii 3’s focus on a minimal footprint for the core framework, a substantial extension collection will be conditional to the successful adoption of Yii v3.

Existing Solutions

The described problem is not limited to Yii or PHP, but almost every single framework. And there are some solutions starting to emerge.

Initiatives like Puppet’s VoxPopuli and React Native Community are showing the way and could be a great source of inspiration.

Here is VoxPopuli’s mission statement:

We are a collective of Puppet module, tooling and documentation authors all working together to ensure continued development on the code we maintain.

We work under a shared name and namespace and synchronize our efforts. Having no official relation to Puppet Inc. allows us to maintain our own pace and direction when it comes to how we work and develop. However, all community members are welcome and this includes many Puppet Labs employees.

One of the benefits we hope to achieve is that by a shared ownership of modules we no longer end up in situations where the original maintainer has moved on and a forest of disparate forks try to fill the void. Since a huge team of contributors has access to our code anyone can step in and help move a module forward, merge code into it and release a new version of it.

React Native Community takes another approach. Whenever a popular extension goes unmaintained, or when the author is overwhelmed with issues/prs, they offer the author to transfer the repository to the react-native-community org on github. There, the extension immediately benefit from a fresh set of eyes, and the author gets help. Usually these are extensions mature enough to have a clear set of features/foreseeable changes, so the original author intention is respected.

If a newly adopted extension duplicates a feature implemented in another one, the community discuss this, and the feature gets removed from one of them. This avoids duplication and concentrate all efforts in one place.

What about Yii3?

Yii could benefit from a similar, official “Yii community extensions” initiative.

Let’s try to get the best and most active Yii extension builders together and create a community effort to build and maintain an extensive collection of long-term supported, best-practice coded, well-documented, well-tested, multi-lingual, feature-rich Yii 3 extensions.

With the intent to create:

  1. Optimal community efficiency by not reinventing the wheel several times building multiple extensions for the same feature/functionality.
  2. Yii being the PHP framework known for its best-in-class extensions with regards to performance, reliability, standardization, code quality, translation, documentation, etc.
  3. More trustworthy, reliable and easy to find extensions through centralization.
  4. More extension continuity; e.g. long-term supported, actively maintained and actively developed without regular forking, renaming, moved ownership, etc.

How this could work with the Yii community:

  1. Create a new Github and Packagist organization separate of yiisoft. Let’s call it yiipeople for now.
  2. Everybody can contribute. Owners of existing extensions are free and encouraged to transfer their repository to yiipeople and continue the development of their extensions there. The current core team is also encouraged to transfer everything they are maintaining that they do not consider core modules, and to contribute to yiipeople just like every other contributor.
  3. Just like with the framework itself, yiipeople should have its own “core team” that reviews commits and PR’s. Close ties to the core framework’s “core team” is encouraged for effort synchronization, but this can and should be a seperate team of senior yii extension developers.
  4. People contribute to and collaborate on extensions in yiipeople under a shared name, namespace and ownership. Each extension can have a single “lead” maintainer and credits to original authors and contributors should be awarded, but ultimately shared ownership applies to prevent unattended issues/PR’s and unmaintained extensions.
  5. Decision making on plans and direction should match the framework’s method: consult the community, but the core team has the final decision. Perhaps a section can be created here on Discourse for the community extension initiative to interact with the community.
  6. yiipeople will focus on creating and long-term maintaining one best-in-class extension per feature/technology/functionality for the most common non-core features per Yii version. High quality extensions with good code, well tested, properly documented, adherence to PHP and Yii’s standards and conventions, with translations, that don’t conflict with each other. It aspires to be every developer’s first place to look and preferred source.

In this setup, the heroes of the yiipeople core team will have several key roles:

  • Draft and maintain common versioning, code quality and structure, documentation, testing and contribution guidelines for yiipeople extensions.
  • Align extension efforts and development with the Yii framework core team.
  • Assess onboarded extensions that are contributed by community members, recommend opportunities for improvements and possibly contribute code themselves.
  • Approach developers of popular extensions to move their extension to yiipeople and become contributors (and perhaps even join the core team).
  • Monitor the health of extensions, jump in when extensions are stalled and/or unmaintained.
  • Handle issues and pull requests, or assist extension lead(s) on minor issues/PR’s if applicable.
  • Make sure the community is consulted and there is consensus among core members and/or extension lead(s) on potential major changes.

I believe this would increase Yii’s development strength and velocity, would be beneficial to users, and would make Yii more attractive to new developers. It’s nice to have a primary source of reliable extensions.

Getting this up and running would be a lot easier and faster with some initial support from the core team. Perhaps financial support through the OpenCollective campaign is even an option. I hope existing extension creators are open to the idea of forming a collective and working together on this, for the sake of the community at large.

28 Likes
2

This proposal is the best I’ve heard ToMeloos grace to share this vision, I think it’s great even doing it as an initiative of the community, for my part + 1000% we can start with the extensions that were abandoned that there are many of them and convert them to Yii 3.0, under a scheme and approach to make it as useful as possible, and thus maintain it over time.

1 Like
3

The proposal is great!

What I’d like to see is a place where we select and discuss extensions which could be maintained by yiipeople - a long time ago I started a similar thing for porting Yii 1.x extensions to Yii 2.x, see https://github.com/schmunk42/yii2-extension-requests/issues

I think it’s also worth to link some other projects for reference, which have or had a similar goal:

I’d also like to see a common ground for coding standards, this would include tools like:

I consider this an important part, because it greatly helps onboarding when code is written in the same style, i.e. this was one of the main design goals of Go. For this we should have a generic test or lint task which can be applied to any project.

In arrangement with @toMeloos I created an organization on GitHub: https://github.com/yiipeople

2 Likes
4

I love the proposal. It is a great idea. In fact, I was running similar thing for Yii 1.0 and 1.1: https://github.com/yiiext but then joined core team and had to stop maintaining it.

2 Likes
5

I suggest to start with yiipeople/standards to write down requirements for an extension such as:

  1. Should follow PSR-2.
  2. Should have good enough (ideally 100%) test coverage.
  3. Should be focused not doing too many things at once.
  4. Should use SemVer.
  5. …
2 Likes
6

Glad to see positive reception. Love it or hate it, please all feel free to let us know how you think about it!

I like the suggestions by @schmunk and @samdark on standards and best practices. Not only do they drive good quality and performant code, it also makes it easier for more people to contribute to the same code. Personally I would advocate keeping these in sync with the standards and best practices applied to the core framework itself, but the final decision on that is in the end up to the yiipeople core team right?

1 Like
7

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.

1 Like
8

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.

9

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

10

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.

3 Likes
11

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.

1 Like
12

I love the proposal and I agree completely. My small suggestion, instead of saying yiipeople why can’t we use yiiextensions as organization?

1 Like
13

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.

1 Like
14

I agree to your point of view. But I feel yiiextensions as more professional.

15

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.

2 Likes
16

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).

4 Likes
17

That’s one of the goals.

1 Like
18

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”.

19

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

20

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?

5 Likes