Hi Tomek,
Sorry; I just saw this! You sent it over the long holiday weekend here in the US and I just now checked this list for older stuff.
I'd like to use this feature, and perhaps similarly-scoped ones, as a way of progressing on the new process by working on a concrete case. That would involve two parallel tracks:
Track 1: Working through topics like the questions you ask, and doing what we can on your PR to have it ready for when the Track 2 is integrated.
Then we could tweak your PR to add the settings that make it appear as some stability level other than default.
So, for your questions:
1) Deciding stability level: I think the way it would work is the feature author decides what stability level they want to aim for. So that's you. Then when a feature freeze deadline comes the people working the issue either meet the requirements for that level, or they don't. If they don't they can keep working, or they can choose a different level that they can meet. They of course can also change their mind at any point, not just at the feature freeze deadline.
We should add a field for this to the wildfly-proposals template as this is info that should be available to readers of the analysis.
(FWIW this sounds like a Community level feature to me, but it's up to the feature team.)
2) JIRA: The initial development is a normal Feature Request JIRA in WFLY or WFCORE. File related issues etc as appropriate/desired to account for any independent pieces of work. So just normal stuff.
I think for any feature that's not targeting the default stability level, the JIRA title should state the target level. That makes it prominent in the release notes, and makes it easy for me to find when I write release announcements. We should come up with some standard format for how to express that.
JIRA issues are associated with a Fix Version, so once merged and that version is released, any further work to get the feature to a higher stability level would require a follow-up JIRA. I think that would be another Feature Request "Promote <the feature name> to stability level <the level>".
3) Bootstrapping.
What you should do is:
a) Start a discussion -- done, here :)
I know this work has been around for a long time, so it should be possible to do those things pretty quickly. Perhaps the biggest aspect is creating a test plan. What that means is a TODO in the proposed process. I think in general the idea of the process is to make things more formal in higher levels. These "expose component feature X via the WF management API" ones are a bit tricky as the heart of the feature is in the component (IJ), so there's always the question of how well it's tested at that level, and how much we want to document that testing.
I think for the basic Stage.MODEL management API testing we should come up with some standard boilerplate. Same for domain transformation testing. For this particular issue we can problem just use a placeholder like "standard subsystem model testing" and "standard subsystem-level domain transformation testing". I think there's a general understanding of what that means that's enough until we formally write it down.
HTH,
Brian