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.

The most important part

When developing a new feature, we believe the following two considerations are the most important of all:

1. Quality. When writing code, or feature development in general, we are not interested in getting the job done any way we can. There are many strict coding standards, written and unwritten, that we follow. And more than that, we make sure to incorporate best practices into our work, practices such as automated testing and deployments, and automated code checks.
   We also require that all work done at OpenCraft be reviewed by a second senior developer. The review process is detailed, so we know that anything that’s published with our name on it has been through the best quality controls possible.
   
2. Open Source. Transparency is one of our key company values. For this reason, we keep the overwhelming majority of our developments open-source. Whenever our clients ask us to customize their platform, we try to design new features in a way that they can be upstreamed (sent to edX® for review and merged into the main version of the platform).

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.

The roadmap

Understanding clients’ needs

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.

Discovery

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!

Community Collaboration

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.

Code time!

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.

Upstreaming

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!

Delivery

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.

Conclusion

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.

Photo by Yancy Min on Unsplash