Skip to content

Latest commit

 

History

History
50 lines (25 loc) · 2.25 KB

TEMPLATE.md

File metadata and controls

50 lines (25 loc) · 2.25 KB

INSERT Title Here

Abstract

Provide overview of intent of BEP here. A short (~200 word) description of the issue being addressed.

Preamble

BEP-Id: BEP-0000

Status: Draft | Active | Accepted | Deferred | Rejected | Withdrawn | Final | Superseded

Version: 1

BEL-Version: 2.0.0 (which version(s) of BEL are to be changed by this BEP)

Authors: Jane Doe ([email protected]), John Smith ([email protected])

Created-Date: 1900-01-01

Type: Standards Track | Informational | Process

Replaces: BEP number (optional)

Superseded-By: BEP number (optional)

Rationale and Goals

The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work. The proposal needs to indicate why current BEL Language features are not sufficient.

Use Cases

Share how the new language feature will be used. For example, adding a populationAbundance() function would allow capturing population level changes due to environment or treatment. Consumers would be the EPA, Toxicologists, Microbiome biologists, etc.

Discussion

Add any questions or discussion points for the community in your proposal. This is a place to add particular questions or discussion points. Discussions and comments can be carried out in either the pull requests or in the OpenBEL Google Discussion Group.

Specification

The technical specification should describe the syntax and semantics of any new language feature.

Backwards Compatibility

All BEPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The BEP must explain how the author proposes to deal with these incompatibilities. BEP submissions without a sufficient backwards compatibility treatise may be rejected outright.

Reference Implementation

The reference implementation must be completed before any BEP is given status "Final", but it need not be completed before the BEP is accepted. While there is merit to the approach of reaching consensus on the specification and rationale before writing code, the principle of "rough consensus and running code" is still useful when it comes to resolving many discussions of BEL Language and API details.