TOC Community Members Elections - Brainstorm & feedback

The task

As discussed in the Contributor Meetup, the new Technical Oversight Committee (“TOC”) of Open edX has recently started meeting. A key first order of business for the TOC is now to “organize and administer the annual election” of the community representatives on the committee. This process is not fully specified in the charter, so the TOC needs to design and approve it. Ed Zarecor, as chair of the TOC, has asked the new community members of the TOC to create a recommendation for the nomination and election process. Once a draft is complete, it will be presented to the whole TOC for review and approval.

Brainstorming & getting comments

To help prepare that recommendation, we would like to get the input from the rest of the community. This is why we are opening this thread, as a form of brainstorm – if you have any ideas or comments, please post them!

Prior art in other open source projects

Ignacio Despujol is also preparing a recap of prior art from other open-source projects, which he will post on this thread once he has it ready. If you are willing to help him prepare it, please say so in a reply in the current thread.

Topics of discussion

The recommendation will need to specify processes, including:

  • How elections will be conducted
  • Who will be eligible
  • How nominations are made (who can be nominated, who can nominate, and how)
  • How the voting is done
  • How voting results define which nominees are selected


  • Emphasize the “do-ocractic” nature of the project in the way we design the election process.
  • Ensure TOC members have demonstrated commitment and contribution to the project.
  • Incorporate ways to promote the core contributor & maintainer program through the election, encouraging more community members and organizations to commit time to it


The charter specifies that community members are to be confirmed by November 1st. So we’ll need to be ready by then.


Thank you Xavier for the introduction.

I have located the procedures for the TOC election of only three institutions, Cloud Native computing foundation (toc/ at main · cncf/toc · GitHub) and Continuous Delivery Foundation (toc/elections/2021 at master · cdfoundation/toc · GitHub) and Istio (community/ at master · istio/community · GitHub
). In the first two the term is for 2 years and in the third for one year.

In Istio the steering commitee selects the TOC, so I have included the steering commitee election procedure.

I have tried to organize the different aspects of the process in an excel table that I am attaching, but this implies changing the order of the clauses, so if someone has doubts about something I would recommend going to the original URL.

I cannot upload the excel file to the forum, so I have put it here Excel file with the comparison


1 Like

Here is the draft of the election process:

It has already been through a first round of review by the TOC board, and is now entering a wider community review phase. Given that we’ll need to start the actual election in September to be able to meet the November 1st deadline for the nominations, please post your comments by July 31st.

Post your comments inline in the document, or in the current forum thread. Note that the TOC will decide whether to implement suggested changes or not individually, but since it’s meant to be a core community feature, it’s important to try to find a solution that works for the community as a whole – so don’t hesitate.

Thank you!

@antoviaque - I was just alerted to this, I missed your post because I am not following this thread. If you want broad community review, I suggest re-posting as a new thread.

@sarina Good point, will do – I’ll post an announcement, linking back to this thread.

Thank you again to everyone who has contributed to this review! It has greatly helped refining the approach, and has led to many changes. The last version of the document coming out of the community review has been adopted by the TOC, without further changes (and including the amendment discussed during the review).

The election will thus start soon! There will be an announcement for the opening of the voters & candidates registration on Thursday (September 1st), with more details. But from now on, the Open edX community, through its core contributors and instructors, will elect a third of the project’s governing board! :partying_face: It’s really nice to see this happening.


For those who haven’t followed the community review of the election charter closely, here are the main changes implemented from the feedback:

  • The most impactful change is the removal, at least for the current round, of the learners vote. There were concerns about the learners vote being difficult to put in place in the time we have available this year, considering the few direct relationships the project has with the learners currently. An amendment has been added to delay this, while keeping the learners TOC seat, which for now are elected instead by the teachers. This Learners TOC member will have the mission to reach out to learners, and work towards implementing a learners vote. Since this is a significant change compared to the original proposal, it was added as an amendment, which was later adopted by the TOC.

  • Clarified that TOC members can be non-technical and can be re-elected

  • Clarified that “the elected candidates’ mission is to serve the Open edX community as a whole first, above the constituencies (core/instance managers, teachers, learners). We assign specific members to specific constituencies (assigning tasks to a single person helps avoiding the “tragedy of the commons” effect), but the primary mission of all the TOC community members is to care for the project’s community as a whole, above all. The additional responsibilities TOC community members get, like the core/teachers/learners come in addition to that as a focus area, not as a replacement.”

  • Clarified voting prerequisites: can people vote multiple times (eg core+educator election)? Can people from 2U, tCRIL and the TOC vote? (yes to all)

  • Clarified data collection uses: listed the information that will be made public (voters names, public profile URL, instance name, etc.), added explicit mention of using the voter registration form for volunteering (opt-in “I want to contribute, please contact me” checkbox on the form)

  • Expanded the pool of potential candidates by removing the requirement to be up-to-date in core contributor time commitments

  • Explicitly include TAs & course authors/assistants in the teachers voters

  • Clarified some of the election rules for deciding on winners (for example in case one candidate wins multiple elections, or what to do if a board member quits close to a normally scheduled election), and various minor text clarifications

