| Re: [eclipse.org-architecture-council] Eclipse Foundation Development Process 2023 Update |
I recommend that if vulnerabilities are something that are driving this request that you be specific about that in the updates to the text of the EDP. First, this makes at least one of your intentions clear. Second, it communicates a concern to PLs and committers in such a way as to establish high priority.
The draft does explicitly state that the vulnerability reporting policy is one of the triggers for the EMO to unleash these special powers: "This includes, but is not limited to, issues that arise due to a failure to implement the Eclipse Foundation Vulnerability Reporting Policy, the Eclipse Foundation Intellectual Property Policy, the Eclipse Foundation Community Code of Conduct, or other governance policies of the Eclipse Foundation."
I generally try to avoid being too specific in the process document to give us room to adapt to new things. That is, I try to focus on the principle. I purposefully try to keep it open so that we could have the ability to step in in other cases when doing so makes sense. This is why I added the disclosure requirement and reminder that members have the ability to call us out on misuse via the grievance handling process.
I would like to add my voice here to agree with Wayne. We just had exactly the same conversation in the Board meeting this week on this point. Although the main current rationale is vulnerability reporting, it cannot be restricted to that alone. As hypothetical scenarios, if there was a project that was consistently and flagrantly violating the Code of Conduct (e.g. imagine repeated misogynistic or homophobic discussions on the mailing list) or the antitrust policy (e.g. imagine discussing and fixing downstream product pricing) the EMO will want tools to intercede.
HTH
Mike Milinkovich
Executive Director Eclipse Foundation AISBL