This proposal is being created as part of 

...

1. Update the README.rst file in the repository to state that it is deprecated and that the repository may depend on out-of-date libraries with security issues.
2. If the repository has a openedx.yaml file, add "obsolete:True" to that file.
3. Transfer ownership of the repository to edx-deprecated. See How To Transfer a Github Repo From a Personal Account to edX for an idea of what these steps may look like; a dedicated How-to will be created for the process once this proposal is approved.
4. Send an email to edx-code@googlegroups.com notifying the openedx community about the change.
5. If transferring a repository to edx-deprecated does not automatically cause Gemnasium to stop reporting on it, create a Devops ticket for this additional piece of work.

...

1. Update the README.rst file in the repository to state that it is deprecated and that the repository may depend on out-of-date libraries with security issues.
2. Add "obsolete: True" to openedx.yaml (creating the file if necessary).
3. Send an email to edx-code@googlegroups.com notifying the openedx community about the change.
4. Create a DevOps ticket to change the status of the repo to "non-monitored" in Gemnasium.
   1. In the future, automation could be added that uses Gemansium APIs to update the monitored status based on the value of "obsolete" in openedx.yaml.

...

1. Update the README.rst file in the repository to state that it is deprecated and that the repository may depend on out-of-date libraries with security issues.
2. Add "obsolete: True" to openedx.yaml (creating the file if necessary).
3. Send an email to edx-code@googlegroups.com notifying the openedx community about the change.
4. Follow similar directions as proposed here: https://helloanselm.com/2013/handle-deprecated-unmaintained-repositories/ to:
   1. Clone the master branch to a deprecated branch.
   2. Remove all code from the master branch
   3. Move a copy of the openedx.yaml with the obsolete: true flag back to the master branch.
   4. Create a short readme.md in the master branch with links to alternatives or information about why the repo was deprecated and where someone can find out more information about how to move forward.

...

• The edx organization will continue to have a mix of supported and unsupported repositories, which could be confusing, but you'd have to try really hard to ignore it.

Proposal 4 (Proposal 1, with an optional hand-off)

Same as Proposal 1, but prior to obsoleting a repo, ask on edX code whether someone would like to take ownership of the repo. If so, transfer to their github org, hand over rights, and maintain a fork of that in edx-deprecated. If not, proceed as per Proposal 1. In either case, change license to Apache.

Pros

• In the unlikely case someone builds something off of it, we may have something we can use down the line. 
• We've made a greater community contribution.

Cons

• We lose some control.

I think this may be just academic for the current repos, which are very edX-specific, but it may become important with tools like EASE, djeventstream, and similar, should we choose to deprecate them as well.