Develop annual review process for projects

[eemeli]

While working on #591, I noticed this bit at the bottom of PROJECT_PROGRESSION.md:

IV. Annual Review Process
The CPC shall develop an annual review process to determine whether projects are in the stage that accurately reflects their needs and goals.

This is particularly relevant for Growth projects, as "A [Growth] project's progress toward its growth plan goals will be reviewed on a yearly basis, and the CPC may ask the project to move to the At Large stage if progress on the plan drops off or stalls." Also, "Projects in the Growth Stage are generally expected to move out of the Growth stage within two years."

We currently have seven Growth projects, six of which have been at that stage since the foundation's foundation:

• architect
• Intern
• Mocha
• Node-Red
• WebdriverIO
• webhint

To be honest, I'm not sure I've seen the growth plans for these projects. I presume those should at least exist, and hopefully be linked-to from somewhere?

[tobie]

Is there a definition of what a growth plan is supposed to look like?

When would that growth plan be requested? As part of onboarding?

[tobie]

Following the conversation during the call, I'd like to clarify my suggestion here for Growth projects:

• We create a new repo called growth-projects (or similar name) structured just like project-onboarding.
• We turn the acceptance criteria of Impact and Growth stage into a single checklist like the onboarding checklist.
• Each project at the Growth stage has an open issue in that repo that includes the checklist.
• When the project has completed that checklist it files a PR with the CPC to change its status.
• The CPC votes on it/approves it.
• At regular intervals (yearly? quarterly?) the CPC checks-in with the project and asks for a status update.
• Growth projects possibly get assigned a champion.

Projects are free to have their own plan as to how to meet those requirements, like they are for onboarding, but the issue is the "source of truth."

[eemeli]

I think one important question to address early on was raised by @jorydotcom at last week's meeting, when this was first brought up: Should the Growth stage continue to be explicitly meant "for projects that are interested in reaching the Impact Stage, and have identified a growth plan for doing so", or should it also be available for projects that are undergoing some other form of growth? Given that we have existing text that's pretty clear on this, I think any change would need an active champion for pushing it forward.

@tobie Regarding the checklists, that sounds like an excellent idea. But why do we need a new repo for it? Couldn't we just rename project-onboarding as e.g. project-status and add them there?

Looking at said repo, I get the sense that a review would be well placed for most of the at-large projects as well, which haven't necessarily advanced all that much in their initial onboarding.

[tobie]

Couldn't we just rename project-onboarding as e.g. project-status and add them there?

That sounds like an excellent idea.

[christian-bromann]

Speaking about project status: I feel like it would make sense maybe to finish the onboarding efforts of these projects before continuing going to the next stage 🤔

[boneskull]

Regarding Mocha:

When Mocha chose the "growth" stage, we did so with the understanding that a) we'd have some sort of conversation about project growth with the CPC--which explicitly would involve setting growth goals--and b) the "growth" stage is not supposed to be permanent.

I've been sitting on a) while I understood onboarding--and developing the onboarding process--to still be taking place (as @christian-bromann mentions). I would expect a conversation with the CPC where together we:

1. identify growth goals
2. set a timeline
3. barring "renegotiation", meeting the goals would move the project into the "impact" stage

To be clear, these goals are not "grow your project by hitting goal x", but rather "goal x is required and sufficient to move into the impact stage".

I'm happy to discuss goal-setting whenever the CPC feels it has the bandwidth to do so.

---

Otherwise...

• The "two years" language might want reconsideration/omission; since the growth plan would be custom-fit for each project, I don't see why the timeline can't be, as well. Also... we really have no idea how long this will take, right?
• If we have projects that have been with us from day 1 that are not completely onboarded, we should prioritize that where possible.
• If the onboarding bottleneck is on the project side, and we're just waiting for them to get their shiz together:
  • We should not block on working with growth-stage projects while we wait.
  • We should set deadlines and consider appropriate next steps if the deadlines are not met.
• Once original-project onboarding is complete, we need to mind growth-stage projects. If we don't tend to these projects, we just end up "collecting" projects and letting them languish... sound familiar?

[tobie]

To be clear, these goals are not "grow your project by hitting goal x", but rather "goal x is required and sufficient to move into the impact stage".

Oh wow, I hadn't understood this like this at all.

Huge +1 to all of your other comments.

[boneskull]

Growth projects possibly get assigned a champion.

Just wanted to riff on this a bit:

• All growth and incubation projects should have an assigned champion or mentor (from the CPC?), and this role should be well-defined.

• We need to answer: how much time per week/month should this individual spend with the project lead(s), how that time should be spent, and how to make the work transparent (record in a log somewhere?), etc.

• If this individual has the expertise to mentor a project, that's a plus--but if not, the individual should function as an advocate for the project to the CPC.

[boneskull]

@rginn linked this https://chaoss.community/

[boneskull]

and @SaraJo linked https://github.com/chaoss/wg-evolution

[boneskull]

going to split this into multiple issues

[joesepi]

There's a doodle out to arrange a meeting to work on this effort.

[tobie]

Meetings scheduled. LMK if you want an invite.

[boneskull]

I seem to have missed the doodle... I would like an invite regardless.

[timmywil]

Just want to note that I second the omission of the "two year" language.

[brianleroux]

can I get an invite too pls?

[tobie]

Update: we had two meetings about this where we did a lot of blue ocean thinking. See meeting notes.

We ended-up with 2 concrete next steps:

• Renaming the project-onboarding repo to project-status (done, see Rename project-onboarding repo to project-status #641).
• Creating a pull request to help Growth projects build a roadmap to progress towards Impact stage (in progress, see Adds Growth plan template project-status#56).

During the CPC call, today, it was decided to do two work-sessions on this topic in the next two CPC meetings. If you're interested in this topic, you should join those work sessions. There aren't any other dedicated meetings planned fo now.

[jorydotcom]

RM'd the agenda label for this, and adding the blocked label as what we do with growth review will certainly depend on how we choose to proceed with the other Growth related issues. See #676 for the broader review process.

[eemeli]

Unblocking and re-raising for the CPC agenda, as the growth plan was added in openjs-foundation/project-status#56.

Note that we also have open issues #676 and #677 which have been split off from this one, but we should review the topic in general.

[joesepi]

Closing in favor of reevaluating what a 360 review process could look like in this new issue:
#982