[chore] Add initiatives to workstreams.yaml

[mx-psi]

Another subset of #3337.

This one adds initiative, which is the rename I went with from this discussion #3337 (comment), from the original PR.

The first commit tries to be as close as possible to the original content of #3337. The second commit

[jack-berg]

I propose:

• that we define all initiatives as children of existing SIGs
• That the parent SIG is solely responsible for managing initiative lifecycle. I.e. accepting / rejecting initiatives, assigning leads, managing sponsorship and laying out their own sponsorship requirements.
• Because initiative lifecycle is managed by parent SIG, there is no GC liaison or TC sponsor requirement. Those are inherited through the parent SIG.

[danielgblanco]

I agree with this. This was the intention of https://github.com/open-telemetry/community/blob/main/project-management.md#project-sponsorship

If a project proposal is led by an existing SIG, TC sponsor and GC liaison for that SIG are assumed to be the sponsor and liaison for the new project. However, before approving the project, TC sponsorship level must be reviewed by the current TC sponsor. This ensures that the existing SIG is sufficiently supported if its scope is extended.

I remember we discussed this at some point between GC and TC. I can see how a new initiative may require the TC sponsorship level to change, so before it's approved the GC/TC should ensure that it has the right level of support.

If the initiative is to create a new SIG (and have some short-term deliverables for that SIG) then a new SIG is created with that initiative as the only child.

[mx-psi]

Alright, I modified it to satisfy those constraints. I am a bit skeptical about this since there may be initiatives that are cross-SIG, but maybe those should always be scoped to a cross-cutting SIG.

If the initiative is to create a new SIG (and have some short-term deliverables for that SIG) then a new SIG is created with that initiative as the only child.

I did this for the Zig SIG, could you take a look and see if that's what you had in mind? It feels a bit awkward to have the Zig SDK entry with no information

[jack-berg]

This looks weird because it should actually be just a regular SIG, not an initiative, I believe

[mx-psi]

I think your comment is missing something :)

I did it this way since the project is named "bootstrap Zig SIG", I could just put it as a SIG and remove this initiative, no strong opinion about it

[jack-berg]

I think the project is misnamed. I don't see anything in the Zig project proposal that differentiates it from other languages implementation SIGs: https://github.com/open-telemetry/community/pull/3260/changes

I think it should just be "Zig: SDK"

TC sponsor Is @jmacd

If it is in fact a normal sig and not an initiative, then this problem goes away:

It feels a bit awkward to have the Zig SDK entry with no information

[danielgblanco]

IIRC we ask folks to create a project/initiative proposal to create a new SIG, so GC can approve its creation and TC can agree level of sponsorship. Plus, it's a good way to advertise a new SIG creation and get the community to put their names down to contribute and be part of the SIG.

That's why the initiative is "Bootstrap Zig SIG". I've not had a look at the proposal but ideally it has a list of short-term deliverables. After those are done the SIG would move to BAU (i.e. what's "done" is the bootstrap, not the SIG).

I personally think it's helpful to have both an initiative and a new SIG with the bootstrap initiative when new SIGs are created. It gives the SIG an initial purpose.

[danielgblanco]

An example of this was the CI/CD SIG. The SIG was created with an initial set of deliverables. They completed them, moved on to a phase two but the rest of structures (e.g. GC liaison, TC sponsor, meetings, Slack, etc) remained the same. They just started a new initiative within that SIG.

[jack-berg]

What's the distinction between Zig and Kotlin? Both are new language implementations, with goals of developing API / SDK and reaching 1.0 stable release, but Zig is an initiative and Kotlin a SIG.

The Zig project's goals look an awful lot like BAU for a typical language implementation SIG: https://github.com/open-telemetry/community/blame/main/projects/zig-sig-bootstrap.md#L76-L89

[danielgblanco]

Kotlin should've had an initiative created to bootstrap the SIG, IMO. The intention of having these "bootstrap" initiatives was to create a set of initial deliverables that ensure the SIG is set up for success.

Let's say I'm an end-user and I see that there's new Kotlin SIG. How do I know what they're aiming to achieve in the next few months after creation? Without something like that I guess I'd have to join a meeting and ask?

[jack-berg]

This is squarely GC business so feel free to proceed however you see fit.

However, characterizing the early phase of a SIG as an initiative is in tension with the idea that all initiatves have a parent SIG because then you need to decide which SIG is the parent for it.

Seems simpler to just call it a SIG, since that's what it will become, and be clear in the project document about what activities are going to be worked on in the early phase.

[danielgblanco]

I think we're probably referring to the same thing. What I'd propose is that, when a new SIG is proposed (as an initiative/project), a new SIG is created with a single initiative under it, which is the bootstrap one as approved by GC and TC.

This just avoids a new SIG being created with no initial initiative to work on.

[danielgblanco]

For an initiative, would meetings not be inherited from SIG meetings too? Just thinking in terms of presenting this information on the community README. Not sure what the plans are there.

[danielgblanco]

I guess here if we don't have meetings or notes created we could simply render it as TBD?

[danielgblanco]

Or have them as required fields in the schema, and set them as TBD in the workstreams file.