Introduce OSPP (Open Source Promotion Plan)

[RuoqingHe]

Summary of the PR

• Create folder for OSPP (Open Source Promotion Plan), and guidelines for participating OSPP.
• Create OSPP-2025.md file to track accepted projects for OSPP 2025 from RustVMM community.

Requirements

Before submitting your PR, please make sure you addressed the following
requirements:

• All commits in this PR have Signed-Off-By trailers (with
  git commit -s), and the commit message has max 60 characters for the
  summary and max 75 characters for each description line.
• All added/changed functionality has a corresponding unit/integration
  test.
• All added/changed public-facing functionality has entries in the "Upcoming
  Release" section of CHANGELOG.md (if no such section exists, please create one).
• Any newly added unsafe code is properly documented.

[stefano-garzarella]

Just little changes since we use rust-vmm to identify our community and project.

[stefano-garzarella]

As I mentioned, I can be the community contact but I'd open another PR so we can agree on that.

[roypat]

I wonder if it would suffice to track these in issues? You could convert the README into a "master issue" and then add individual projects as sub-issues (using the new github feature). Then status (accepted, under discussion, etc) can be tracked via labels?

[RuoqingHe]

I wonder if it would suffice to track these in issues? You could convert the README into a "master issue" and then add individual projects as sub-issues (using the new github feature). Then status (accepted, under discussion, etc) can be tracked via labels?

IMO using PRs for reviewing proposals, suggest changes would be easier and more compact. In that case we can just use the final OSPP-<year>.md file for submission, and the status of each proposals are simply annotated by merged or closed. And we can also lable PRs 🙂

[stefano-garzarella]

I wonder if it would suffice to track these in issues? You could convert the README into a "master issue" and then add individual projects as sub-issues (using the new github feature). Then status (accepted, under discussion, etc) can be tracked via labels?

IMO using PRs for reviewing proposals, suggest changes would be easier and more compact. In that case we can just use the final OSPP-<year>.md file for submission, and the status of each proposals are simply annotated by merged or closed. And we can also lable PRs 🙂

I like @roypat idea with issues, because it will be easy to track progress, etc. but I also agree with @RuoqingHe about reviewing PRs proposals and especially accepting them if as a community we agree it makes sense, since we have a limit of 5 projects (although I think we won't reach the limit this first year).

So I don't have a strong preference, I like both ideas, up to you!