Add document for User Groups#3564
Conversation
Signed-off-by: Severin Neumann <severin@bronto.io>
| For a User Group, the project can offer: | ||
|
|
||
| - **A dedicated Slack channel** named `#otel-<name>` (e.g. `#otel-healthcare`), | ||
| with the OpenTelemetry Admin user as a channel manager. Ask in `#opentelemetry` and |
There was a problem hiding this comment.
We could also add a Slack automation for first-time joiners to the channel that says "this is part of an OpenTelemetry User Group"
| When in doubt about a name or logo usage, ask — it's much easier to adjust early | ||
| than after a group has momentum. | ||
|
|
||
| ## Getting your group listed |
There was a problem hiding this comment.
that's TBD, we can have it on opentelemetry.io or somewhere on the community README or both
Signed-off-by: Severin Neumann <severin@bronto.io>
|
@open-telemetry/governance-committee any more feedback? |
| - A group might turn out to be **adjacent to an existing SIG** — for instance the | ||
| [End-User SIG](https://github.com/open-telemetry/community/blob/main/community-members.md) — | ||
| and the natural move is to bring the work there. |
There was a problem hiding this comment.
Should there be an additional path for a User Group to be come a dedicated SIG?
Ie. if it turns out that interest is strong and there are regular contributions to core OpenTelemetry repos, then it might be worth making the group a SIG to reduce friction.
There was a problem hiding this comment.
Yes, this is kind of hidden in the first point that they could put forward a project proposal.... the additonal sentence "in collaboration with" might make this less obvious.
What I tried to avoid stating explcitly that this is what's going to happen, most User Groups should never become a SIG
There was a problem hiding this comment.
most User Groups should never become a SIG
Agreed, I'm fine with not calling this out as an option.
In any case whenever this would occur the existing SIGs and maintainers can give guidance on the best path forward...
There was a problem hiding this comment.
Exactly, it should come naturally. The thing we don't want is people form a User Group, run it for 6-12 months and then expect to be "promoted" to a SIG. My preference would be that there are LOTS of user groups, and SIGs remain the special (...) case.
|
Is this something we want to advertise (let people know about), or only point them to it if someone asks about such an option? At the moment, I don't feel strongly about either option; I'm mainly interested in what people think about this. |
Personally I think we should advertise this, and let people know, that if they want to do things opentelemetry, here's some RECOMMENDATIONS by the project how to do it. I think especially the question around having a slack channel or spaces to meet are helpful for people to just go ahead and have #otel-whatever-they-want-to-talk-about |
| with the OpenTelemetry Admin user as a channel manager. Ask in `#opentelemetry` and | ||
| an admin can create it. | ||
| - **Access to the OpenTelemetry Zoom** for regular meetings, if your group wants | ||
| to meet synchronously. |
There was a problem hiding this comment.
I think this is something that https://ocgroups.dev/ could offer as the recommended CNCF solution for community groups. Group organizers can create their own Zoom links and recording is available as option (I've not tried it but I presume recording will go to the hosts email to handle later, potentially guests too).
This would allow groups to manage their own recordings. There are certain limitations (e.g. they have to set a max of attendees, and it can only be repeated 12 times) but I think those are pretty minor.
There was a problem hiding this comment.
Oh wow, that's really cool! Let me add this in.
| an existing SIG. See the | ||
| [project management guidelines](https://github.com/open-telemetry/community/blob/main/project-management.md). | ||
| - A group might turn out to be **adjacent to an existing SIG** — for instance the | ||
| [End-User SIG](https://github.com/open-telemetry/community/blob/main/community-members.md) — |
There was a problem hiding this comment.
Is this link intended to point to the community members page? I'm not sure I understand the relation.
There was a problem hiding this comment.
no... that's the wrong link indeed. Would https://opentelemetry.io/community/end-user/ work?
There was a problem hiding this comment.
Yes, I think that's the go-to resource :)
|
|
||
| For a User Group, the project can offer: | ||
|
|
||
| - **A dedicated Slack channel** named `#otel-<name>` (e.g. `#otel-healthcare`), |
There was a problem hiding this comment.
Would it make sense to prefix the channel with #otel_ug instead that way it is clearly a user group. Scenario is if we had a user group for wearables #otel_wearable if would look just like #otel_browsers with the later being a sig/project.
There was a problem hiding this comment.
Ooo I think this is a good consideration. I'm good with #otel-ug-*.
Co-authored-by: James Thompson <thompson.tomo@outlook.com>
- Adopt #otel-ug-<name> Slack channel convention to keep User Group channels distinct from project/SIG channels - Recommend ocgroups.dev for synchronous meetings with self-managed recordings - Mention optional welcome automation for first-time channel joiners - Fix End-User SIG link to opentelemetry.io/community/end-user/ Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
One or more co-authors of this pull request were not found. You must specify co-authors in commit message trailer via: Supported
Alternatively, if the co-author should not be included, remove the Please update your commit message(s) by doing |
Addresses #3542, this is an initial proposal for guidelines around "OpenTelemetry User Groups"