Attendees
- Edward Zarecor (Axim)
- Xavier Antoviaque (OpenCraft)
- George Babey(2U)
- Ferdi Alimadhi (MIT)
- Anant Agarwal (2U)
- Stefania Trabucchi (AbstractTechnology)
Guests
Absent
- Samuel Paccoud (FUN)
- Dustin Tingley (Harvard)
Mobile Strategy and Direction
The TOC discussed a proposal, captured in a draft OEP, to endorse newly contributed mobile applications developed by RaccoonGang as the official mobile applications for the Open edX platform.
The TOC members unanimously agreed to endorse this proposal.
As a result of this endorsement, the legacy mobile applications for Android and iOS developed originally by edX, will be deprecated over time, using our DEPR process.
Any community members who wish, can continue to use the legacy applications, but the supported choice will be the newly contributed ones.
We intend to develop the roadmap for mobile as we do for other areas of the platform, through the Product Working Group. We intend to extend the existing applications collaboratively so 2U and other existing users can migrate to them. Universal adoption creates the biggest community-wide win-win opportunity. However, we will focus on a roadmap for eventual convergence rather than gate adoption of the new applications on fully closing the current feature gaps.
Updates to the Project Code of Conduct Governance
The TOC reviewed and endorsed a proposal from Axim to change the way that the project Code of Conduct is managed and enforced. The proposal developed by Sarina Canelake at Axim Collaborative proposes a more inclusive approach. Previously, the Governance Team as defined by the Code of Conduct included only Axim staff. The proposal is to adopt a structure similar to that of the TOC that will include members from 2U and the community. The proposal is available for review and comment here.
Updates to the Process for Electing Community Members to the TOC
The community representative on the TOC, Xavier Antoviaque, Stefanie Trabucci, and Samual Paccoud, developed a set of recommendations for changing the process for electing community members to the TOC.
The full proposal will be shared with the community imminently.
The key changes that are being recommended are small, but important. They correspond to comments listed in the elections feedback thread in the forum.
- It is recommended that folks involved in the project in any capacity will be eligible to vote in community elections. This will create an open, inclusive, and broad based electorate. Rules for candidate eligibility will remain the same and require that candidates are Core Contributors to the project.
- Going forward, each voter will be able to vote in only one category. One person, one vote.
- For the avoidance of doubt, the charter now notes that we will use the default vote completion method used by CIVS to decide ties (currently, Minmax-PM), see CIVS completion algorithms for more details.
- In cases where a single candidate is elected in multiple categories of voters, the order of categories used to pick the winner from each category is reversed. It is now User → Teacher → Operator/core (see the last two paragraphs of Elections - Additional feedback? - #3 by Felipe to read Felipe’s explanation).
- The nominations and voting registration will open earlier in future years, at the plenary of the Open edX Conference. This is to allow to give better visibility to the process, and work on registering more candidates and voters at the conference. (It’s too late for this year, but this would be done from next year).
The TOC unanimously endorsed the proposal
Review of OEP-63 on TOC Reachability
Following the discussion about its operation and decision principles in April, the Technical Oversight Committee (TOC) is reviewing a process describing how it would intervene in community decisions, to maintain project coherence and efficiency. The TOC’s goal is to empower contributors to make decisions, but recognizes that some decisions may require extra attention due to their complexity or long-lasting repercussions.
The proposed process is defined in a draft OEP 63, open for comments. It empowers community members to bring up topics to the board’s attention, and request to take a decision about a proposal.
According to the policy, anyone in the community can request it, but the request must be supported by at least two core contributors or a TOC member. TOC members are also encouraged to participate in community discussions early, before they’re asked to arbitrate.
The process for submitting an arbitration involves:
-
Opening a public discussion about the issue, such as in a forum or in a formal decision recording format like OEPs.
-
Posting a formal arbitration request to the TOC, which can be done in a forum post or a GitHub ticket.
-
Receiving support for the arbitration from core contributors and/or TOC members.
-
If the requirements are met, the TOC schedules the topic for a future meeting
-
The TOC chooses to accept, modify, or refuse the suggested decision in the arbitration.
-
The outcome of the arbitration is communicated in a reply to the forum thread of the arbitration, along with a comment to explain the decision.
The TOC members completed their review of the OEP without objections.