Community extension collective

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

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

That’s one of the goals.

1 Like

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?

5 Likes

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.

5 Likes

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.

1 Like

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.

2 Likes

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?

1 Like

No rule without exception :wink: But still the goal should be one per type.

It’s explicitly non-official.

What are good examples from the community?

1 Like

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:

  1. Start by defining coding standards and some initial policies and procedures (initial because you don’t want to get stuck debating hypothetical scenarios for the next 6 months)
  2. Then create a map of the existing Yii 1.1 and Yii 2 extension landscape (and thereby also Yii 3 extension needs). Apply a basic rating system to identify which repositories we would really like to see moved to YiiPeople based on their code quality, maintenance health, etcetera. Conflicting/duplicate extensions will be spotted in this stage. This map can be our yiipeople/awesomelist
  3. Then approach extension owners about transferring their repositories and joining the initiative.
  4. As extensions land everyone can start opening tickets and committing fixes for coding standard “violations” of adopted extensions, to gradually get them to aligned with the community standards.

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.

1 Like

Maybe we need to sort that out :slight_smile: 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.