Skip to content

docs: add sig and wg guidelines #53

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
CyrusVorwald wants to merge 1 commit into
base: main
Choose a base branch
from
Open

docs: add sig and wg guidelines #53

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 3 additions & 2 deletions guidelines/governance/sig-governance-guidelines.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,4 +1,4 @@
# SIG Governance Guidelines
# Special Interest Group Governance Guidelines

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
Expand Down Expand Up @@ -44,10 +44,11 @@ The technical lead MUST do the following:

- Triage issues
- Optimize software development lifecycle, process, and workflow
- Resolve cross-project technical issues

## Project management

Each SIG project MUST define the rationale, methodology, and public observability for
The SIG MUST define the rationale, methodology, and public observability for
Copy link
Contributor

@han-so1omon han-so1omon Sep 14, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would stick with "each sig project", as it is better decentralized chain of responsibility in likely the event that projects under the same sig are run by different people and have different priorities and release dates


- how priorities are determined, staffed, managed, and accepted.
- how target release dates are determined
Expand Down
44 changes: 44 additions & 0 deletions guidelines/governance/wg-governance-guidelines.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,44 @@
# Working Group Governance Guidelines

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
[RFC 2119](https://www.ietf.org/rfc/rfc2119.txt).

## Introduction

The purpose of this document is to describe working group (WG) practices and guidelines. WG members MUST adhere to these guidelines where applicable.

### Relationship to SIGs

All WGs MUST define their relationship to SIGs and follow the related SIGs guidelines. Deviation from related SIGs guidelines MUST be explicitly declared with stated rationale.

## Leadership roles

### Execution Lead
Copy link
Contributor

@han-so1omon han-so1omon Sep 14, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have a few questions

  • Can you explain the purpose of creating a distinction here between technical lead and execution lead?
  • Is this similar to the "chair" role?
  • Why would the technical lead not set the priorities of the working group?
  • Why are there not roles defined in the sig-governance guidelines?

My thought is that possibly there could be an execution lead or liaison between the sigs, but that the sig technical leads should maintain their roles as technical leads for this project. That also has the effect of eliminating confusion over technical leadership in a group that is explicitly stated to be a collaboration between other groups that already have technical leads

Copy link
Contributor Author

@CyrusVorwald CyrusVorwald Sep 14, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's the equivalent of separating out a product owner from a technical lead. The distinction is that the person responsible for the execution of the project may not necessarily be involved on a technical level. It's possible that these are both the same person, but generally should not be.

There are roles defined in sig-governance. See https://github.com/icon-project/community/blob/594c06d3d22adce71d2b3c6d7e5f1864b67fdfc6/guidelines/governance/sig-governance-guidelines.md#leadership-roles

Copy link
Contributor

@han-so1omon han-so1omon Sep 14, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would say that typically a special interest group is responsible for a project, and only in certain cases is a working group is responsible for a project. By your logic, should there not be an equivalent role in the special interest group?

Copy link
Contributor

@han-so1omon han-so1omon Sep 14, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And why should the technical lead generally not be the same as the person responsible for the execution of the project? They are both popular ways to run a project.

Copy link
Contributor Author

@CyrusVorwald CyrusVorwald Sep 14, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Correct. The "Chair" role in a SIG would be the equivalent, but it is more broad and strategic. These roles can be honed more as this structure gets adopted.

Copy link
Contributor

@han-so1omon han-so1omon Sep 14, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I recommend to remove the technical lead role from the working groups. Execution lead can coordinate with technical leads and chairs for the collaborating sigs


The execution lead is responsible for the overall health and execution of the WG. The execution lead MUST:

- Ensure that the WG goals and objectives are set
- Set WG priorities and roadmap
- Ensure that the WG adheres to the related SIGs guidelines
- Ensure that the WG has sufficient resources to succeed
- Ensure that WG progress reports are submitted on a monthly basis
- Facilitate communication and cross-SIG collaboration if the WG is related to multiple SIGs
- Take on technical lead role if the technical lead is not designated

### Technical Lead

The technical lead is responsible for the technical health and execution of the WG. The technical lead MUST:

- Triage issues
- Ensure that the WG is adhering to the related SIGs technical guidelines

## Disbanding

WGs MUST disband if
- scope is completed
- there has been no communication activity for 1 month in the defined communications channels
Copy link
Contributor

@han-so1omon han-so1omon Sep 14, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it should be longer than 1 month. I would support either of the following:

  • 3 months, because there is not really a bad effect of keeping the group open, other than clutter. and i think patience is appropriate here
  • raise the question after 2 months (e.g. 'anyone here?')


## Archiving
- WGs that disband MUST be archived in the [archives/working-groups](/archives/working-groups) folder.