The Open edX Core Contributor Program grants community members expanded rights and ownership over various aspects of the Open edX Project, allowing them to actively participate in defining and deciding the direction of the platform. Members of the Core Contributor program earn this distinction by participating in Open edX community with distinction. They embody what we call the “3 Cs”: Commitment to the project, exemplary Conduct, and high Caliber contributions.
The program began in 2020, with an initial 9 community members being granted write access rights to various Open edX code repositories. Since then, the program has expanded to include nearly 40 core contributors, who not only commit code but oversee translations, manage projects, and more.
Recently we codified the program in OEP-54. “OEP” stands for Open edX (Enhancement) Proposal. An OEP is a document that details a specific decision being made by the Open edX community; the community agrees that they will follow the processes defined in the OEPs.
In OEP-54, we define various aspects of the Program, such as membership criteria and the nomination process for a new member. I’ll dive into some of these, with a focus on Core Contributors who commit code changes.
As we’ve expanded the number of Core Contributors who can commit code, we’ve also begun expanding the number of roles a Core Contributor can take on. Contributors are welcome to hold more than one role, as well! A full list of roles and responsibilities can be found at this link; a few roles I’ll highlight are:
For information on how to really dig into the community, see OEP-54’s “Where Do I Start?” section - there’s a lot of good resources there to get you started, as well as a few pointers on how you can reach out on the forums or to specific working groups. Joining a working group is a wonderful way to meet members of the community and get started on tasks identified by the group as having high value.
For those who code, I recommend joining the Build-Test-Release or Frontend working groups, as both groups tend to have a backlog of tasks they’d like people to pick up. The Deprecation working group is pretty fun (in my opinion!) - they focus on removing dead code from the system. They also tend to have a large backlog, but some tasks may be pretty complicated unless you know some Open edX architecture or are strong in Django/Python.
If you work at a company that’s developing Open edX features you’d like to someday see in the main codebase, you should reach out early in your development process to get pointers on the best way of architecting and implementing your change in order for it to have the greatest chance of being accepted. Reach out in the discussion forums in the Collaborative Proposals topic. Submitting your bug fixes, changes, and features upstream is a great path towards becoming a Core Contributor.
Community members who have demonstrated the 3 C’s, with a history of contributions to the Open edX project, may be nominated for inclusion in the program by an existing program member. For coders, the nomination would specify one or more repositories in the openedx GitHub organization for the nominee to get write access to. The process is designed to be straightforward and transparent: it takes place on the discussion forums, and other Core Contributors in the program weigh in on the nomination. Members are encouraged to give constructive feedback if they don’t feel a nominee is quite ready to join the program.
The Core Contributor program is administered by The Center for Re-Imagining Learning (tCRIL), the nonprofit organization that stewards the Open edX project. At any point on the road to becoming a core contributor, the program administrators may be reached in the #core-contributors Slack room in the Open edX Slack, or at cc-program-admins@tcril.org.
It’s been a joy and a privilege to be a part of the Open edX community and to have the chance to help administrate the Core Contributor program. I look forward to working with more and more of you as the program goes.
—---
Sarina Canelake
Engineering & Community Manager at Axim Collaborative
Sarina has 5+ years experience hacking on the Open edX platform and working with the Open Source community. She is dedicated to enabling open source contributors to the Open edX platform via extensibility and process improvements. She lives in Boston, MA with her 3 cat sons and has a lifelong love for all things Pokémon.
Photo by Chang Duong on Unsplash
At OpenCraft, we do a lot of feature development for our clients. While the Open edX platform is great and feature-packed out of the box, the best part is its extensibility. And we take full advantage of that when we need to develop a new feature.
When developing a new feature, we believe the following two considerations are the most important of all:
So, usually, in addition to internal reviews, our code is reviewed by edX. To ease this process, our instance manager monitors repositories and automatically creates sandboxes, allowing testing of the feature without installing the platform locally.
It’s worth mentioning that we are members of edX's prestigious Core Committers program, which means we are involved in the process of designing, implementing, and reviewing new features for the global platform roadmap.
We aim to help our clients with the design process: We talk with them so that we can understand their needs, and then we envision how to fill the gap with a new feature.
At OpenCraft, developing a new feature starts with a technical discovery. This is where we create a document that lays down the scope of the work to be done, a description of our approach as to how to do it, a list of tasks, and how much time it will take. We then send this document to our clients to review and approve, and we’re off!
As already mentioned, we put a lot of effort into designing new features in a way that they can be included in the Open edX codebase. This allows us to keep sources open and guarantees the best possible quality, because edX keeps standards high and reviews contributions rigorously. That’s why discussions with edX and other members in the community are an important part of our work. For example, we participate in Open edX releases preparation, are active on community forums and in Slack, and maintain some popular Open edX extensions.
After having signed off on the scope of the work, it’s a simple task of getting to it!
A good practice in this step is getting all code covered with tests, and reviewed by another developer before merging. We make a lot of use of our open source instance manager and create testing sandboxes for everything. Only after ensuring that everything works as expected, we deploy changes using blue / green strategy, so we can easily roll back in case of unexpected issues.
At OpenCraft, we believe in Open Source. Depending on the work done here, we might be creating new modules like XBlocks and Django Apps in which case we’d upstream them by uploading them to our public GitHub or GitLab accounts for everybody to use and improve.
But some changes require changes to the Open edX platform itself. In this case, after a ticket has been through our thorough internal quality control, we’ll submit it to Open edX Core Committers for review. Core Committers are trusted, long-standing members of the Open edX community who have been granted permission to review and merge code into the Open edX codebase. OpenCraft has multiple Core Committers within its team, which is a great token of trust from edX!
Finally, delivery! Once the work is done, approved, and merged into the platform if needed, we are ready to deliver the finished product. This might mean installing a new XBlock or App that was created, or it might be as simple as redeploying the client’s Open edX instance to include the latest changes.
While the roadmap above is the standard process, it’s not always a straight line. Sometimes we work with features that are interconnected, or maybe we have multiple review passes, or requirements change down the line etc. But no matter what happens, we are always committed to the two pillars of OpenCraft’s success: Quality Code and Open Source.
If you’re interested in having a feature developed for your OpenEdX deployment, feel free to drop us a note! You can contact OpenCraft here.
