Versions Compared

Old Version 7

changes.mady.by.user Unknown User (sctemme)

Saved on

compared with

New Version 8

changes.mady.by.user Unknown User (rgardler)

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Make sure our users know what they should be doing to find out about updates, EOL, CVEs
  • Consider if projects that are not releasing regularly are really healthy.  Could they realistically respond to a security vulnerability in a reasonable time frame?
  • Have a better EOL policy with defined communication routes, policy for CVE in EOL releases.
  • Look again into SCR:CLR as a service to projects
  • Look at 2FA for Apache
  • Make sure we upgrade our CNA CVE process to JSON 5.0 to make use of the additional record data
  • Get involved with various OpenSSF initiatives
    • Is the training something we should promote to committers
    • How can we make the scorecard better for ASF projects
    • How can we make the critical projects list better for ASF projects
    • How does Alpha and/or Omega fit with ASF
    • Would sigstore be a future replacement for current signing policies
    • Look at SLSA/SBOM work
  • Minimize situations in which PMCs refuse contributions for anything other than strong technical reasons
    • Forking increases the attack area and complexity of fixes - projects should be governed such that the need to fork when using the code is minimized
    • Stop Either stop accepting forks as a necessary and acceptable outcome of PMC control OR focus on enabling of ASF projects - users cannot be expected to invest in a community if the gates to the PMC are closed
    • Focus on education such that PMCs can enable "constructive forking" in a controlled manner in which such that the forking community are welcomed and can continue to contribute to the core projectsupported in improving a projects architecture to minimize the need to fork
    • Educate ASF projects that the way to a healthy community is through the production of reusable components that enable ASF projects should consist of components for reuse and should accept contributions designed to enhance that reuse in broader contexts so as to allow the pool of contributors to growASF Projects should be encouraged to build modular solutions to enable more reuse of components in broader contexts while still enabling pluggable features for specific use cases
    • Re-Affirm that ASF Projects are successful when the broadest possible community is optimized, not when the primary employer of PMC members is successful - this success leads to further success in the primary employer should one existengaged leading to more maintainers and more eyeballs on the shared code
  • Consider annual re-affirmation by PMCs towards Apache Way, with reminders of What It Is.
  • Consider ASF Blog Post: "How You Can Help" directed towards corporate users.
  • should have more complete policy around production of "builds" https://www.apache.org/legal/release-policy.html#compiled-packages
  • Spend Foundation resources (money) on creating messaging for community members, e.g.
    • Popularizing, re-affirming The Apache Way
    • Messaging to evangelize a "give back" culture among consumers
    • Presentations for community members to share with Colleagues on how to give back, how to handle Open Source contributions
    • Language for corporate lawyers to facilitate contributions by developers in their organization, what it means when a developer signs an ICLA (or is hired already having one on file), etc.