Skip to content

Latest commit

 

History

History
102 lines (69 loc) · 5.86 KB

SEP-0001.md

File metadata and controls

102 lines (69 loc) · 5.86 KB
Raw

SEP-0001 - SEP Purpose and Guidelines

SEP 1
title SEP Purpose and Guidelines
author(s) Steven Christe
contact email steven.d.christe@nasa.gov
date-creation 2014-03-05
type process
discussion unavailable
status accepted

What is a SEP?

SEP stands for SunPy Enhancement Proposal. A SEP is a design document modeled after the Python Enhancement Proposal which describes a new SunPy feature, process, or major changes to existing processes or features. The purpose of the document is to present a concise technical specification and rationale for the new feature or change. Anyone can submit an SEP.

Changes that typically require a SEP

  • major new features in SunPy
  • major changes to the user-facing API
  • major refactoring of the backend

Changes that do not typically require a SEP

  • the addition of new sources to maps, light curves, Spectra, etc.
  • bug fixes
  • minor enhancements

SEP Types

There are generally three types of SEP.

  • Standard: This SEP introduces and describes a new feature or changes to an existing feature (e.g. API change). The purpose of this type of SEP is to be at first a proposal and eventually mature into a design document (if accepted). It is generally a good idea for a Standard SEP to come before any code has been written.

  • Process: This type of SEP describes a new process or a change to an existing process in the management of the SunPy project. Examples include procedures, guidelines, changes to the SunPy decision-making process or management structure, and changes to the tools or environment used in SunPy. Any meta-SEP (proposed changes to the SEP process) is also considered a Process SEP.

  • Informational: This SEP provides information and does not introduce any new features or changes nor describes a new process.

SEP Workflow

Creation

SEPs should contain a concise description of a single new idea or proposal. SEPs are generally not necessary for small enhancements through a SEP may sometimes be requested by The Steering Committee in some cases even for small changes. A SEP begins its life as a proposal. Legibility, organization, and focus are key features of a successful SEP. SEPs can be rejected out-right if they lack any of those characteristics. All SEPs must identify a champion (usually the author) whose job it is to present and defend the proposal. It is generally a good idea to discuss the new idea with the community before going to the trouble of writing a SEP in order to gauge general opinion however, it is not required.

All SEPs creators should begin with the SEP template which is stored as SEP-template.md. All SEPs are stored in the sunpy/sunpy-SEP repository. Fork the repo and create a new file with your SEP. SEP are written with markdown.

Amending a SEP

If a topic is already covered by an existing SEP and the change is not a major one than it is appropriate to propose an amendment to an existing SEP. All the usual rules apply and processes apply to the amendment of a SEP as for the creation of a new SEP.

Submission

All new SEP should be submitted into the sunpy/sunpy-SEP repository by pull request.

Review Process

Once an SEP is submitted, as a pull request to the sunpy-SEP repository, it will be discussed via normal development channels. The Steering Committee is tasked with accepting an SEP, this should be done on the basis of agreeing there is commuinity consensus, however, they may act as a tie-break if needed. The Steering Committee are also responsible for editing SEP drafts and supporting authors of SEPs through the process. Once an SEP is accepted, its implementation can be reviewed through the usual process. Once the implementation is complete and accepted the status of the SEP shall be changed to implemented.

  • Discussion: This means that SEP is currently being considered and a decision has not been made.
  • Accepted: The SEP has been accepted and it will be assigned a number and merged into the sunpy-SEP repository. A decision rationale must be drafted and added to the SEP by the Steering Committee. If the SEP is of the Standard type then it can now be implemented.
  • Implemented: Only valid for a Standard SEP. This status means that the feature discussed in the SEP is implemented and has been merged into the main SunPy repository. The Steering Committee must vote to approve an SEP by a simple majority.
  • Rejected: The SEP has been rejected. A decision rationale should be provided by the Steering Committee and the SEP should still be assigned a number and merged in order to close the issue. It should be noted that a future SEP can supersede the decision.

SEP Template

Also stored in SEP-template.md

SEP-num -- SEP Title

SEP num
title SEP Title
author(s) First Last
contact email me@myemail.org
date-creation YYYY-MM-DD
type process, standard, informational
discussion link to discussion if available
status discussiom, accepted, rejected

Introduction

A short description of the SEP including a statement of the problem the SEP is seeking to solve

Detailed Description

If this is a standard SEP this section should contain usage examples.

Decision Rationale

This is a great idea because...