Create sunkit-spex enhancement proposals (SSEP)

[samaloney]

Provide a general description of the issue or problem.

We have lot of information spread over issues, pull requests, google drive docs etc which make it difficult for those familiar with the project to find information let alone someone new.

Follow a similar approach as Sunpy (SEP), astropy (APE), python (PEP) to formalise the process and make us write things down for the records.

I've drafted up a few very very early concepts on the wiki here:

SSEP-1 SSEP Definition, Purpose and Process
SSEP-2 The Rationale for sunkit-spex
SSEP-3 Data Containers
SSEP-4 Modeling and Fitting

In this issue I think we should focus on:

• Is this a good idea?
• Could/should we just use SEPs?
• If need our own SSEPs so should we follow astropy/sunpy and have a separate repo or take the gammapy approach and have them in the main repo as part of the docs? md or rst?
• Surely we can come up with something better then SSEP? gammapy has PIG (Proposal for improving Gammapy) 😆

[jajmitchell]

Answering your questions in the order presented above.

1. I think this is a great idea.
2. I reckon having our own rather than using SEPs will be a much clearer way of tracking the changes in Sunkit-Spex, and of giving users an understanding of the package.
3. I don't have any strong feelings on whether we should take the SEP/APE vs PIG approach for the format.
4. How about, SKIP (SunKit Improvement Proposal) or SSIP (Sunkit-Spex Improvement Proposal)? I think Proposal for Improving Sunkit-Spex is probably a no go though.

I could add some entries for the upcoming changes to the models?

[Cadair]

Governance Cadair Enters the Room

My opinion on this is that you should definitely use SEPs.

SEPs are the manner by which the SunPy Project [1] (i.e all the packages under it etc) make these big decisions and solicit feedback from the whole community. There is already precedent for non-core packages using SEPs with SEP-12 for NDCube 2. As sunkit-spex is a SunPy package it should use SEPs and the other SunPy governance structures.

If there's a motivation to keep a secondary list of SSEPs I see no reason why a SEP can't also have an identifier specific to it's package or other subset of the project and you could keep a list of SSEPs in the docs somewhere as well.

---

[1] Standard notation applies SunPy is the project

[samaloney]

Hum any issue creating like 5/6 of them?

I think we should focus on the content for now anyway, we can move them later.

[Cadair]

Hum any issue creating like 5/6 of them?

Not in my mind, knock yourself out!