this is not an attempt to overregulate things but I just stumbled upon the Flowpack Repository list and realized that it’s getting a bit messy and it contains many “half-baked” packages with different naming schemes.
Event though all team members have push rights, I’d suggest to set up some (really) basic guidelines (all as basis for discussion) in order to avoid this “semi-official” collection to go wild:
New packages should be announced (here or on slack? which category/channel?) before they are published. If in doubt rather start in your own repository/namespace and migrate the package later on
The package must contain a valid composer manifest with proper dependencies ("~1.2" rather than “@dev” or “*” for the version constraint)
The package must contain a README that describes the purpose and usage
The package must contain a LICENSE file (preferably MIT)
The repository name should follow the scheme “some-package” (rather than Flowpack.SomePackage)
The repository should be registered with packagist.org
If you agree with the list above (please comment/add suggestions) I’d go through the list of packages and try to fix them/contact the contributors.
Speaking of which… What about http://flowpack.org/ ? And why is @robert and @christopher mentioned as contributors? Do we need that site? If yes, shouldn’t we rather create a subpage on neos.io?
I’d say it’s good to have it separate, because Flowpack is not Neos, so a subpage on www.neos.io would be weird.
As to why those two are mentioned: that page was created for the Single-Sign-On stuff, and that was done by them. Later nobody changed that part.
Do we need it at all? If all repos on Flowpack · GitHub had a proper and helpful description, we could just use that. OTOH such a page can group packages in a meaningful way, we just need to maintain it. Which again everyone can do.
But you’re right of course, it would be nice to have some kind of “entry point”… Would be a useful GitHub feature to be able to upload some README.md that will be displayed when browsing to Flowpack · GitHub
Anyways, personally I’d prefer not to have an extra website unless we really keep it up-to-date (= adding it to our kitchen duties).
One point re
If there are no objections I’d go ahead and rename the ones that do not match this pattern – Do you know whether packagist will pickup that change or how easy/painless it is to update it?
I think you need to update packagist manually if you change the repository name/url.
When did we decide to have repository names like that? Not that I would mind, just wondering about the reasons…
How do we handle packages getting started? They don’t fullfil these requirements (because shouldn’t be announced and on packagist yet).
Usually I would do that in my account but when working together I prefer organisations (as in case of the Codeception package).
Also what about adding PSR-2 (and maybe PSR-4) as requirements for these packages?
Is that meant as in “Nobody dare to change that part!” or “Nobody has changed that part (yet).”
IMHO if that page exists we should all have access (make it neos or a github page) and update it or get rid of it.
Again github page with this domain routed to it could be a quick way for maintaining such an entry point page.
Never, that’s why I bring it up here.
Personally I think it makes sense to follow the scheme we started with the Neos packages and with the more recent Flowpackage repositories.
I don’t think we need to overregulate things. But Flowpack packages are meant to be a collection of “high quality TYPO3 Flow packages” so I think we should not spam it with WIP projects.
That’s why I suggest that we start new packages in our own repos and move them to flowpack once mature enough and/or discuss new ideas here or on slack.
If you guys agree, I’d go and update that site to contain a more general introduction including the “rules” for new packages as mentioned. And regarding the list of contained packages: I think it would be better to make sure the packages contain helpful READMEs and proper dependencies instead of a list that will never be up-to-date…
Just a little update: In unrelated matters I tried to get the SSO packages to run with a recent Flow version. They have some great features and thorough documentation but unfortunately they are not compatible with Flow 3.x and the vagrant demo didn’t work for me either.
I had a quick look but it seems to be quite a lot of work to get those up-to-date.
Well, but for the “bigger groups”, like SSO and (Elastic)search it might still be useful (and not too much work), to explain a little bit about them there. No?
