For a package to become part of Sage’s standard distribution, it must meet the following requirements:
License. The license must be a GPL version 2+ compatible license.
Build Support. The code must build on all the fully supported platforms.
A standard package should also work on all the platforms where Sage is expected to work, but since we don’t fully support these platforms and often lack the resources to test on them, you are not expected to confirm your packages works on those platforms. However, if you can, it is better to do so. As noted here, a failure of Sage to work on a platform where it is expected to work, will be considered a bug.
There is no need to worry too much about platforms where Sage will probably not work though if it’s clear that there is significant effort taking place to port Sage to a platform, then you should aim to ensure your package does not cause unnecessary headaches to those working on the port.
If it’s clear that a port is stagnent, with nobody working on it, then you can safely ignore it.
Quality. The code should be “better” than any other available code (that passes the two above criteria), and the authors need to justify this. The comparison should be made to both Python and other software. Criteria in passing the quality test include:
Previously an optional package. Usually a new standard package must have spent some time as an optional package. However, sometimes this is not possible, if for example a new library is needed to permit an updated version of a standard package to function.
Refereeing. The code must be refereed, as discussed in The Sage Trac Server: Submitting Patches and Packages.