New project to fork dingo/api & dingo/blueprint?

[dmason30]

https://github.com/dingo/api
https://github.com/dingo/blueprint

Currently uses this jwt-auth as a dependency too.

This projects original maintainers have been absent a long time and was handed over to @specialtactics. Due to not having full control over the project @specialtactics a few months ago forked the api repo to:

https://github.com/api-ecosystem-for-laravel/dingo-api

However, there has been little activity since then and we are still waiting for Laravel 9 PRs to be merged:

dingo/blueprint#90
api-ecosystem-for-laravel/dingo-api#18

There is quite a bit of interest around these packages still and I wonder if it would be easier for @specialtactics if we moved it to https://github.com/PHP-Open-Source-Saver with more maintainers, including myself as I have a project we are still using it in too!

[mfn]

No one wrote back so far here? 👀 Sorry 😬

Basically what you wrote makes sense and the organization name was chosen for this reason (though I wasn't involved with all of this, I joined for jwt-auth later). We also welcomed https://github.com/PHP-Open-Source-Saver/laravel-acl not long ago.

I would like to suggest that, before moving on and embracing new projects, we should come up with some specific guides or even rules what constitutes a valid project to add here and some docs how to cultivate it (i.e. to keep the "bar for standards" or something).

Pinging @Messhias @specialtactics @eschricker (we can also discuss this on our internal board first)

[dmason30]

We ended up removing the dingo packages due to lack of maintenance. Shortly, after the PRs linked above were merged 😅.

However, this does mean that I am no longer going to be involved if this package does end up becoming a community fork.

[specialtactics]

Hey guys, sorry I clearly don't check my github emails frequently enough.

Yes, I forked it a while ago, and I have someone helping me maintain it. Our actual goal is to completely move away from dingo/api as it's become somewhat obsolete, but it will take quite a bit of work in terms of porting over the required features and syntax, and re-implementing them differently.

I think the result of that goal will actually be a new package, so I think it's not much point to move that package again, as I don't see much of a future for it.