community
community copied to clipboard
open-telemetry
[PROPOSAL] Convert the End User Working Group to a SIG
Almost exactly a year ago, the OpenTelemetry End User Working Group was formed with the following two overarching goals:
- To increase awareness and adoption of OpenTelemetry
- To improve the project
These are the means that we developed and actively run to achieve those goals:
- Monthly End User Discussion Groups, now available in all three regions (AMER, EMEA, and APAC), including summaries to be posted to the OTel blog
- Administration of a private end-user discussion slack channel
- OpenTelemetry Community survey
- Structured end-user interview/feedback sessions, including summaries to be posted to the OTel blog
- A monthly practical learning session with talks and demos from contributors and end users
- An online space on the community site that indexes our resources
- A directory within the greater Community repo to manage our assets
- Event planning as appropriate, for example:
- OTel Unplugged Day, a community day in conjunction with KubeCon NA 2022
- Observability Abstract Workshop, a virtual workshop to encourage participation and contribution to the project by submitting talk proposals to conferences
I was not able to find documentation on the below that is specific to the OpenTelemetry Community, so this is taken from the Kubernetes community governance guidelines (emphasis is my own):
Special Interest Groups (SIGs) are persistent open groups that focus on a part of the project. SIGs must have open and transparent proceedings. Anyone is welcome to participate and contribute provided they follow the Kubernetes Code of Conduct. The purpose of a SIG is to own and develop a set of subprojects.
Working Groups are temporary groups that are formed to address issues that cross SIG boundaries. Working groups do not own any code or other long term artifacts. Working groups can report back and act through involved SIGs.”
It has become apparent that the efforts of the End User WG are, in fact, not temporary, and furthermore, serve important long-term functions: to facilitate a feedback loop between end users and relevant project SIGs in order to influence project priorities based on end user wants and needs, and to maintain a vendor-neutral space to support end users. In addition, we do own long-term artifacts that are contained in the sub-repo linked above.
As a working group, we lack the more serious “status” that a special interest group is afforded. This has made it difficult to fully develop a process for funneling end user feedback in a way that creates trackable work items and drives project priorities and improvements. It has also made it difficult to increase involvement from the community at large, both from other contributors as well as end users. Additionally, members of this working group are not able to obtain titled roles such as maintainer, even though we are active and consistent contributors to the project.
Converting the EUWG to a SIG will enable us to get more traction for our efforts by giving us a seat at the Maintainers’ table, so to speak:
- Enable us to work more closely with the core Maintainer group to develop the closing half of the feedback loop, ultimately allowing project priorities to be driven in part by its end users
- Provide a tangible business incentive for community members to get involved and contribute to our current efforts, as they would have the opportunity to obtain a titled role
- Increase visibility of our group, thereby also increasing awareness of the resources that are available to end users and project contributors
- Separate the end user group from the community group, and provide the ability for to members of the end user group to be codeowners of the resulting path
hi @reese-lee!
do you think any changes to the maintainer and approver roles would be helpful/needed?
work more closely with the core Maintainer group to develop the closing half of the feedback loop, ultimately allowing project priorities to be driven in part by its end users
I personally think this should be at the core of the End User SIG charter, and all of its user outreach should be designed around supporting this goal.
So I think that @reese-lee & I pretty clearly fit the spirit of the maintainer role even if not some of the precise words. I don't see a reason to make a lot of changes there - the main change I would make is maybe adding a sentence at the top where it says "maintainers MUST" that says something like "maintainers of SIGS that don't manage a codebase MUST set strategic priorities ...." (vs technical ones) and maybe adding something like "for SIGs that manage a codebase" to a couple of the things like "ensure adequate test coverage" that are obviously non-applicable.
However, I'm not really sure how to imagine what an "approver" or a "triager" would look like in this SIG, because those two roles as defined here are highly tied to code responsibilities. We do have folks who host ongoing monthly meetups, and there's also @avillela who has been consistently involved in the working group but only started recently so I'm not sure whether making her a maintainer yet is appropriate. Maybe we add a third role for SIGs that manage something other than a codebase, with its own definition?
I'll look into how some larger projects like K8s or Linux define their roles, and also ask in the #maintainers-circle channel, and get back to you. I'm also attending my first TAG Contributor Strategy meeting tomorrow - I don't know how those meetings run, but if there's time for open discussion maybe I can pose this there.
However, I'm not really sure how to imagine what an "approver" or a "triager" would look like in this SIG
I think the role of an "approver" or "triager" in this SIG could be linked to digesting user-feedback and converting it into actionable items. I don't think this is something the SIG needs to do alone, but also with input from the GC as mentioned in https://github.com/open-telemetry/community/issues/1933
btw, based on brief discussion in GC yesterday, it sounded like there is consensus on converting the End User WG to a SIG
Happy to see this getting some traction! Dan let me know that still remains a need for clarification of what a WG and SIG is, and the roles within those, so I'll follow up on that. Overall, I'm excited to help move this forward.
Closing this issue out, as REQUEST: New repository and team for end-user SIG #2004 has been closed and a repo sig-end-user has been created.