Incorporate changes adopted in SEP 029

This commit updates the language of SEP 001 to be consistent with the proposed changes in SEP 029. Namely, it allows for SEP issues can be closed when action is no longer required. This commit also clarifies that the definitive text for an SEP is in the repository and not the issue tracker.

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