Code that can be included
-------------------------

* Must be forkable:
    - Must be released under a free / open source license.
    - The author(s) must NOT object to modification.
    - Must not expose internals in APIs (which could make modification
      difficult).
* Must be easilly buildable:
    - Must have an automated build.
    - Should not add build dependencies.
    - Cannot ever build-depend on anything that doesn't comply
      with these rules.
    - Cannot ever build-depend on external network services.
    - Must build reproducibly.
* Must be maintainable:
    - Must have automated tests.
    - Must have some minimal level of comments, documentation, or similar.
    - Tests must run using software that complies with these rules.
    - Should not add more coupling to other components than necessary.
* Does NOT have to be complete/finished!
    - You can start it, and someone else can continue working on it :)
      (No code is "owned" by anyone.)
    - However, unfinished functionality MUST be somewhat isolated from
      finished code, so it does not break existing functionality.
    - A contribution can involve a mix of finished and unfinished code,
      for example it could contain bug fixes to existing functionality
      (which should have good qualitive and have tests etc.) in addition
      to new functionality (for which the expectations are much lower, as
      long as it is somewhat isolated from other code).


As an example, consider that slul-try2 would be functional, and a patch
to add a new code generator would be received. Then:

* It could extend the "base code" for code generation
* It should not change (or remove) existing interfaces though, if those
  interfaces are exposed for dynamic linking.
* It should not depend on any external tools, such as assemblers, linkers,
  etc. Instead, it should have machine-code generation built-in.
    - And this applies to basic tesing as well. There should be some basic
      tests built-in.
    - And it is often better to have a few large/combined end-to-end tests
      than many small isolated tests. This may sound counter-intuitive, but
      it's from experience :) Isolated tests have a tendency to only cover
      a small set of known code paths, while larger combined tests can cover
      "unknown unknowns" that the code authors didn't think about (which is
      pretty much the main point of tests).
* It can start minimal. It doesn't have to be functional, but it has to
  compile (and comply with the guidelines).