One point of confusion that seemed to come up is around what the two working groups in question plan to do, and what they would like to do with the CII Badging program. Would it make sense to wait until the WGs get formalized in https://github.com/ossf/tac/issues/13? I think knowing the intended scope of both of these groups would probably help in determining where this would make the most sense.

If it turns out there is significant scope overlap, maybe we should consider combining the two groups.

From a quick glance at the existing Objectives, it looks to me like the Best Practices group makes the most sense:

 

Our objective is to provide open source developers with best practices recommendations, and with an easy way to learn and apply them.

vs.

 

Our objective is to enable stakeholders to have informed confidence in the security of open source projects. At the macro level, this includes identifying threats to the open source ecosystem and recommending practical mitigations. At the micro level, we will identify a set of key metrics and build tooling (API, web UI) to communicate those metrics to stakeholders, enabling those stakeholders to better understand the security posture of individual open source components

But I think there's significant wiggle room in both of these, so either one could really make sense. Ideally we'd get these clarified and extended with the other information in https://github.com/ossf/project-template/pull/1 before deciding on this.

Dan Lorenc 

On Mon, Sep 28, 2020 at 1:48 PM David Wheeler <dwheeler@...> wrote:

This morning the OpenSSF Best Practices WG and Security Threats WG each voted that the CII Best Practices badge project should move into their respective WGs. I think there was general agreement that the badge project should have just one “official” place (to minimize confusion).

It’s good that CII Badge Projects is wanted! And I think this result confirms that there’s a general desire to move it into the OpenSSF. That said, there’s conflict that needs resolution.

SO:

I propose that the TAC decide which OpenSSF WG ends up with the CII Best Practices badge. The Security Threats WG will write a few sentences arguing their case, and I think someone in the Best Practices WG should do the same. I further propose that this decision at least be an agenda item for the OpenSSF TAC meeting on Oct 6; the TAC could then decide to vote immediately, or kick off an electronic voting process to give people time to think.

No matter what the outcome, I think the CII Best Practices badge work will need to work with both working groups, as it can (and should!) support both WGs.

— David A. Wheeler

i'm not sure we really reached a concrete plan here in the last TAC meeting. Does anyone have any feedback on my suggestions above? I want to make sure we unblock the decisions and give the WGs and the Badging program a clear path forward.

Dan Lorenc

On Mon, Sep 28, 2020 at 4:16 PM Dan Lorenc via lists.openssf.org <dlorenc=google.com@...> wrote:

One point of confusion that seemed to come up is around what the two working groups in question plan to do, and what they would like to do with the CII Badging program. Would it make sense to wait until the WGs get formalized in https://github.com/ossf/tac/issues/13??? I think knowing the intended scope of both of these groups would probably help in determining where this would make the most sense.

If it turns out there is significant scope overlap, maybe we should consider combining the two groups.

From a quick glance at the existing Objectives, it looks to me like the Best Practices group makes the most sense:

 

Our objective is to provide open source developers with best practices recommendations, and with an easy way to learn and apply them.

vs.

 

Our objective is to enable stakeholders to have informed confidence in the security of open source projects. At the macro level, this includes identifying threats to the open source ecosystem and recommending practical mitigations. At the micro level, we will identify a set of key metrics and build tooling (API, web UI) to communicate those metrics to stakeholders, enabling those stakeholders to better understand the security posture of individual open source components

But I think there's significant wiggle room in both of these, so either one could really make sense. Ideally we'd get these clarified and extended with the other information in https://github.com/ossf/project-template/pull/1 before deciding on this.

Dan Lorenc 

On Mon, Sep 28, 2020 at 1:48 PM David Wheeler <dwheeler@...> wrote:

This morning the OpenSSF Best Practices WG and Security Threats WG each voted that the CII Best Practices badge project should move into their respective WGs. I think there was general agreement that the badge project should have just one “official” place (to minimize confusion).

It’s good that CII Badge Projects is wanted! And I think this result confirms that there’s a general desire to move it into the OpenSSF. That said, there’s conflict that needs resolution.

SO:

I propose that the TAC decide which OpenSSF WG ends up with the CII Best Practices badge. The Security Threats WG will write a few sentences arguing their case, and I think someone in the Best Practices WG should do the same. I further propose that this decision at least be an agenda item for the OpenSSF TAC meeting on Oct 6; the TAC could then decide to vote immediately, or kick off an electronic voting process to give people time to think.

No matter what the outcome, I think the CII Best Practices badge work will need to work with both working groups, as it can (and should!) support both WGs.

— David A. Wheeler