Criteria for accepting new profiles

[eqrion]

From the Q&A:

What are suitable profiles and criteria for introducing new profiles?

    This question is mainly deferred to future proposals and the discretion of future CG discussions; evaluating the need for new profiles associated with a feature proposal could become part of the process document.

I generally agree with this, but it sounds like from the CG discussion that there is an appetite for something more precise here.

Here is a possible procedure we could adopt:

1. A new profiles.md document is added to meetings/process. This document serves to define the acceptance criteria of new profiles, not the spec mechanisms of how profiles work.
   - An initial version could just be a copy of the goals/non-goals/risks/intended-properties sections from the Overview.md
2. Proposals may introduce new profiles or change existing profiles.
3. Any change to defined profiles by a proposal should be evaluated against the profiles.md document when we vote on advancing the feature to Phase 2 and 4.
   - Those are the phases where the CG typically votes on whether a feature makes sense.
   - Phase 1 proposals are not required to decide on changes to profiles yet.

In the end, whether we add a profile or not would just be a judgement call of the CG guided by pre-agreed upon goals. I'm not sure if adding more process beyond that would be beneficial, but open to other thoughts.

cc'ing parties who participated in the CG meeting today:
@dtig @rossberg @conrad-watt @titzer @penzn

[rossberg]

That all makes sense to me, except that I would perhaps incorporate it into the main process doc (in order to avoid having N versions of process doc in the future, one for each potential sort of proposal).

[eqrion]

Just to be clear, I'm not trying to create a new separate kind of proposal for profiles. I think we should reuse the existing proposal and phase process for changes to profiles.

The process above is specifying where we put the 'rules' around profile changes (profiles.md), and when we enforce those rules in the proposal process (phases.md).

[rossberg]

I'd view profiles as a form of proposal, or part of a larger proposal. I don't think they are super special in that, and I expect that we'll see a larger variety of "classes" of proposals in the future anyway. Not sure if there is a benefit in scattering process "diffs" for them across multiple documents.

[eqrion]

Sure, I don't have that strong opinion about where the goals/non-goals/risks/intended-properties of profiles live. I just think they need to be somewhere and then referenced in the phases as the standard that we use when evaluating profiles.

[dtig]

One note here is that the existing process for profiles is meant to be non-blocking, i.e. that different proposals can independently make progress and we resolve conflicts ahead ahead of merging into the main spec (of course with discussion ahead of time). But if the goal is to keep the number of profiles as small as possible, the process should have some language on merging profiles if/when necessary. I wonder if a good next step is to start with a draft document in this repository that can then be merged with an existing doc/added to the process directory?