Permalink
Browse files

Merge pull request #69 from SynBioDex/sep-029

Incorporate changes adopted in SEP 029
  • Loading branch information...
ckmadsen committed Jan 14, 2019
2 parents bb7a1c6 + bcbbcab commit c19935d820eb3769156ce54920f7010fcc3fd4f9
Showing with 5 additions and 3 deletions.
  1. +5 −3 sep_001.md
@@ -8,7 +8,7 @@
| **Type** | Procedure |
| **Status** | Accepted |
| **Created** | 05-Oct-2015 |
| **Last modified** | 20-Feb-2016 |
| **Last modified** | 30-Dec-2018 |
## Abstract

SEP stands for [SBOL](http://sbolstandard.org) Enhancement Proposal. A SEP is a design document providing information to the SBOL community. It may describe a new feature or term for the SBOL data model or a rule or organizational process that the SBOL community should follow. The SEP should provide the rationale and a concise technical specification of the feature.
@@ -70,7 +70,9 @@ Following a discussion on sbol-dev or other channels (e.g. during an SBOL worksh
4. Edit your SEP directly on github
5. Initiate a **pull request** for your version of the repository on https://github.com/SynBioDex/SEPs

If approved, an editor will submit the SEP to the dedicated github issue tracker, for which only SBOL editors have write-access. The github issue number then becomes the SEP number by which the proposal can be referenced. The SBOL editors will _not_ unreasonably deny a SEP. Reasons for denying SEP status include duplication of effort, being technically unsound, not providing proper motivation or not addressing backwards compatibility.
If the SEP concerns the SBOL specification, it is recommended that a corresponding pull request is also opened in the [SBOL specification repository](https://github.com/SynBioDex/SBOL-specification). This ensures that if the SEP is accepted, it can be swiftly merged into the specification.

If approved, an editor will merge the pull request for the SEP into the dedicated SEPs repository on github, for which only SBOL editors have write-access. The SBOL editors will _not_ unreasonably deny a SEP. Reasons for denying SEP status include duplication of effort, being technically unsound, not providing proper motivation or not addressing backwards compatibility.
### 2.3 SEP Discussion and Updates

Authors are explicitly encouraged to update their SEP as the discussion progresses and their ideas are refined. As updates are necessary, the SEP author(s) can email new SEP versions to the SBOL editors, who will update the issue accordingly.
@@ -83,7 +85,7 @@ This is simply a list of any open SEPs that offer a competing or contradictory p

Eventually, an SEP is either withdrawn by the authors or put to a vote by the SBOL Editors (or any two developers). The exact voting procedure is described in SEP #5. If approved, the SEP will be marked as “Accepted”. Once a change is implemented, the status changes to “Final”. Approved procedural SEPs (e.g. concerning SBOL governing rules) are labelled as "Active", indicating that this rule may be further adapted in the future.

All SEPs will always remain "Open" on the issue tracker so that they are all visible by default. Editors attach and update issue labels to allow easy filtering for SEP Type and Status.
SEPs remain "Open" on the issue tracker until they no longer require attention; i.e., have been either accepted and merged into the specification, rejected, or revoked.
## 3. The SEP document <a name='document'></a>
### 3.1 SEP Types

0 comments on commit c19935d

Please sign in to comment.