What are the objectives of each TAG?

[joshgav]

We need to help project maintainers and end users understand the value prop of participating in and using TAGs. To this end, it would be helpful for us to develop a common understanding of why our TAGs exist and their primary objectives. From these objectives we'll be able to extract and promote the values TAGs provide.

To that end, following are the objectives I pursue in TAG App Delivery. Can leaders of other TAGs share theirs?

1. Govern projects in our domain. For example, ensure cloud-native fit of projects, ensure healthy ongoing development, enable eventual graduation.
2. Build awareness of and enable users with projects across our domain. For example, produce compare/contrast posts for overlapping projects, produce sample code, and write overview papers.
3. Develop common patterns and standards and promulgate them across our domain. For example, encourage projects to adopt CloudEvents and CDEvents and use standard "app.kubernetes.io" labels.
4. Gather end user feedback and use as guide for projects in our domain. For example, interview users and ask them to share stories in meetings.

[TheFoxAtWork]

Some of this is in the TAG Charters, understanding the deltas between the charters and the work of the TAGs is important to level set expectations and align consistently in the work the TAGs pursue.
Potentially we can "slurp" the charters and pull a comprehensive list together.

[TheFoxAtWork]

We have Riaan Kleinhans working on bringing some of this alignment and has an initial assessment on the deltas between the TAGs.

there is a lot of work that is needed to standardize what is a TAG, and much is out of date. This is a good opportunity for us to establish a TAG framework.

[TheFoxAtWork]

Anticipated summary of work to close deltas/analysis of the current charters in January

[aliok]

Following is not about the original topic (objectives of each TAG), but, since it is brought up...

to standardize what is a TAG

It is for me hard to evaluate the level of flexibility CNCF wants to give TAGs on how they want to operate (similar to CNCF projects being flexible with how they operate), but what would be nice is some standards on things like elections, contributor ladders, roles etc.

Here's a relevant issue for TAG Contributor Strategy: cncf/tag-contributor-strategy#541

[TheFoxAtWork]

Context to be clear is important, as is the scope. The "why" as to how TAGs exist and operate.

[lhmzhou]

from the charter: https://github.com/cncf/tag-observability/blob/main/observability-charter.md#areas-considered-in-scope

[amye]

This is on the agenda for the next TOC meeting, Feb 6th.

[angellk]

Fantastic! This is a great (needed) topic. Is there anything that needs review and comment on prior to the TOC meeting?

…

On Tue, Jan 30, 2024 at 2:57 PM Amye Scavarda Perrin < ***@***.***> wrote: This is on the agenda for the next TOC meeting, Feb 6th. — Reply to this email directly, view it on GitHub <#1205 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGMEV7NRWQXCUF2ACHDGETYRFUETAVCNFSM6AAAAAA7GOTUCWVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DGMJRG43TC> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[TheFoxAtWork]

@angellk , not necessarily anything to review or comment. The impetus was to clarify the objectives and work of the TAGs, understand if the work in front of them and being asked of them is the work they are chartered for. the deltas between the charters and the work of the TAGs is important to level set expectations and align consistently in the work the TAGs pursue.

[xing-yang]

Here are Mission Statement from TAG Storage charter: https://github.com/cncf/tag-storage/blob/master/storage-charter.md#sig-mission-statement:

To enable widespread and successful storage of persistent state in cloud-native environments through:

- Providing valuable and objective information to the TOC, End Users and Projects of the CNCF regarding areas considered in scope.
- Collaborating effectively with other related groups.
- Helping to maintain the continued health of CNCF Storage Projects,
- Identifying and filling gaps in the landscape of CNCF Storage Projects.

cc @chira001 @raffaelespazzoli

[chira001]

@TheFoxAtWork @amye @Riaankl - this is a brain dump where I'm trying to simplify the scope and roles for the TAGs in a simpler manner, including future areas that we may want to discuss.

Primary TAG responsibilities:
Each TAG has a common set of roles and functions which are generally common to all TAGS

