Project Lifecycle: Annual Review Process

[Naomi-Wash]

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]

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).

[planetf1]

The lifecycle document talks about providing two examples of growth/production, and uses terms like 'production usefulness'

I don't think the definition is very tight, and that the way forward is for projects - particularly the more mature ones (ie liboqs) to make a statement they are comfortable with about what this means -- and indeed there's been some discussion in the community.

Transparency over the characteristics of the code/docs/testing are a large part of this so that any consumer can review and make their own decision as to whether that means they can use in production.

It also implies some responsibility within the liboqs community to critically assess where they are, and figure out sensible ways forward to improve (as the community has discussed, and is very aware of some of the things they'd like to do). Ideally any high line items would feature in a roadmap, again providing insight to consumers.

I think that's in the spirit of the lifecycle categorization - words like 'production' and 'support' need to be treated carefully and we need to be clear it's the consumer's responsibility to assess.

It might be interesting to review what other subprojects state - particularly smaller communities with great ideas but limited resources!

[maximilien]

I believe this is solved in other issues. Let me suggest that we proactively close this issue by the next TAC meeting (Oct.9th) unless I hear otherwise..

[baentsch]

we need to be clear it's the consumer's responsibility to assess.

Can you please point to the section in the document making this clear? Doesn't this statement void the whole point and purpose of the lifecycle document giving users guidance as to the quality of the software?

we proactively close this issue

Can you please explain what this practically means? Do you expect (further?) input or will you just close it?