Create project_proposal.yml

[riaankleinhans]

The LF process for excepting projects are:

• a project is created if LFX/PCC under the correct Project (OpenSSF) and WG (If applicable)
• The formation team then create the project formation documentation, including the draft charter and contributor agreement (if applicable)
• The project update / except and return to the LF formation team, whereafter the project get activated in PCC.

The template contain the required fields and drop down menus for filling out the project information in PCC.

The proposed internal OpenSSF project expectance process:

• The project create a project proposal issue.
• The project get the opportunity to present their work to the TAC. (In a TAC meeting)
• TAC members and meeting attendees can ask question to the project team, either in the meeting or via the issue
• Once the TAC feel sufficient information was gathered to vote on the expectance of the project a vote is called on the issue vir Gitvote.
• Once the vote pass the Project is created in PCC by the LF Technical Program Manager.
• The PMO and Formation team work with the project to complete the process.

[mlieberman85]

What is this trying to solve over the current PR based process?

[SecurityCRob]

I like better automating, templating, and documenting our process. This also allows us to plug more into the LF tools/infrastructure to get better reporting and visibility.

[steiza]

Like @mlieberman85, I want to hear more about the why / what this enables before we talk about how it should be implemented.

There are definitely some confusing things today about TAC processes. Funding requests are done via issues, whereas TI lifecycle stages are done via PRs and TI reports are also done via PRs.

Ideally, things would be done in a single way. This PR moves TI lifecycle stages (at least for creating a new project) to using issues instead of PRs. I think the TAC should align on if that's the direction we want to go in first. And if so, I think we should move all of TI lifecycle management over to issues, otherwise this splits it between issues and PRs, which would make things worse than it is today (in my opinion).

---

On a separate topic, I have mixed feelings on git-vote. Where does git-vote's configuration live? Is it publicly visible? Officially, our funding process docs says we have a week to evaluate submissions, but it seems like git-vote is configured for ~40 days? Before we were using git-vote, people wrote comments not just giving their vote but explaining their position, which we're now missing with the 👍 emoji.

I'm not sure I want to move in a direction of using git-vote more.

[marcelamelara]

I share reservations about switching away from PR-based processes. I have personally come to prefer PRs over issues for TAC processes, mainly because the PR UI supports a lot of reviewing capabilities natively.

For example, if I have a comment on a particular section of a lifecycle application or TI update, the PR review UI directly associates my comment with the relevant line(s) in the text, and one can create a longer discussion thread on that particular section of the doc. Doing reviews via issues, on the other hand, requires manual quoting of text, which is fine for small comments, but longer discussions with many comments quickly become pretty hard to read and follow. Approvals are also more easily tracked in a single place in the UI.

The other big advantage I see in using PRs is that a doc can be merged directly into the repo, rather than having to do the two-step process of reviewing an issue, and then separately opening a PR, making sure it aligns with the issue, and then merging the doc in question.

The current process doesn't really preclude an online discussion and vote at the TAC meeting. If the main goal is better integration with LF tooling for project tracking and the like, is there a way to achieve that through automation for PRs?

[marcelamelara]

Ideally, things would be done in a single way. This PR moves TI lifecycle stages (at least for creating a new project) to using issues instead of PRs. I think the TAC should align on if that's the direction we want to go in first. And if so, I think we should move all of TI lifecycle management over to issues, otherwise this splits it between issues and PRs, which would make things worse than it is today (in my opinion).

I 100% agree with @steiza 's sentiment here. We should seek to align on a single way of doing things, and in this vein, I've been thinking recently that the TI funding request reviews should be done via PRs. (This is a separate discussion for #419)

[lehors]

@marcelamelara basically said it all. I agree we should consolidate but towards PRs NOT issues for the very reason Marcela mentioned:

The other big advantage I see in using PRs is that a doc can be merged directly into the repo, rather than having to do the two-step process of reviewing an issue, and then separately opening a PR, making sure it aligns with the issue, and then merging the doc in question.

For that matter, our process already states how new WGs and projects should be proposed. Proposing a new WG should be done following the WG lifecycle by submitting a PR with the appropriate template to add the WG in sandbox or incubating stage. See Working Group creation or change of lifecycle stage. We have a similar process for projects: Project creation or change of lifecycle stage

[sevansdell]

• versus creating this PR for a new issue, I recommend you close this PR, and do the following instead:
  -- propose adjusting the current PR templates for new projects to include the verbiage you need for getting the project properly uploaded into LFX.
  --The documentation for the external LFX/internal staff process steps (currently in the first comment should be in a proposed PR change to https://github.com/ossf/tac/blob/main/process/project-lifecycle.md.

[marcelamelara]

Thank you for clarifying the need for this PR at the 12/10/24 TAC meeting @riaankleinhans ! With that in mind, I recommend changing any references in the text to "Proposed project" to something like "Approved project registration" or "Approved project onboarding" to make it clearer that this a post-TAC approval process. I also agree with the suggestion someone else made that the link to the Project proposal PR be included in this form.

[steiza]

Huge +1 to @marcelamelara's comments above. I think we can drastically simplify this form by asking for a link to the project lifecycle doc, and using that to replace the request for project name, description, mission statement, category, parent working group, website, and repository.

The technology sector question is a bit strange - I understand where it's coming from in terms of the LF wanting to collect demographic information, but I'd be surprised if we had many visual effects projects in the OpenSSF?

The industry sector is even weirder - as far as I know all of our projects are cross industry? Again, I understand why the LF is interested in this demographic data, but I'm not sure how much sense this makes for OpenSSF projects specifically.

I think the rest of the questions (technical activity type, expected announcement date, and primary license) make sense.

[riaankleinhans]

Thank you for all the positive feedback.
Updating this is on my radar for this week.

[riaankleinhans]

CRAZY last week of the year.
Will have to stand over for 2025. ☺️