Revert "Revert "refactor: move xmodule folder to root""

xmodule/docs/decisions/0001-move-due-dates-to-db.rst

@@ -0,0 +1,60 @@
+1. Move Due Dates to Relational Database
+----------------------------------------
+
+Status
+------
+
+Accepted
+
+Context
+-------
+
+We want an authoritative and readily-accessible place to track due dates for sections/units in a course.  We also want to override due dates per learner, and record the reason for the override. The current implementation stores due dates in the XBlock (in mongodb). If you want to know all of the due dates in a course, you have to walk the entire course structure and pull out each date, which is an inefficient operation.
+
+There is currently a way to override due dates per learner, using `IDDE <https://github.com/mitodl/ccx-idde-overrides-slides/blob/master/markdown/slides.md#individual-due-date-extensions-idde>`_, but this relies on a generic field-override system which doesn't know anything about the underlying data, and enabling this feature results in a database query for every xblock access, for every course on the platform. IDDE also does not allow for an audit trail on due date extensions, nor does it allow instructors to record a reason for the extension. 
+
+
+Decisions
+---------
+
+1. Create a new pluggable Django app responsible for dates and date overrides
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+This approach anticipates other date-related functions in the future, such as APIs for returning a calendar view of upcoming dates.
+
+- The app will contain at least these models:
+    + ``DatePolicy``: contains course_key, absolute date and a time delta
+    + ``ContentDate``: contains DatePolicy id and content id + field
+    + ``UserDate``: contains user id, DatePolicy id, and absolute date + relative date. It will also record an audit trail for the override.
+- The app will hook in to the ``LmsModuleSystem`` with a custom ``FieldData`` implementation.
+    + If the date exists in the relational database (whether in UserDate or ContentDate), it'll use that date; otherwise, it'll use the one stored in the XBlock.
+- The app will expose a REST API for retrieving and updating dates in the database.
+
+2. Create an instructor interface for setting student due dates
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The existing IDDE instructor interface may be used, or a modern micro-frontend can be included from the new pluggable Django app.
+
+3. All dates for a course/learner will be retrieved using one query, cached for the current request.
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+It's important that the underlying implementation can efficiently retrieve all due dates for the course, otherwise it's not an improvement over IDDE.
+
+For instance, to retrieve all dates for a given user and course
+
+::
+
+    select cd.location, datep.date, datep.delta, ud.date, ud.delta
+    from content_date cd
+    left join date_policy datep on datep.id = cd.policy_id
+    left join user_date ud on ud.policy_id = datep.id
+    order by cd.location, ud.date, ud.delta
+    where datep.course_key = "course_key"
+    and ud.user_id = 1234
+
+
+4. Dates will be copied to the relational database when the course is published.
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The app will listen for the ``SignalHandler.course_published`` signal in Studio and will create/modify ``DatePolicies`` and ``ContentDates`` as required.
+

xmodule/docs/decisions/0002-remove-mongodb-dependency.rst

@@ -0,0 +1,28 @@
+Remove MongoDB as a Dependency
+------------------------------
+
+Context
+=======
+
+The edx-platform repo uses MongoDB for storing content (the ModuleStore and ContentStore interfaces). MongoDB was chosen early on in the Open edX project because:
+
+* **Course content is very freeform**, and XBlock is a pluggable interface. So while the data stored for videos, problems, crystallography simulations, and circuit schematic editors might have some overlap, individual XBlock are permitted to extend that storage any way they like. At the time, this struck us as a more document-database-centric than SQL.
+* **MongoDB’s GridFS** seemed liked a good solution for the static assets that need to be managed on a per-course basis (e.g. PDFs).
+* **MySQL at the time did not support JSON fields.** This would have made certain search operations more cumbersome. (MySQL itself was chosen because PostgreSQL was not available on RDS at the time).
+
+Since that time, several things have changed:
+
+#. We've been trying to reduce the complexity of the stack needed to run Open edX.
+#. We've switched over from the original ``DraftModuleStore`` to ``DraftVersioningModuleStore``. The latter drops most query patterns and mostly uses MongoDB as a simple key value store.
+#. We've adopted django-storages for pluggable file/blob storage.
+
+Decisions
+=========
+
+All usage of MongoDB in edx-platform will be removed or replaced in the following ways:
+
+* Old Mongo (``DraftModuleStore``) will be removed as a storage backend altogether. This is already covered under DEPR-58, and affects only old style courses with course keys in the "Org/Course/Run" format (as opposed to the "course-v1:Org+Course+Run" format).
+* ContentStore storage of course static assets will be moved to django-storages, allowing for pluggable backends (e.g. files, S3, GridFS).
+* Split Modulestore (``DraftVersioningModuleStore``) will be moved to use the Django ORM for the active version lookup, and django-storages to replace key-value storage of what are structure and definition documents today.
+
+Note that this does not include the use of MongoDB for the forums experience. While I still believe that removing MongoDB for that service is desirable, it's beyond the scope of this particular ADR.