-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Project Lifecycle: Acceptance Criteria #39
Comments
This statement is not the jist of the discussion as I understood it. The summary should rather be "For security software projects, e.g. OQS and PQCP, in case of disagreements of acceptance assessment criteria, the more conservative interpretation assumed by either TAC or (sub) project maintainers shall rule". Should PQCA think all its (also future) projects are of this nature, feel free to simplify to
As stated elsewhere I'm concerned that corporate-interest driven, thus typically TAC-based entities (as the LF/PQCA contract gives TAC majority control to corporate PQCA sponsors), could thus "force" the external publication of falsely optimistic "project readiness" assessments thus misleading the public. This may be OK for projects purely marketing some corporate pet project put into OSS say, but IMO is not acceptable for software that people may rely on for their (also personal) security. I'd actually urge PQCA considering adopting the OpenSSL mission and values that would prohibit such things. Based on this, the by LF-contractual design corporate-controlled TAC cannot have final judgement over these criteria. Finally, as a worked example: If the TAC had "final judgement", it would allow entities not seriously contributing to a project, but controlling the TAC, to declare a low level of contribution to be sufficient for a (sub) project to be "healthy", thus putting it into a higher "lifecycle state". This would put the onus of delivery (on that false lifecycle assertion) onto the shoulders of the (sub) project maintainers and exonerate the (TAC-based) non-contributors from responsibility (to contribute or take responsibility for their false (or "optimistic") assessment criteria decision). Also here, please tag me explicitly @Naomi-Wash on any suggested resolution of this issue as I think this touches on the core reputational risks to software I feel personal responsibility for. Thanks. |
@baentsch I see you requested to be specifically tagged prior to resolution. I believe this issue was already addressed in a similar manner to issue #40. The verbiage that this comment thread originally started on is no longer in the Labs Stage acceptance criteria. In its place, just as in the Impact Stage, there is an expectation that the project includes the metrics used in justifying their proposed lifecycle stage. I plan to resolve this issue unless there’s a suggestion for further updates to the Labs Stage acceptance criteria. |
Comment moved from Project Lifecycle Document Section 3. Stages - Definitions & Expectations - Labs Stage - Acceptance Criteria
Since these metrics can vary significantly depending on a project's type, scope, and size, the TAC has final judgment over the level of activity adequate to meet these criteria.
Discussion
The text was updated successfully, but these errors were encountered: