The most important criterion is that the contribution must enhance the system. If it meets this fundamental criterion then there is a good chance that the contribution will be accepted. More specific criteria include the following:

1. It must not have undesirable effects in terms of code size, data size, CPU cycles, or determinism of the system. This restriction can be relaxed if the new behavior can only be explicitly enabled by means of one or more configuration options.

2. It must be portable to all affected platforms. Usually this means that for anything except a new HAL package the code must be fully portable.

3. It should adhere to the project's coding standards. Most importantly the new code should contain appropriate assertions and comments.

4. Where appropriate (which is nearly always) it should be accompanied by appropriate test cases and documentation.

5. There must not be any confusion about licensing or ownership. This may require a copyright assignment.

A contribution need not meet all these requirements immediately. In fact it often makes sense to start with a proposal on the an appropriate mailing list, possibly including an initial patch which is known to be unacceptable, with the understanding that the contributor will make further changes. If there are major problems with the proposed contribution then it is better to detect these early on. If there is existing code elsewhere which does much the same job then it is good to know about this as well, to avoid duplication of effort. There may be better and easier ways to tackle the problem.