search

PQCA / TAC

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

Project Lifecycle: Research Projects and Production Projects #37

Open Naomi-Wash opened 3 months ago

Naomi-Wash commented 3 months ago

Comment moved from Project Lifecycle Document Section 3. Stages - Definitions & Expectations

All projects may attend TAC meetings and contribute work regardless of their stage. Projects are divided into “Research Projects” and “Production Projects.”

Discussion

This separation makes no sense for OQS as it is set up now: As discussed in https://github.com/open-quantum-safe/tsc/issues/1 it bears properties of both Research and Production -- so which track as per this definition shall it be in?

I'd recommend OQS be a "production track" project. If a project has any subprojects that are focused on production-ready code, they should be a production track project. We of course expect production projects to have experimental code, but the "research" designation is for projects that don't plan on ever moving anything to production. It's a way to tell users "don't use this or expect to use this in the real world".

OK, then I understand better what you mean by "production track": It's not a quality-driven designation but a usage-driven one, right? Is this understanding explicitly documented somewhere? For "usual" software (where the usual "break-and-fix-quickly" approach holds) this seems OK, but is it advisable for security software? Shouldn't there be some more seriously checked quality/reliability criteria agreed for things like OQS or PQCP? Also see the "security discussion" below...

Yes, you're exactly right: it's a usage-driven definition. We have the stages within the tracks to document maturity.

It seems as if one of the requirements for a production project is that they have a responsibility to clearly articulate the status of parts of their project. There may be unsupported/tech preview type functionality in some of their subprojects(repo), or even down to library, method. That is inevitable as those projects continue to develop, but a user of the project needs to be informed - ie they trust the project as a whole. This may also extend to build and/or runtime options (as oqs has in part) to only use functionality at a certain level

That's exactly right Nigel!

Satisfied and no objections with the proposed structure.

maximilien commented 1 month ago

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