SPEC stages / decision points / language

[jarrodmillman]

This is a follow-up to issue #81.

The language about the stages / decision points is not great. Currently, this is what we have

In #79, there are these options

Option 1 is most similar to the current draft where the focus is on decision points. Options 2 and 3 are more related to my older idea of organizing things into stages during which each SPEC document is in a certain state and "ends" with a decision made by some group about the SPEC document.

[dschult]

I like Option 3. :} It makes it more clear who makes the decision, and the stages are identified with minimal overlap with the verbs that describe the decisions.

[dschult]

The big thing is to get the language decided for both states and actions. Then the rest is already written and pretty clear. One suggestion is to reduce the number of names by calling the stages: Proposal, Draft SPEC and SPEC. Then the verbs are clearly verbs and not stages.

We propose the proposal. The Steering Committee Accepts the proposal and turns it into a Draft SPEC. The Core Projects endorse the Draft SPEC. and the Steering Committee (or an administrator?) approves it when 2 Core Projects endorse it. Approval involves changing it from a Draft SPEC to a SPEC. Further endorsements can be made. But if the number of endorsements falls below 2, the SPEC is no longer Approved and becomes a Draft SPEC.

what a mess... OK... so I think the verbs were: propose, accept, endorse, approve, adopt.

[jarrodmillman]

As soon as two core projects are listed in the endorsed-by field of a SPEC in the main branch, the SPEC is no longer marked as a draft: scientific-python/scientific-python.org@2686022

We need to do a bit more work on the logic, but the draft to not draft will happen automatically when there are two core projects listed in the endorsed-by field.

[pllim]

Once this is finalized, would be nice to have the process clearly laid out in repo README so it is immediately clear to outsiders.

For instance, a random repo wants to start adopting some of these SPECs and realized they also maybe want to propose an update or a completely new SPEC. But their repo is not listed in your core-projects. Should they even bother? Who are the SPECs for? How do you make it into core-projects? Can you be part of this without being part of core-projects?

[bsipocz]

Can you be part of this without being part of core-projects?

yes, there are the non domain specific core-projects. They endorse and adopt specs, but other libraries can also adopt them.