List on Packagist, we list with
league as the vendor namespace.
Shove code in a
Write unit tests. Aim for at least 80% coverage for v1.0.
DocBlock all the things.
Semantic versioning must be used to manage version numbers.
Use Travis-CI to automatically check coding standards and run tests.
Have an extensive README.
We’re doing this instead of releasing code under our personal accounts for a few reasons, but the main reason is this:
A problem shared is a problem halved.
Working together we take care of business quicker, can get more feedback and respond to issues and pull requests faster.
There are no plans to reinvent any wheels, unless those wheels are old, broken, unsafe or horrible to use. If the code cannot be installed with Composer, has an API written with BizZaroCapS, doesn’t have a single unit-test, is actually broken or the lead developer has abandoned the project, then that is a problem which can most likely be solved with a fresh start, and we’ll be on the case to make it as awesome as possible.
If this sounds fun and you’d like to join the group you can definitely do that. This is not some stuffy old-boys club where you have to be internet famous or an old friend, you just need to bring over (or start) at least one package that either complies with the rules, or intends to comply with the rules by the next major version.
Probably the best way to submit a new package is by dropping a line to one of the existing package contributors on Twitter. See a complete list above under “Our Packages”.
This group is about packages, and not about the people. To keep that clear - and to make sure people are joining for the right reasons - no members list will be posted, but we’ll let you know who is in charge of packages so you can poke them with feedback.
We are not here to tell you what to do or how to do it - and contrary to popular belief neither are they. This is an open-source project started by a few friends who wanted a fun vendor name and will continue to grow as we release more and more awesome packages.