| SEP | 029 |
|---|---|
| Title | Update to issue procedure for SEPs |
| Authors | James Alastair McLaughlin (j.a.mclaughlin@ncl.ac.uk) |
| Editor | Zach Palchick |
| Type | Procedure |
| Status | Accepted |
| Created | 17-Oct-2018 |
| Last modified | 17-Oct-2018 |
| Issue | #64 |
SEP 001 defined the procedure for managing SEPs. This procedure currently mandates that all SEPs remain "open" on the issue tracker so that they are all visible by default. This SEP proposes that this requirement is changed so that SEPs issues can be closed when action is no longer required. This SEP also clarifies that the definitive text for an SEP is in the repository and not the issue tracker, solving the problem of unnecessary copy and pasting between the two. Finally, this SEP also recommends that SEPs concerning the specification are accompanied by a pull request to the SBOL specification repository.
It is generally accepted (citation needed) when using GitHub for software development that an open issue is something that requires attention, and when attention is no longer required, the issue can be closed. As we are repurposing the GitHub issue tracker for keeping track of SEPs, it would therefore be logical that the issues SEPs that no longer require editorial attention (e.g. revoked, or merged into spec) can be closed.
Moreover, in the current system, the text of SEPs is duplicated; it is usually copied once for the markdown file contained in the repository itself, and once for the issue. In this SEP we recommend that the text of SEPs exist only in the repository. SEPs can then remain permanently in the repository for posterity, while their issues can eventually be closed by the editors. Using the repository as the definitive resource rather than the issue tracker is important for openness: issues are only accessible by the proprietary GitHub API, whereas the repository itself can be cloned or moved elsewhere. The current system also suggests that issue numbers correspond to SEP numbers, which has not been the case in practice.
Finally, there is a latency issue between the acceptance of SEPs and their merging into the SBOL specification. This SEP attempts to mitigate this by recommending that any SEP concerning the specification is accompanied by a pull request to the SBOL specification repository.
The following text of SEP 001 under "2.5 Decision":
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.
Is superceded by the following:
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.
The following text under "2.2 SEP Submission":
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.
Is superceded by the following:
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.
After the steps for forking and opening a pull request to the SEPs repository in "2.2 SEP Submission", the following text is added:
If the SEP concerns the SBOL specification, it is recommended that a corresponding pull request is also opened in the SBOL specification repository. This ensures that if the SEP is accepted, it can be swiftly merged into the specification.
It should be noted that closed issues are not deleted and are always accessible and searchable through the same user interface as open issues.
To the extent possible under law,
SBOL developers
has waived all copyright and related or neighboring rights to
SEP 002.
This work is published from:
United Kingdom.