Ensure all WGs have a public charter

[caniszczyk]

No description provided.

[mayakacz]

4/6 seem to have a CHARTER.md template, but none are filled in. The TAC itself also has a placeholder.

• Vuln disclosures: https://github.com/ossf/wg-vulnerability-disclosures/blob/main/CHARTER.md
• Security tooling: https://github.com/ossf/wg-security-tooling/blob/main/CHARTER.md
• Best practices OSS developers: https://github.com/ossf/wg-best-practices-oss-developers/blob/main/CHARTER.md
• Identifying security threats: https://github.com/ossf/wg-identifying-security-threats/blob/main/CHARTER.md
• Securing critical projects: none in https://github.com/ossf/wg-securing-critical-projects
• Developer identity: none in https://github.com/ossf/wg-developer-identity
• TAC: https://github.com/ossf/tac#charter

Is the ask here to fill those in? From my read, that requires defining the mission for each group, 2/3 vote for the working group to put in place, and then ratification by the TAC.
Should we ask WGs to do this by a particular date? Do we want to preview the missions that each group proposes?

[mayakacz]

Ah, there's also a blank charters folder: https://github.com/ossf/tac/tree/main/charters

[dlorenc]

The charters contain a mix right now of governance and mission/scope info. It seems like right now is too early to really fill out the detailed governance stuff, but scope/mission makes sense.

I don't think any of the groups have a TSC yet (or even necessarily want one), so the 2/3rd part will be tough:

a. This charter may be amended by a two-thirds vote of the entire TSC and is subject to approval by the TAC.

@rhaning was going to put together some templates on what he thinks the WGs should be filling out. I can't remember which issue that's tracked in though.

[dcmiddle]

See also #13 for related discussion of scope vs. CHARTER.md
and
ossf/project-template#1 for scope in README.md template

[mayakacz]

What I was personally seeking was clarity on each WG's scope. I think that the completed README.md templates fill that desire.

Is there anything else here that still needs to be clarified? What is the best way to collect and deliver that feedback? (this issue?)

For each README.md, here are my thoughts:

• Vulnerability disclosures WG
  • Clarify that development of a new OSS vuln format only makes sense if none of the existing formats work, or we are not able to work with existing formats to develop what is needed
  • Clarify whether or not this WG intends to now or in the future enable direct reporting of vulnerabilities to this group for triage (my 2c: no)
  • It's unclear what 'membership' means for the listed individuals, and should probably be defined centrally across WGs. (This comes up in Create lifecycle for WGs + maturity levels #13.)
• Security Tooling WG
  • Remove reference to CHARTER.md
  • This could use a bit more detail
• Security Best Practices WG
  • LGTM. Suggest filling in or removing empty sections if not needed (do we need all sections of the template filled in?)
• Identifying Security Threats WG
  • LGTM
• Securing Critical Projects WG
  • LGTM. Suggest filling in or removing empty sections if not needed (do we need all sections of the template filled in?)
  • Remove reference to empty governance info
• Developer Identity Verification WG
  • Has this WG landed on their latest proposed scope? Other than the name, this doesn't seem to have been updated recently
  • Remove reference to empty governance info

I would propose the existing README.md are sufficient for incubating WGs, which our current WGs are.
I would propose we review and collate any feedback at the next TAC, but pending anything critical that needs to be changed, approve these.

---

I would then propose we close this issue, and now track the development of a CHARTER.md governance model for the WGs. It sounds like the first step here should be reviewing the existing template (at the TAC?) and determining if there is anything we would like to change.

There is also a need to review/define the TAC charter.

[MarcinHoppe]

@mayakacz my personal preference would be to discuss the topic you mentioned in issues or on the mailing list of each individual WG. I am afraid mixing discussion for all WG in this issue would lead to a discussion that is difficult to follow.

Specifically, for the concerns you raised about the Vulnerability Disclosures WG:

