Many years ago, we forked django-wiki and departed the upstream repo. So the course wiki feature no longer benefits from security updates & new features from the upstream repo. This project looks at our options to improve the wiki situation, particularly the options of deprecation and getting back to using the upstream repo.
While not a critical feature of most courses, wikis are present in enough courses to make removing the feature problematic. There are about 10 material changes in our fork vs. upstream, several of which would likely be welcomed upstream if submitted as PRs. So while not trivial, a switch back to an upstream release seems feasible if some effort is dedicated to working with the upstream maintainer on it over a period of time.
The first questions to answer - how much is the course wiki feature used?
Questions To Answer
What’s the current usage of the django-wiki course wiki feature for prod-edx and prod-edge?
How many courses have it activated?
How many pages/content have been generated over time?
By course team? By learners?
How many active learners are accessing the generated wiki content over time?
I first extracted all the wiki slugs and their associated course keys from the read replica's MongoDB collection which backs the Split Modulestore. I saved them to a JSON object using this JS (and some minor hand-edits to the output):
It is still the most widely used Django-based wiki package listed on https://djangopackages.org/ , and is one of the only two still actively maintained: https://djangopackages.org/grids/g/wikis/ . It added support for Python 3.9 and Django 3.2 four months ago, which we still need to do for our fork. It has merged 32 PRs in the past year, from 10 different developers.
How many changes are in our fork that don’t have equivalents upstream?
No obvious equivalent upstream, many of these are probably worth submitting upstream PRs for:
Our migration history is different from upstream; if moving back to an upstream release, we’d need to do something like add one last custom migration that would get us to a point in upstream’s migration history and then edit the history table
Note that we made our fork over 8 years ago, so upstream has made many changes in the meantime that we’d need to review, probably meriting somewhat careful a11y and security reviews at the very least.
@Jeremy Bowman will put together a blended project brief to determine if submitting our modifications upstream and getting back onto an official django-wiki release could work as a blended development project. This would save us a nontrivial amount of effort on future Django upgrades, etc. in addition to gaining many improvements made to the upstream package in the past 8 years.
For future hackathon projects, here are two ideas about which @Marco Morales (Deactivated) is hopeful:
We could integrate in django-wiki in order to power a special response typed inside Open edX discussions.
Specifically, we'd add a new type of response that was the community response.
This response would allow all members of the community to collaborate on a single answer.
In particular, this response type could be used on question post types in the discussion forum.
Piazza (a platform for instructors to efficiently manage class discussions) has actually added this feature.
Perhaps the Django wiki could power a new type of post in our discussion forums called resource.
These resource pages would be indexed and searchable in our discussions experience but would operate as a wiki with a full page editable interaction mode.
Both of these special post types (community response / resource page) could be an interesting way to combine wiki behavior in a discussion forum.