• We are SMEs (within the defined scope charter) with an advisory role to help the TOC scale
• We educate and provide whitepapers, documents, guidance and other tools to enable the CNCF mission - i.e. the adoption of cloud native technologies
• We help with project lifecycle, providing expertise to help with project reviews, graduation processes and reviews of project health
• Collaborate with other groups within the CNCF and other orgs in the ecosystem to share information and ensure projects are connects where appropriate
• Proactively encourage projects which may be of interest to the ecosystem to present and consider the CNCF, providing the initial guidance and qualification
• Enable open communities through regular open meetings and helping as points of contact for inbound communication

Additional TAG responsibilities:
Some TAGs perform specific functions for the TOC or the community and need to be explicitly defined

• Roles which are specific in scope to particular TAGs e.g. security assessments for TAG Security; building and nurturing community in TAG Contributor Strategy
• General governance or oversight for both long running WGs and focused term WGs

What we are not:
It is important to explicitly define what the TAGs don’t do - primarily for the avoidance of doubt

• We are not project governance - we may help, contribute or help/guide projects
• We do not make project graduation (or indeed other decisions) - we provide recommendations to the TOC, but ultimately, the TOC has the final say on any decision
• We do not king make (i.e. we do not recommend one project over another)

Gray areas:
Areas that may be loosely defined in a charter or may need some clarification

• We may be involved in defining or helping influence standards, especially when helping projects converge on common goals. However, this is a very fine line, which may become king making unintentionally.
• Formally act as a locus for incubating and graduating projects, with a more formal update timeline to help simplify reviews and updates (this needs clarity on defining a single primary TAG for each project, and liaising with appropriate stakeholder TAGs)

TAG Roles

• Co-chairs and Tech leads are well defined and understood
• Members (and/or attendees?) are less well understood - specifically the ladder to help and participate that lead to more formal roles
• TOC Liaisons - liaison role may need to be formalized in the charter, especially if they take on an oversight role for delegated responsibilities

Where we could change:
Besides the gray areas, some areas that may be considered for the future

• Consider converting a long running WG that performs a specific function to a defined role for a TAG
• Formalize flexibility on term limits for TAG members
• Is there scope for the TOC to delegate more responsibility, under oversight, to the TAGs? If TAGs are to achieve their primary aim of scaling the TOC, this may need to be formalized.
• Have a more formal role in project qualification and review (perhaps focusing on criteria for each level including IP policy, roadmap, governance etc …)

[jberkus]

I want to introduce one more gray area:

• If a project requests specific help, do they go to the TAG or the TOC? For example, resolving a disputed SC election, or a change to a spec used by multiple projects, or other things?

[linsun]

Great list of thoughts. One thing I noticed as I serve as tag lead is often times only sandbox projects come to TAG meetings. We should do health check and annual review on graduated project as well which I don't think we are atm.

[raravena80]

From the TOC meeting, what TAGs are not:

• TAGs don't contribute to code, but TAG members can.
• TAGs don’t vote (The TOC does).

[cathyhongzhang]

I like this well-thought brain dump 👍 As I mentioned in today's TOC meeting, we can add the following in TAG responsibility: Work with CNCF TAB and TOC to identify cloud-native technology gaps and challenges.

[jberkus]

Revised from discussion:

• TAGs, as a group, are not expected to provide direct code or documentation contributions to projects.

[angellk]

Here's the mission statement from TAG App Delivery's charter:

Consistent with the CNCF TAG definition, the mission of CNCF TAG App Delivery is:

To collaborate on areas related to developing, distributing, deploying, managing and operating secure cloud-native applications with the target of delivering application in manner of cloud native.
To develop informational resources including guides, tutorials and white papers to give the community an understanding of best practices, trade-offs, and value-adds regarding to application delivery.
To identify suitable projects and gaps in the landscape, periodically updating the TOC with suggested actions in a structured manner. This includes helping the TOC with assessments and due diligence of prospective new projects.

cc: @AloisReitbauer @joshgav @thschue

[raravena80]

I think this is a great opportunity to update the TAG charters too. For example, in the TAG-Runtime mission statement we link to general TAG responsibilities, but that link doesn't have any TAG general responsibilities.

[linsun]

Related issue #1256 to track and monitor health of tags.

[TheFoxAtWork]

Quick update - discussion on this in tomorrow's TOC meeting, see Mailing list for the agenda