Technical Oversight Committee (TOC) serves as an essential bridge and channel for integrating and sharing information across independent individuals, companies, and organizations. It is the coordination centre for problem-solving in terms of resource mobilization, technical research, and development outlook of the current community and cooperative projects.
- Provide supervision and guidance on the projects in the DeepModeling ecosystem.
- Participate in discussion and decision-making of technical roadmaps.
- Engage in discussion and decision-making activities in open-source collaborations.
- Decide whether to open, or to close, a project.
TOC members consist of representatives from:
- Team leaders
- 1 representative from GB
- 1 representative selected from above
The current list of TOC members is as below.
Name | GitHub | Membership | |
---|---|---|---|
Han Wang | wanghan-iacpm | han.wang.caep@gmail.com | TOC Co-Chairman |
Linfeng Zhang | jameswind | zhanglf@dp.tech | TOC Co-Chairman |
Huayi Wei | weihuayi | weihuayi@xtu.edu.cn | TOC Member |
Kuang Yu | KuangYu | windwhisper.yu@gmail.com | TOC Member |
Mohan Chen | mohanchen | mohan.chen.chen.mohan@gmail.com | TOC Member |
Xinzijian Liu | zjgemi | liuxzj@dp.tech | TOC Member |
Zhi Chen | zhixchen | chenzhi@pku.edu.cn | TOC Member |
TOC members have no concept of tenure, but will retire under certain circumstances that are to be detailed later.
All members of TOC have the right to nominate a representative as a new TOC member. The nominee is required to meet the following standards:
- The nominee must have enough energy to invest in TOC affairs, such as participating in TOC discussions, decision-making, and TOC monthly meetings.
- The nominee must have deep understandings of the DeepModeling Community or other projects in the DeepModeling ecosystem.
- The nominee must put the community first and be able to balance the relationship between the interests of his/her/their organization, if any, and the interests of the community.
After nomination, the existing TOC members will vote for the election and decide by lazy consensus.
Within the community, different types of decisions require different forms of approval. For example, the previous section describes decisions that require 'lazy consensus' approval. This section defines how voting is performed, the types of approvals, and which types of decisions require which types of approvals.
Decisions regarding the community are made by votes on the community repository. Votes are indicated by pull requests adding an entry under the "votes" folder. Votes may contain multiple items for approval and these should be separated. Voting is carried out by replying to the vote pull request.
Voting must be open for at least 2 days, and the deadline should be clearly stated in the call to vote.
Voting may take three flavours:
- +1: 'Yes,' 'Agree,' or 'the action should be performed.'
- 0: Neutral about the proposed action (or mildly negative but not enough so to want to block it).
- -1: This is a negative vote. On issues where consensus is required, this vote counts as a veto. All vetoes must contain an explanation of why the veto is appropriate. Vetoes with no explanation are void. It may also be appropriate for a -1 vote to include an alternative course of action.
All participants in the DeepModeling community are encouraged to show their agreement or disagreement towards a particular action by voting. But only the votes of TOC members are binding. Non-binding votes are still useful for those with binding votes to understand the perception of an action in the wider community.
Only active (i.e. non-emeritus) TOC members have binding votes.
-
Lazy Consensus: A proposal is considered supported by the community as long as nobody objects. This is the default decision-making mechanism in the DeepModeling Community, inspired by Apache Lazy Consensus. In cases of an objection, and no consensus can be found, a majority vote will be held. If a participant who makes a vote is in an urgent situation, they can request to change the Lazy Consensus process to a Majority Vote process to accelerate the decision-making.
-
Majority Vote: A majority vote is compelled in a separate pull request when there is no lazy consensus or when requested by a participant in an urgent situation. If 2/3 majority is reached before the voting deadline, the proposal will be passed directly. If the requirement is not met until the voting deadline, there will be a meeting to discuss the topic, followed by another compulsory majority vote.
Actions | Description | Approval | Binding Voters | Minimum Length (days) |
---|---|---|---|---|
New TOC Member | When a new TOC member is nominated. | Lazy Consensus | TOC Members | 6 |
New Incubator Project | When a project applies for incubation. | Lazy Consensus | TOC Members | 6 |
Modify governance Rule | When need modify governance rules | Majority Vote | TOC Members | 6 |