docs/project/core_inclusion.pod - Core Inclusion
This document address questions we will consider when deciding whether or not to move a piece of code into core.
Occasionally useful bits of code will arise that someone thinks should be made core components of Parrot. This document lists some of the questions we'll consider when deciding whether this is a good idea.
When considering whether to add code to Parrot, we'll ask ourselves and the developer(s) the following questions, in approximate order of importance. This is not an exhaustive list as much as a guide to help us make sure we think through the implications of adopting and supporting a new core component.
How will it help Parrot and its users to further their goals? Examples include better debugging, increased execution speed, better code generation and improved modularity.
This is somewhat subjective, but the main question concerns how high the maintenance burden will be relative to the benefits the code will provide.
More specifically, will the addition make development more fun for the majority of Parrot's users. A generic optimization framework would help most projects and have a good chance of inclusion. A specialized math library or an HLL-specific datatype won't be of use to most projects and should live as a separate project.
If we can't figure out how it works or if it does what it claims, it'll have a hard getting accepted. We have enough undertested and underdocumented code already.
Core code needs to be maintained. If an experienced core committer expresses willingness to maintain an addition, that's good. If that committer has worked with the code, that's better.
We want Parrot to run on as many platforms as possible. If the code has any OS- or CPU-specific components, are they well-separated and easy to port to other systems?