This document defines the project governance for FATE.
The FATE community adheres to the following principles:
- Open: FATE is an open source project.
- Welcoming and respectful: See Code of Conduct.
- Transparent and accessible: Work and collaboration are done in public.
- Merit: Ideas and contributions are accepted according to their technical merit and alignment with project objectives, scope, and design principles.
- Vision: Benefit the ecosystem of federated AI solution providers, users and researchers, focused on federated AI use cases that will work across industries.
TSC Board members must meet these requirements:
- Participate in the FATE project;
- Must be an individual or organization that provides advice and resources and shows leadership to guide or support the development of the FATE project.
The rules for electing TSC Board members are given below:
- Any candidates must be nominated by existing board members, and introduce their plans and resource support for the FATE project during the election.
- Voting rule: Existing board members will vote to elect new board members. The candidate will become a board member by winning a simple majority of the votes.
- In the initial election, a total of 5 board members shall be elected. Existing TSC members shall nominate the candidates for the TSC Board, and each TSC member has only one nomination chance. During the election, all candidates shall introduce their plans and resource support for the FATE project. Then existing TSC members will vote for each candidate. Candidates winning a simple majority of the votes will become board members.
- The term of office of each board member is 2 years.
- Before the expiry of the term, the member may renew the term by participating in a defense and winning a simple majority of the votes of the board members.
Any member may withdraw from the TSC Board during the term of office. Existing members are entitled to remove any member who fails to perform his/her duties or violates regulations through voting.
- Voluntary withdrawal during the term of office: The member may file a withdrawal application to the TSC Chair, which shall review the application and decide whether this member is eligible to the nomination of future board members.
- Passive withdrawal: If a board member fails to perform his/her duties or violates regulations, the TSC Chair may propose to remove this member through voting. The removal will be approved by a simple majority of the votes from board members. This member is ineligible for future board election.
- If the representative of an organization member that serves as a board member cannot fulfill its role due to resignation or personal reasons during the term of office, the organization shall designate a new representative and continue the previous representative’s term of office.
The qualification requirements and application method for the TSC Maintainer are:
- The TSC Maintainer must be a committer first.
- The applicant must be proficient in at least one technical expertise.
- The applicant must keep contributing some PRs, including contributing codes, documentations, or other technologies, and undertaking partial code review of the community.
- All TSC members shall vote within one month after the applicant files an application. The applicant will become the Maintainer by winning a simple majority of votes.
The term of office of the TSC maintainer：There is no limit for the term of office of the Maintainer as long as the maintainer carries out his/her duties as a maintainer.
A Maintainer can become a board member. As described before, a board member must be nominated by an existing board member, and win a simple majority of the votes from existing board members.
The Maintainer may withdraw at any time. Existing TSC members are entitled to remove the Maintainer who fails to perform his/her duties or violates regulations through voting.
- Voluntary withdrawal: The TSC Maintainer may withdraw by sending an email to all TSC members or submitting the PR on GitHub.
- Passive withdrawal: If the TSC Maintainer fails to perform his/her duties or violates regulations, he/she will be removed by a simple majority of the votes from TSC members.
The TSC Chair must meet the following requirement:
- An individual who has a significant influence in the industry and can contribute to the federated learning sector.
The TSC Chair election rules are given below:
- The TSC Chair shall be selected from and nominated by the TSC Board. The candidate winning a simple majority of the votes from the existing TSC members will be the TCS Chair.
- Candidates must be nominated by existing board members, each of which can nominate one candidate only. During election, all candidates shall introduce their plans and resource support for the FATE project.
- Voting rule: Existing TSC members will vote to elect the new Chair. The candidate will become the TSC Chair by winning a simple majority of the votes.
- The term of office of the TSC Chair is one year, and the Chair can be re-elected once. If the board membership of the TSC Chair expires during its term of office, he/she may renew the membership and proceed on the stipulated renewal procedure, while the term of office of the TSC Chair will not be affected. The TSC Chair may terminate his or her TSC membership, but this will be regarded as voluntary withdrawal from the board and voluntary resignation from the TSC Chair following the corresponding procedures.
- To extend the terms for one more term, the current TSC Chair shall file an application for reelection 3 months in advance. Then TSC members will vote, and the reappointment will be approved if he/she wins a simple majority of the votes.
- During the election of new chair, the candidate must be nominated and elected following the above steps. Upon resignation, the former Chair will remain a board member or may withdraw from the board.
The TSC Chair may resign during the term of office. Existing board members are entitled to remove the Chair who fails to perform his/her duties or violates regulations through voting.
- Voluntary resignation: The TSC Chair may file a resignation application to the TSC Board 3 months in advance, and directly resign after the election of the new Chair and handover the work to the new Chair within three months.
- Passive resignation: If the TSC Chair fails to perform his/her duties or violates regulations, the LF or two (or above) board members may propose to remove the Chair through voting. The removal will be approved by a simple majority of the votes from TSC members. Upon the removal, the new Chair shall be elected following the stipulated chairperson election procedure.
- The former Chair will be no longer a board member in the case of voluntary or passive resignation during the term of office.
- The project aims to operate as a consensus-based community, and decisions are built on the agreement reached by TSC members. Proposals and ideas for agreement can either be submitted via a GitHub issue or PR, or by sending an email to [email protected].
- Decision making process should be transparent to adhere to the principles of FATE project.
- If any decision requires a vote to move the Project forward, TSC member will vote on a one vote per voting TSC member basis.
- Quorum for voting requires all voting TSC member to participate.
- Any decisions require to be supported by a majority approval of TSC member vote.
- For formal votes, a specific statement of what is being voted on should be added to the relevant GitHub issue or PR, and a link to that issue or PR should be added to the TSC meeting agenda document. TSC member should indicate their yes/no vote on that issue or PR, and after a reasonable period of time, the votes will be tallied and the outcome will be noted.
- All proposals, ideas, and decisions made by TSC member should either be part of a GitHub issue or PR.
TSC meetings include the TSC Board meeting and the TSC regular meeting, with the agenda and form of each meeting as follows:
TSC Board Meeting
- This meeting is held irregularly, and called and chaired by the TSC Chair or any board member;
- The agenda of the meeting includes the discussion and communication of major issues including rules and regulations, project direction, project cooperation, community development and community operation, the election of the Chair, and voting on relevant issues.
TSC Regular Meeting
- It is held once a quarter and chaired by the TSC Chair;
- The agenda of the meeting includes technical discussion, project/sub-project review and proposal discussion, conveying of board resolution, and voting on relevant issues;
- TSC members shall not be absent from meetings more than 2 times in a year; otherwise, the member could be removed from the TSC Board or TSC Maintainer.
- Making a community work requires input/effort from everyone. Maintainers should actively participate in Pull Request reviews. Maintainers are expected to respond to assigned Pull Requests in a reasonable time frame, either providing insights, or assigning it to other maintainers. And make sure that ongoing PRs are moving forward at the right pace or close them.
- Diligently providing supports (via mailing list, GitHub, slack, email, WeChat, etc.), answering questions，responding to requests and replying to bugs, etc.
- Publishing releases
- Fixing bugs
- Writing and updating documentation for usage and development
- Getting the word out and making your project known
- Monitoring the improper speech and behavior of the community and dealing with community conflicts and disputes.
- Our current release cycle is intended to be two months. We may change this based on user demand.
- In general, master is assumed to be release candidate quality at all times for documented features. For undocumented or clearly under development features, use caution or ask about current status when running master.
Significant changes to the codebase and / or new features must be first discussed and weighed, and sometimes formally documented, before they can be implemented. The process for proposal informs and involves all the members of the community in major improvements to the codebase and / or new features throughout the development process, to increase their sharing comments and ideas and offering to help.
The proposal process is the process for reviewing a proposal and reaching an agreement on whether to accept or decline the proposal.
Design Documents
The proposal should be documented as a separated markdown file pushed to the root of the proposals folder in the community repository via PR. The name of the file should follow the name pattern design/shortname.md.
Use the Proposal Template as a starting point.
Proposal lifecycle
The proposal PR can be marked with different status labels to represent the status of the proposal:
- New: Proposal is just created
- Reviewing: Proposal is under review and discussion
- Accepted: Proposal is reviewed and accepted (either by consensus or vote)
- Rejected: Proposal is reviewed and rejected (either by consensus or vote)
Proposal Review
The maintainers hold “proposal review meetings” approximately weekly to review pending proposals.
The principal goal of the review meeting is to make sure that proposals are receiving attention from the right people, by cc'ing relevant developers, raising important questions, pinging lapsed discussions, and generally trying to guide discussion toward agreement about the outcome. The discussion itself is expected to happen on the issue tracker, so that anyone can take part in.
Once comments and revisions on the design doc wind down, there is a final discussion on the issue, to reach one of two outcomes:
- Accepted proposal or
- Declined proposal
After the proposal is accepted, implementation work proceeds in the same way as any other contribution.
The Federated AI Ecosystem organization is open to receive new sub-projects under its umbrella. To apply a project as part of the Federated AI Ecosystem organization, it has to meet the following criteria:
- Licensed under the terms of the Apache License v2.0
- Project has been active for at least one year since its inception
- Related to one or more scopes of FedAI ecosystem:
- Federated machine learning
- Federated transfer learning
- Federated data network
- Federated inference
- Federated machine learning on Edge
- Federated learning workload management using cloud native technologies
- Multi-party security protocol
- …
- Be supported by 2/3 majority of the existing maintainers
The submission process starts a Pull Request or Issue with the required information mentioned above. Once a project is accepted, it's considered as a Federated AI Ecosystem sub-project under the umbrella of Federated AI Ecosystem.
Please see CONTRIBUTING.md for general contribution guidelines
FATE adhere to the Code of Conduct.
All substantive changes in Governance require total Maintainership vote supported by 2/3 majority of existing maintainers.