Opening this to document the criteria for a beta release. Once we reach a beta we want a stable API as much as possible, and should avoid schema changes (or provide upgrade paths for them if possible).
Per 📌 [meta] Ecosystem modules Active the plan is for the LMS project to provide only the central building blocks for an LMS, with a pool of ecosystem modules for additional functionality.
There are various Opigno modules we have no intention to port at all, because they can be implemented via well supported general-purpose contrib modules and/or config.
This means the goal of the LMS project + ecosystem modules is only to provide functionality that is LMS-specific (course and lesson creation, progress, scoring, activity types).
Eventually it might be nice to provide an LMS recipe that brings together LMS + ecosystem + other modules and recipes to provide more of an out of the box experience, but that can and should only be done when there's a core API and features to build from.
📌 Add additional activity types Active - it would be good to add 'slide' and probably one of the more complex ones like H5P. We can add further activity types during beta though.
Should also decide what we want to do about notifications.
We should make a decision on these and get them closed either way prior to beta:
📌
Consider saving mandatory setting in lesson status
Active
📌
Consider removing LessonStatusAccessControlHandler
Active
🐛
Clarify published status on activities
Active
📌
Implement answer access
Active
📌
Clean up evaluatedOnSave() vs needsManualEvaluation
Active
Active
1.0
Other
Removed 📌 Implement answer access Active , currently answer entity doesn't need any access checks so if we ever implement additional UI, such access checks can be implemented without breaking BC.
I think we're ready for beta. I'll release a new alpha being a beta candidate and let it sit there for a week or 2.
Automatically closed - issue fixed for 2 weeks with no activity.