Clarify that development of a new OSS vuln format only makes sense if none of the existing formats work, or we are not able to work with existing formats to develop what is needed

We currently have ossf/wg-vulnerability-disclosures#67 open that will answer if we need to put effort into development of a new format.

Clarify whether or not this WG intends to now or in the future enable direct reporting of vulnerabilities to this group for triage (my 2c: no)

No, we don't consider that and I don't see anything in the README that would indicate we have ever even entertained the idea. If you feel this is worth discussing, opening a new issue would probably be the best way to get a definitive answer.

If there is an expectation that this WG would handle that, I'd love to hear about it!

[mayakacz]

@mayakacz my personal preference would be to discuss the topic you mentioned in issues or on the mailing list of each individual WG.

Agreed, and SGTM. Maybe a feedback issue in each WG repo...

Clarify that development of a new OSS vuln format only makes sense if none of the existing formats work, or we are not able to work with existing formats to develop what is needed

We currently have ossf/wg-vulnerability-disclosures#67 open that will answer if we need to put effort into development of a new format.

SGTM.

Clarify whether or not this WG intends to now or in the future enable direct reporting of vulnerabilities to this group for triage (my 2c: no)

No, we don't consider that and I don't see anything in the README that would indicate we have ever even entertained the idea. If you feel this is worth discussing, opening a new issue would probably be the best way to get a definitive answer.

I would not expect that. That is aligned with my thinking, thanks!

[mayakacz]

Can we complete reviews of each WG's charter? How should we do that?

[mayakacz]

I think there are actually two things here:

• Reviewing the scope of each WG. I see @david-a-wheeler has opened issues for each of those
• Removing/ replacing/ simplifying the 'default' charters in each WG's repo. These currently feel overly burdensome.

[SecurityCRob]

Picking this back up so we can get this completed and closed out.

• Vuln disclosures: https://github.com/ossf/wg-vulnerability-disclosures/blob/main/CHARTER.md
  Required updates - charter community name, date approved, mission statement, link TSC to contributors - WG Charter updates wg-vulnerability-disclosures#106
• Security tooling: https://github.com/ossf/wg-security-tooling/blob/main/CHARTER.md
  Required updates - link TSC to contributors - WG Charter updates wg-security-tooling#33
• Best practices OSS developers: https://github.com/ossf/wg-best-practices-oss-developers/blob/main/CHARTER.md
  Required updates - Date approved, link TSC members to Git Contributors - WG Charter updates wg-best-practices-os-developers#57
• Identifying security threats: https://github.com/ossf/wg-identifying-security-threats/blob/main/CHARTER.md
  Required updates - charter community name, date approved, mission statement, link TSC to contributors - WG Charter updates wg-metrics-and-metadata#25
• Securing critical projects: none in https://github.com/ossf/wg-securing-critical-projects
  Required updates - create & fill our charter.md - WG Charter updates wg-securing-critical-projects#52
• Supply Chain Integrity: https://github.com/ossf/wg-supply-chain-integrity
  Required updates - create & fill our charter.md - WG Charter updates wg-supply-chain-integrity#49
• TAC: https://github.com/ossf/tac#charter
  Required updates - none at this time

[vmbrasseur]

Hey, team. While working on the Vulnerabilities Disclosures charter, @JasonKeirstead and I ended up having a number of questions.

One of the biggest ones was, "why are all of the WGs each individually defining their governance and operating models? why is there not a single such model created by the TAC? each WG then uses that but ensures that their repos include a clear statement of mission/scope and link back to the main WG charter?"

Having a single operating model for WGs is common in FOSS. Some examples of this (and charters) are at fossgovernance.org.

Is there any particular reason why all WGs are going their own direction on this rather than using a common governance from the TAC?

[SecurityCRob]

This also is being tracked in the following:
#29
#30
#31
#32
#33
#34

[SecurityCRob]

This is now being managed through #162