There were a lot of comments and changes, so hopefully I won’t have forgotten anything! You can also locate changes in the Charter (the colored zones include changes, legend at the bottom of the doc).


  • September 1: Nominations & voting registration opens
  • September 12: Deadline for applying as a core contributor
  • September 30: Nominations & voting registration closes
  • October 7: Voting opens, ballots are sent to eligible voters, nominated candidates are announced with a link to their program
  • October 25: Voting closes
  • November : Announcement of the results
  • January 1: Terms begin

If you’re interested in the planning of the election or want to help, see the planning document, then comment or make inline suggestions there.

Btw, there has been a few questions around about the process - if you have questions, don’t hesitate to post them in this thread! It’s very likely that others will have the same questions too, so that will help everyone to answer them publicly here.

1 Like

Thank you @antoviaque. Great idea to have a thread about the process. It could be useful for a lot of voters and candidates.

I’ve started “spreading the word” about the election. I started with our internal team at EDUlib at Université de Montréal, Ecole des Hautes Etudes Commerciales de Montréal and Ecole Polytechnique de Montréal. I’ve asked that they spread the word in their own internal groups too.

I’ve already got some feedback on the process. To be honest, the process seems clear to me. Unfortunately, people who are not involved in the day to day activities of the community like you and I might have a different view of the process if we want to have them participate in the elections.

One of the question I got back from two of our instructors, technically the people helping the instructors build the courses, is that they do not know for whom to vote. I guess people want to know who are the candidates and what are their electoral platform before deciding to register to vote and voting.

There also seems to be confusion about who can vote for who. For example, they wanted to vote for me, but unfortunately, I am not a candidate and they would not be able to vote for me since I would be in the “operators & core community representative” category if I chose to run. And this is a restricted vote by core contributors and maintainers.

That’s it for now.

1 Like

Thank you @sambapete ! That’s great, it will help to reach more of the eligible voters. :+1:

And thanks for passing on the questions, too. It’s useful to know what’s not clear, and get a chance to clarify it.

I agree, in these types of elections when we are not very actively involved in the project, it’s hard to tell who to vote for, as we don’t know them. Which is why there is a series of questions in the candidature application template about what the candidates would do – their concrete projects and priorities. This way the choice can be focusing more on comparing the proposals of the different candidates, and evaluate what’s important to improve Open edX, from their perspective as instructors – either in the project, or in the software/UX.

Also, @Ali is planning to prepare a dedicated page/site which will provide a recap of the main information about the candidates and will allow to compare between the different projects/programs. See the current plans & discussions about that page.

If you were to declare yourself as a candidate (which I encourage you to do! it’s good for the democratic process to have more candidates, so don’t be shy :slight_smile: ), all the eligible voters would be able to vote for you – in other words, the candidates are all the same, regardless of the group of voters you belong to. So if your colleagues qualify for the instructors voters category, they would be able to vote for you.

The only thing is to make sure to fill the voter registration form, and be able to provide the elements listed in the form to confirm their eligibility.

1 Like

I wonder if one of the hurdles for people considering voting is: What does the TOC do? Is there a summary of what the TOC has done in the last year that could help people understand the implications of their vote?


The full scope of the TOC’s responsibilities are captured in the Charter. The critical summary is that the TOC is responsible for “governing the overall technical direction and stewardship of the Project.” This first year was a time of transition and establishing how the TOC will work together and collaborate.

Some of the critical activities this year are:

  • Identification and appointment of the first cohort of community members of the TOC.
  • Holding a project strategy “off-site” to align TOC members on the current state of the Open edX project and brainstorm on areas to invest and opportunities for the coming year.
  • Develop, approve the community election mechanism for year two.
  • Execute the election plan

This has been a year of transition for the project and the TOC.

The TOC will not be involved in the activities of the project, day in and day out. That work will be done by working groups, maintainers, and core contributors. The TOC will provide guidance and input and review the recommendations of our working groups to ensure they are consistent with the non-profit mission of tCRIL. In October, for example, the TOC will review a set of recommendations coming from the Product Working Group regarding production direction and priorities. The recommendations and TOC feedback will all be published at that time.


In regard of the voting method, in case of two candidate are tie with each other… There seem to be reference on the site about choosing what they call completion rules

Supported completion rules

CIVS currently supports five rules for Condorcet completion: Minimax-PM (the default rule), Schulze (also known as Beatpath Winner or Cloneproof Schwartz Sequential Dropping), Maximize Affirmed Majorities (MAM), a deterministic variant of MAM called CIVS Ranked Pairs, and a runoff-based Condorcet algorithm called Condorcet-IRV. The Schulze and MAM rules are described in the linked documents; Minimax-PM, CIVS Ranked Pairs and Condorcet-IRV are described below.

CIVS does not impose a completion rule; in fact, anyone viewing the results of an election can see what the results would have been with each of the rules. It is probably a good idea for the election supervisor to decide on an rule ahead of time, and include it in the election description. On the other hand, all five rules usually agree with each other, especially on the ranking of the first few candidates.

I am not sure if the above section is relevant to us, and if it is. And if yes, should the rule be chosen prior the result?

Ref: CIVS completion algorithms