This criteria list is a work in progress - feel free to recommend improvements.

Phase 1 - Identification

• Candidate Name
  
  
• Status
  Assigned by the lsb-futures team; shows where the candidate currently is in the process

  Complete	Met all criteria, recommended to LSB Workgroup for inclusion in the LSB
  Target XXX	In active development, targeted for handover for LSB version XXX
  Active	Active consideration, no major blocks but not far enough along to assign a Target
  Blocked	One or more criteria are a problem (usually more than just "nobody working on it")
  Inactive	Not currently under consideration due to being blocked for an extended period of time.

• Group
  Which LSB (or FSG) sub-group the candidate is being tracked by.
  
  
• Candidate Number
  Assigned by the lsb-futures team; a tracking number to aid in referring to the candidate
  
  
• Demand
  There needs to be sufficient demand for the component to be standardized. Demand can be measured many ways. For example, heavy usage of a component in the community or multiple requests from developers. Keep in mind that, while there may be demand for many things, not all will meet the additional criteria.
  
  
• License
  The component should have at least one compliant implementation available under an Open Source license that also promotes a "No Strings Attached" environment for developers. This means that the developer would be able to develop and deploy their software however they choose using at least one standard implementation. This is interpreted to mean that at least one implementation is available under a license that meets the Open Source Definition but is does not prohibit propriatry usage. The rationale for this criteria is very similar to that of the LGPL.
  
  
• Best Practice
  The candidate must represent the "best practice" in the development community for the problem it solves. It needs to have emerged as a clear de facto standard and be available on most (or all) of the major distributions.
  
  
• Stable ABI/API
  The API/ABI is required to be stable enough to target for standardization. The maintainers need to follow the "best practices" for ABI/API stability. They should have a proven track record for doing so and properly resolving any issues that arise.
  
  
• Dependencies Present
  The candidate's runtime dependencies should either already exist in the LSB, are planned to be added, or abstracted away so that specifing their interfaces is not required. Dependencies provide insight for things that may need to be added and/or potential problems that may be encountered. Recursive dependencies should be listed and discussed before proceeding.
  
  

• Upstream Cooperative
  The upstream maintainers must be committed to backwards compatibility(for some defined version) and stability. They should be willing to work with developers and distributors on providing a standard everyone can agree on and adopt.
  
  
• Distribution Maintainers Cooperative
  The component maintainers for the distributors should be willing to work together. They should be willing to work with upstream maintainers and developers on providing a standard everyone can agree on and adopt.
  
  
• Component Versions
  The upstream maintainers, distributions, and developers should be synced up on compatible versions. If not they should be willing to agree on and adopt compatible versions.
  
  
• Distribution patches
  If the distributions maintain any patches against the component, these could be merged upstream or dropped. Since the LSB is a behavioral standard this is not required but could make things easier.
  
  
• Internationalization
  If the component interacts with the user it should, if possible, have internationalization(i18n) support and support localization(l10n) as appropriate. Lack of locale data should try to be remedied in a timely manner, although it is hard to support every locale.
  
  
• Resources
  Resources for working on the deliverables required in Phase 3 should be arranged. A component may be an excellent candidate for standardization but can't proceed until there are people to do the work. Depending on the candidate there may be parties who would benefit from the standardization and could reasonably by asked to contribute to the effort.
  
  
• Rationale
  The rationale for the why the component was added and for all parts of the specification should be recorded and published. Mailing lists and meeting minutes are not sufficient, this data needs to be recorded in the specification or a separate document. Lack of rationale documentation has already been a problem with older versions of the specification, so this is very important.
  
  

• Import into LSB Database
  Import the component into the LSB database as a first step for working on the spec/tests/devel/sample.
  
  
• Written Specification
  Development/adaptation of the written specification for that component in the proper format for integration into the LSB specification.
  
  
• Initial Test Suite
  Development/adaptation of the test suites for that component in the proper format for integration into the LSB test suite.
  
  
• Development Components
  If required, creation of source for the stub libraries and header files for that component in the proper format for integration into the lsbdev environment. For simple components, these may simply be used as a cross-check against the DB-generated headers and libraries.
  
  
• Sample Implementation
  Build of the sample binaries for that component in the proper format for integration into the LSB sample implementation. If suitable, should also include a recommendation of a reasonable application that uses the component for inclusion into the Application Battery.
  
  
• Application Battery
  If suitable, should also include a recommendation of a reasonable application that uses the component for inclusion into the Application Battery.
  
  

• Once a candidate has completed all 3 phases, the Futures subcommittee will recommend it to the LSB Working Group for inclusion in the next version of the LSB. The items completed in Phase 3 will be transitioned to the Written Specification, Test, and Tools subcommittees.