Merge pull request #1853 from edx/db/update-comments

Updating comments and docs for MITx -> edX transition

docs/developers/Makefile

@@ -88,17 +88,17 @@ qthelp:
 	@echo
 	@echo "Build finished; now you can run "qcollectiongenerator" with the" \
 	      ".qhcp project file in $(BUILDDIR)/qthelp, like this:"
-	@echo "# qcollectiongenerator $(BUILDDIR)/qthelp/MITx.qhcp"
+	@echo "# qcollectiongenerator $(BUILDDIR)/qthelp/edX.qhcp"
 	@echo "To view the help file:"
-	@echo "# assistant -collectionFile $(BUILDDIR)/qthelp/MITx.qhc"
+	@echo "# assistant -collectionFile $(BUILDDIR)/qthelp/edX.qhc"
 
 devhelp:
 	$(SPHINXBUILD) -b devhelp $(ALLSPHINXOPTS) $(BUILDDIR)/devhelp
 	@echo
 	@echo "Build finished."
 	@echo "To view the help file:"
-	@echo "# mkdir -p $$HOME/.local/share/devhelp/MITx"
-	@echo "# ln -s $(BUILDDIR)/devhelp $$HOME/.local/share/devhelp/MITx"
+	@echo "# mkdir -p $$HOME/.local/share/devhelp/edX"
+	@echo "# ln -s $(BUILDDIR)/devhelp $$HOME/.local/share/devhelp/edX"
 	@echo "# devhelp"
 
 epub:

docs/internal/development.md

@@ -97,9 +97,9 @@ Instead, hit /migrate/modules to see a list of all modules loaded, and click on
 github (or other equivalent git-based repository systems) used for
 course content can be setup to trigger an automatic reload when changes are pushed.  Here is how:
 
-1. Each content directory in mitx_all/data should be a clone of a git repo
+1. Each content directory in edx_all/data should be a clone of a git repo
 
-2. The user running the mitx gunicorn process should have its ssh key registered with the git repo
+2. The user running the edx gunicorn process should have its ssh key registered with the git repo
 
 3. The list settings.ALLOWED_GITRELOAD_IPS should contain the IP address of the git repo originating the gitreload request.
     By default, this list is ['207.97.227.253', '50.57.128.197', '108.171.174.178'] (the github IPs).
@@ -109,9 +109,9 @@ course content can be setup to trigger an automatic reload when changes are push
 
    { "repository" : { "name" : reload_dir }
 
-    where reload_dir is the directory name of the content to reload (ie mitx_all/data/reload_dir should exist)
+    where reload_dir is the directory name of the content to reload (ie edx_all/data/reload_dir should exist)
 
-    The mitx server will then do "git reset --hard HEAD; git clean -f -d; git pull origin" in that directory.  After the pull,
+    The edx server will then do "git reset --hard HEAD; git clean -f -d; git pull origin" in that directory.  After the pull,
     it will reload the modulestore for that course.
 
 Note that the gitreload-based workflow is not meant for deployments on AWS (or elsewhere) which use collectstatic, since collectstatic is not run by a gitreload event.

docs/internal/overview.md

@@ -101,8 +101,6 @@ The LMS is a django site, with root in `lms/`.  It runs in many different enviro
 
   - ajax calls go to `module_render.py:handle_xblock_callback()`, which passes it to one of the `XBlock`s handler functions
 
-  - [This diagram](https://github.com/MITx/mitx/wiki/MITx-Architecture) visually shows how the clients communicate with problems + modules.
-
 - See `lms/urls.py` for the wirings of urls to views.
 
 - Tracking: there is support for basic tracking of client-side events in `lms/djangoapps/track`.

docs/internal/remote_gradebook.md

@@ -2,7 +2,7 @@ Grades can be pushed to a remote gradebook, and course enrollment membership can
 
 1. Definitions
 
-An "xserver" is a web-based server that is part of the MITx eco system.  There are a number of "xserver" programs, including one which does python code grading, an xqueue server, and graders for other coding languages.
+An "xserver" is a web-based server that is part of the edX ecosystem.  There are a number of "xserver" programs, including one which does python code grading, an xqueue server, and graders for other coding languages.
 
 "Stellar" is the MIT on-campus gradebook system.
 
@@ -14,10 +14,10 @@ The remote gradebook xserver should be specified in the lms.envs configuration u
 
 Each course, in addition, should define the name of the gradebook being used.  A class "section" may also be specified.  This goes in the policy.json file, eg:
 
-    "remote_gradebook": {                                                                                                          
-       "name" : "STELLAR:/project/mitxdemosite",                                                                                  
-       "section" : "r01"                                                                                                          
-        },     
+    "remote_gradebook": {
+       "name" : "STELLAR:/project/edxdemosite",
+       "section" : "r01"
+        },
 
 3. The API for the remote gradebook xserver is an almost RESTful service model, which only employs POSTs, to the xserver url, with form data for the fields: