Attendees
- Ed Zarecor (Axim)
- Ferdi Alimadhi (MIT)
- Dustin Tingley (Harvard)
- Virginia Fletcher (2U)
- George Babey (2U)
- Samuel Paccoud (FUN, Community Representative)
- Xavier Antoviaque (OpenCraft, Community Representative)
- Stefania Trabucchi (Abstract Technologies, Community Representative)
Executive Summary
- TOC Membership Changes: Virginia Fletcher replaces Julie Davis (2U), Samuel Paccoud (FUN) leaves
- Conference Plans: Announcement imminent, the conference will be held later than usual
- Mobile App Development: After the TOC approved to adopt the Raccoon Gang apps as the official mobile apps, progress has been made. There was a kick-off meetings with 2U and Raccoon Gang, as well as a comprehensive gap analysis.
- Maintenance Funding: Discussed better spreading maintenance funding burden, as most currently falls on 2U, prompting discussions about the distribution of workload within the community. Opportunities for non-profit organizations to take on certain maintenance tasks were discussed.
- Elected Representatives’ Term Extension: The TOC proposed and agreed to extend the representative term from one to two years to ensure representatives have sufficient time to be productive. Implementation starts with the current 2024 election.
- Election Nominations: The TOC reviewed and approved the candidates for the 2024 community elections.
- Front End Plugability Summit: A Front End Plugability Summit will be organized with the intent to resolve difficulties in adapting the front end to business-specific needs. Recommendations from the summit will be presented to the TOC.
- Pull Request Review Delays: Significant delays in pull request reviews are hampering certain projects. Proposals were made to improve this situation, including expanding the core contributor program and improving pull request monitoring.
- Forum Thread Discussions Summary: Various proposals were raised in the community forum, including expanding the maintainer program, involving edX/2U employees, improving pull request monitoring, and creating lighter roles for contributors.
- Core Issues: Overburdened repository maintainers, misalignment with organizational use cases, and lack of predictability for external contributors were identified as significant problems. Having multiple reviewers and defining core repositories were proposed as solutions.
- Stats: The core contributors’ capacity was summarized, with about 50 active contributors performing between 200 and 300 hours of work every two weeks.
- Root Cause Analysis: Ancient project biases, late proposal reviews, the shift from proprietary to open, and the continuous delivery of repositories were identified as root causes of the issues.
- Encouraging Participation in the Core Contributor Program: Issues were raised about the perceived value and benefits of becoming a core contributor, especially for those who already have merge access. Identifying platform parts that can be kept internally was suggested to accelerate velocity.
- Open Source Project Deployment and Contribution: Proposals for managing automatic deployments from pull requests were explored. A reference version from the community’s standpoint was suggested.
- Additional Measures: Getting 2U employees involved as core contributors and defining a review-sharing process were proposed as next steps. The significant improvement in managing pull request workflows was also recognized.
- Next Steps: The meeting agreed on creating a catalog of potential changes, pushing for earlier product reviews, improving the extension points and the platform’s plugability, identifying core repositories, encouraging community involvement and contribution, and exploring ways to clarify the open-source project’s social contract. The feasibility of delegated reviews and automatic deployment by 2U was to be discussed internally.
Summary
TOC Membership Changes
Virginia Fletcher, Head of Technology at 2U, was welcomed to the team. She was taking over from Julie Davis as a 2U representative. Virginia is in her fourth week with the company. She had previously worked as a CIO and Chief Product Officer at Strike Learning, managing some of their portfolio companies and overseeing product and technology as a whole. She had about 30 years of experience in the tech industry, with the last few years spent in Ed Tech. Her experience spanned various industries, including supply chain automation, Fintech, and healthcare.
Samuel Paccoud, the CTO of France Universite Numerique announced that he would be leaving his job at the end of the week to join the Prime Minister’s office for digital affairs. He will be working on transformation for universities, helping them to transform their tooling.
Conference Plans
The conference plans have been moving forward, although it would be later than usual due to the schedule at the selected location, which should be announced soon.
All TOC members were encouraged to attend if possible. We might do an in-person TOC meeting at the conference if there were a quorum of members present at the conference. While there would always be members joining remotely, there hasn’t been an in-person meeting yet.
Mobile App Development
The group then discussed the outcome of the recent decision voted by the TOC to adopt the new Raccoon Gang applications as the official mobile offerings for the Open edX project. The motion had been approved unanimously and is moving forward rapidly.
A meeting has been held the previous week with staff from 2U to kick off the process of collaborating on advancing the mobile applications. A meeting has also been held with Raccoon Gang to demo the full functionality of the new mobile apps and conduct a comprehensive gap analysis between the existing mobile applications and the new ones. Great progress was made and there would be the equivalent of three scrum teams focused on advancing the mobile apps for the next three to six months. A recording of the mobile app demo is available and could be shared.
Next Steps
- Share the recording of the mobile app demo with interested parties.
Maintenance Funding
The burden of funding maintenance that currently falls on 2U was then discussed. There is a lot of work being done by the 2U team to provide various maintenance and that they were considering whether there were pieces of that work that could be handed over to others to maintain the core.
A discussion ensued about how to decide to allocate or delegate certain maintenance tasks that a particular company could do, to a nonprofit organization instead. Maintenance work for a general platform core, for example, benefits the entire platform and community, not just one single company. (Examples: software languages, or transitioning from one search system to another due to license changes)
The point was made that Axim acts as a focal point for the wider community but would not be in a place to be the exclusive owner of the open-source project. It was suggested to be careful to not end up carving out tasks and simply assigning them to Axim. Instead, tasks with general positive externalities should be facilitated and worked on by the open-source community as a whole, including 2U and Axim. The significant issue being how to evenly distribute the maintenance workload across the community of users who benefit from the open education platform.
It was agreed that it could be beneficial to examine areas where the community is willing to take on parts of the platform. Starting with what organizations and individuals want to contribute might be more effective and could result in suggestions of tasks that may not have been considered for delegation. It was also suggested to bring the community’s needs together in a format like a hackathon, which could be a good way to start addressing specific needs. What Jeremy did with the Python 3 upgrade could also be a source of inspiration.
It was also acknowledged that the amount of code that makes up the platform was too much and that we are actively working to simplify the platform and deprecate services that were not part of the core or haven’t aged well. The goal being to make the platform not just more equitably maintained, but also more maintainable generally.
Next Steps
- 2U is planning to have further discussions about what that carve-out might look like, and bring it back for further discussion
- Consider pulling the next TOC meeting forward to continue this discussion sooner
Extension of Elected Community Representatives Term to 2 Years
The TOC then reviewed a proposal to extend the term of the elected community representatives from one year to two years. Given that the TOC meets six times a year, it was felt that a one-year term didn’t provide enough time for representatives to be productive.
The effect would be immediate, so that the people standing for election now would be elected to a term of two years. It was acknowledged that this might feel like moving quickly, but assuming that all the nominees were willing to serve for two years, it would be preferable to put that into place now.
Decision
- The term of the elected community representatives was extended to 2 years, and will apply to the current 2024 elections
Next Steps
- Reach out to all of the nominees to make sure they are fine with the change to a two-year term
- Update the official version of the charter to reflect the extension of the term of the elected community representatives from one year to two years.
TOC Election Nominations Review
The TOC reviewed the candidates for the 2024 community elections, as one of the TOC’s roles was to provide the final arbitration of the list of candidates and raise any concerns about any of the nominees.
The candidates nominations and voter registration have concluded, based on changes to the charter that had been reviewed in previous meetings. No objection was raised.
Decision
- All nominated candidates have been accepted by the TOC.
Front End Plugability Summit
There are plans to organize a Front End Plugability Summit across the project. The problem to solve being that there are areas in the front end of the application that are difficult to change to accommodate business-specific needs. As a result, some of these changes have leaked into the open-source project. The project needs a way for organizations like 2U and others to extend the front ends without making changes to the core. Some noted that the issue has become urgent, and that we have the right group of front-end architects from across the community to participate in the summit.
The summit is expected to produce a shared recommendation for how to approach front-end plugability, with several architects responsible for that recommendation joining a future TOC meeting to present their recommendation.
There are currently four solid recommendations that are starting to emerge, with four different teams developing these in advance of the meeting. It was hoped that significant progress on reaching consensus would be made when they meet in person later in the month.
It was noted that the TOC could play a crucial role in making recommendations if consensus couldn’t be decided, especially given that there were four different teams with four different approaches. Though it is hoped that the group will focus on what’s the best option for the project rather than facing a “not invented here” conversation, and ending up with multiple ways of doing things, which would require everyone to learn multiple methods. This would not help the maintainability issue discussed earlier, and could potentially make the problem worse.
Next Steps
- Organize the Front End Plugability Summit to address issues with the front end of the application.
- Arrange for the recommendation on front-end plugability to be presented to the TOC in advance of a future meeting, so everyone has a chance to review it and discuss it in depth.
Pull Request Reviews Delays
The next topic discussed was the issue of significant delays in getting some changes to the platform reviewed and merged. This issue was highlighted by multiple community members over time - most recently by Naccho, who is focused on launching Open edX on campus for five Spanish universities. The aggressive timeline for this project is being put at risk due to delays in making changes to various parts of the platform.
OpenCraft also posted a proposal for sharing the maintainership of some enterprise repositories. This proposal was made in response to difficulties experienced in getting feedback, reviews, or decisions on their pull requests. The willingness to contribute and share the load to facilitate the process was emphasized.
Forum Thread Discussions Summary
A thread from the forum discussing the issue was brought up, that was based on yet another report about difficulties in getting pull requests merged. This thread led to several interesting discussions and proposals within the community:
- Open the possibility for core contributors to become an escalation or delegation place for pull requests
- Advertising the core contributor program more and expanding the maintainer program. There are probably many people within the community who could participate but currently do not.
- Having edX/2U employees become core contributors as a way to involve people more in the community and create more collaboration.
- Improving the monitoring of pull requests and ensuring proper explanations are provided.
- Creating a lighter role for contributors to encourage more people to become core contributors.
Core Issues
It is currently hard for contributors outside of the organization to predict when their contribution will be reviewed and whether it will be merged. This is due to the fact that the owners or maintainers of a repository may have other obligations that prevent them from addressing contributions in a timely fashion. There is a need for a process that provides predictability and reduces the burden of being a gate to contributions, while also ensuring safety for the organization’s business.
Additionally, there are now features in the platform that the organizations doing reviews do not use. This means that it’s necessary to understand not just the organization’s own use case, but also the broader use case and the complexities within the platform. There is reluctance to approve something that could potentially break the system or the community. Welcoming core contributors who have more expertise across different use cases, especially for front ends that are not being deployed by the current reviewers’ organizations.
It was suggested to ensure we have more than one reviewer and approver for pull requests in every important repository. This would ensure that if the organization is too busy to review something, there would be a way for it to get reviewed and move forward.
This brought up the difficulty in defining which repositories are important or “core”. There might need to be different levels of importance across the repositories, similar to severity levels.
Stats
To give an idea of the capacity of core contributors, there are:
- ~50 core contributors, with the number growing year over year, but not exponentially: adding ~5 new contributors each year, and losing a few.
- In terms of contributed hours, core contributors report contributing between 200 and 300 hours every two weeks.
- In terms of pull requests, the number changes over time and we didn’t have an exact figure available immediately, but it can be looked up in the board “Contributions”.
It was added that a significant part of the core contributors don’t appear to be very active, which is something to keep in mind, and that we may need to address.
Root Cause Analysis
The history of the project is a factor: when it was originally open-sourced, it was primarily for edX’ purposes. Contributions that did not align well with the organization’s purposes were not prioritized. As a project, we have made some steps towards being a more inclusive project, but there is still a long way to go.
A unique aspect of our project: edX does continuous delivery of some of the repositories that are part of the open-source project. This presents a significant opportunity to disrupt things on their production depending on how things are merged, which is why it made sense to have some stage gates before things merged to production.
Some of the proposals are also sent too late for review: there is an ongoing effort to push contributors to submit for review by the product team when they are still in the design phase, rather than when they have become finished software.
The project has also undergone significant transformation over the last couple of years, but in projects and organizations of our size, there can be significant cultural and organizational inertia. The shift from a more proprietary mindset to one of active contribution to an open group, can’t be easy for everyone. Involving more engineers and teams in the community and encouraging them to contribute to the project could help to develop an open-source culture.
Encouraging Participation in the Core Contributor Program
There is an issue with the perceived value of becoming a core contributor, particularly for those who already have merge access and commit rights. There might be a need to sell the benefits of becoming a core contributor to those who do not yet see the value in it.
It was acknowledged that the core contributor program was initially very attractive to those for whom it was the only route to commit access, but probably much less to those who already have it. It might also not be clear to everyone what the social contract is on an open-source project. It was proposed that everyone, including those who already have commit access, should earn their commit rights (potentially with some kind of grandfathering or delay to make this transition smoother).
It was noted that this would need to go hand in hand with a smaller surface area and more extension points. There might be a need to identify parts of the platform that could be kept internally to accelerate velocity without having to go through the community contributions aspect.
It was reiterated that the goal is not to add too many steps for contributors, but to improve the process for everyone. Taking on maintainership and becoming a core contributor can help justify the ability to make quick decisions and get things done within the community.
Open Source Project Deployment and Contribution
It was noted that if continuous delivery is one of the primary obstacles to having contributors on repos, then there needs to be a discussion on how to work around that.
One of the solutions discussed in the forum thread on this topic would be to have the automatic deployment for pull requests differentiating on the origin of changes being added. When changes come from 2U or have already been reviewed by 2U, it would proceed to automatically deploy, like currently. However, for changes approved by other community members, it would add a manual step to allow someone to review the code before it is deployed.
While most people in the community use named releases and don’t depend on merges to deploy features, the burden remains on contributors to keep their code up to date until their contribution is merged. He suggested that there is an interest for contributors to have their contributions merged so that other developers can start using them and they won’t have to keep rebasing their pull requests.
Having a reference version from the community standpoint, even if it hasn’t been battle-tested on edX yet, would be an important step. This would allow contributions to continue even if changes would still be needed before it can be deployed it on edx.org.
It was also agreed that one of the goals should be to avoid a situation where additional constraints on contributions from 2U would cause them to not come in as quickly as desired. Related activities could include continuously improving the extension points and the plugability of the platform, and having a product collaboration process where no pull requests, except for bug fixes or upgrades, are coming in without a product approach memo upstream of them.
Additional Measures
Two potential next steps were then suggested: getting a few people from 2U involved as core contributors, and defining a process for sharing the load on reviews. These proposals will be reviewed within 2U.
It was also proposed that rather than capturing action items, it could be better to create a catalog of potential changes to the current approach and then look at them all holistically to decide which ones would be most beneficial.
It was also noted that the work that Michelle Philbrick and Tim Krones have been doing around managing the flow of pull requests has already made a significant difference. The number of items waiting for review has decreased significantly recently.
Another question is whether there would be enough incentive for engineers to join the core contributors group at edX/2U, and that it could be discussed if it wasn’t the case. On this topic, the idea of an expiration date on free access commit access to the repository was also brought up, which could potentially serve as an incentive for continued contribution.
Next Steps
- Create a catalog of potential changes to the approach and then look at them all holistically to decide which ones would be most beneficial.
- Continue to push for product reviews to be submitted to the product team earlier, in the design phase – no pull requests, except for bug fixes or upgrades, should be coming in without a product approach memo upstream of them.
- Continue to improve the extension points and the plugability of the platform.
- Identify the list of repositories considered “core” (and its subset that need more attention from a review perspective), vs the ones that are better kept internally
- Work on involving more engineers and teams in the community and encouraging them to contribute to the project, and keep developing an open-source culture within the involved organizations
- Consider ways to make the social contract of an open-source project clearer to all participants.
- Explore the possibility of everyone earning their commit rights, with some form of grandfathering or delay for those who already have them.
- 2U to have an internal conversation about the actions above, and the following points:
- Bringing up the proposal of getting a few people from 2U involved as core contributors
- Consider options to remove barriers to delegation by 2U to 3rd party community members, such as the automatic deployment