search

PQCA / TAC

https://pqca.org
Apache License 2.0
15 stars 3 forks source link

Project Lifecycle: Annual Review Process #42

Open Naomi-Wash opened 1 month ago

Naomi-Wash commented 1 month ago

Comment moved from Project Lifecycle Document Section 4. Annual Review Process

The TAC shall develop an annual review process to determine whether projects are in the stage that accurately reflects their needs and goals.

Discussion

Not directly a comment on the doc, but validation thereof. PQCA currently has two projects.

  • OQS ~ Production/Growth? (moving towards Impact?)
  • PQCP ~ Production/Incubation ? We need to understand the lifecycle of a project overall. However within each project there may be more subtlety around parts of the project. For example oqs has some implementations of more experimental algorithms (Mayo) but others that are more stable and being adopted (Kyber/ML-KEM). Some code is aimed at production, but doesn't meet many criteria (oqs-provider). So it would seem there is a responsibility for each subproject to further clarify the lifecycle of individual components/features along similar lines

Absolutely agree on the need for correct sub project classification. Input solicited in https://github.com/open-quantum-safe/tsc/issues/2. I absolutely do not agree on your implied classification of oqs-provider (but again, this may be due to a difference in understanding of the quality criteria for "production"): What about making them explicit here and/or in the above TSC issue?

This classification would be the responsibility of the OQS TSC, not the overall TAC.

Should we add it as text to make clear the responsibility distribution between TAC and TSCs?

I think that would be at a higher level in the document, as the split between TAC and TSC is a recurring theme? TODO: Find place in text & update this comment

Explaining (and ideally, agreeing) that "split of responsibility" would make an awful lot of sense in my eyes: I only got involved in this discussion on the TAC as it seems to be the place that IBM wants to use to wield the control over the project I so consistently object against since their take-over proposal a year ago wrt OQS (basically, defending the "O" in the name): No objection against influence via technical contribution; but corporate control over a FOSS project via committees and definitions (e.g., of what is "healthy") in my eyes is "not Good" (harsher word deleted :).

baentsch commented 1 month ago

OQS ~ Production/Growth? (moving towards Impact?)

This classification proposal is too optimistic and would raise wrong expectations by users if published as such.

This is to urge PQCA to act responsibly and carefully wrt this classification: Particularly OQS and PQCP are security software. Under no circumstances should PQCA entities overly "optimistic" or controlled by marketing-oriented people following their corporate agenda(s) be allowed to set externally visible "lifecycle" expectations contradicting the positions of responsible (also sub project) maintainers of such software, if they see things more conservatively.

Also here, please tag me explicitly as/if progress is made: I have not subscribed to this project and otherwise probably would not get notified as my preference is to only work on technical GH issues. In this case, though (the resolution of) this issue is one that can have impact on my personal reputation (e.g., if I don't withdraw visibly and quickly enough from projects that PQCA markets too aggressively).