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.
The TSC consists of the TSC Board and the TSC Maintainers.
The TSC Board will be responsible for the following aspects of the Project.
- Providing advice and resources to guide or support the development of the Project.
- Nominating and electing candidates for the TSC Chair.
- Proposing improvements for the project, including its governance and community processes, and defining additional areas the TSC Board may assist the Project.
- At least one dedicated volunteer should be assigned to work in the community, including but not limited to technical research and development, business application, community operation and SIG. The volunteers can come from the Board members themselves or recommended organization members.
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 TSC Maintainers will be responsible for the following aspects. The TSC Maintainers must fulfill their duties during their terms of office.
- Actively contributing to the project and the community, participating in the code review process, responding to and replying to contributions and issues in a timely manner, and ensuring the overall code review process progresses in a timely manner.
- Managing issues, including bugs and problems.
- Managing the repository and tracking the release process.
- Preparing and updating documentation.
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 rights and responsibilities of the organization member include the following:
- Assign at least one dedicated volunteer to participate in community building, including but not limited to technical research and development, business application, community operation and SIG.
- Participate in the ecological construction of the community, drive the adoption of FATE’s application in organization member, and build a bridge of resource cooperation between the community and organization members.
- Enjoy the priority right to participate in the SIGs, and to participate in the development, reports and activities of project-related standards.
- The logo of organization members can be displayed on the official media of the community.
The organization member must meet the following requirements:
- Possess capabilities of technical research and development or have the business scenarios of applications in the field of privacy computing.
- Willing to invest resources in participating in community construction and contribution, including but not limited to technology research and development, scenario application, community cooperation and community operation.
The rules of becoming an Organization member are:
- The applicant must submit related information to TSC, please contact xxxxxx for the application form.
- Voting: All TSC Board members shall vote within one month after the applicant files an application. The applicant will become the Organization Member by winning a simple majority vote.
- The term of the Organization Membership：There is no limit for the term of the organization membership as long as the organization member carries out their duties as an organization member.
An organization member can become a TSC board member. As described before, a board member must be nominated by an existing board member, and win a simple majority vote from existing board members.
The organization member may withdraw at any time. Existing TSC Board members are entitled to remove the organization member who fails to perform their duties or violates regulations through voting.
- Voluntary withdrawal: The organization member may withdraw by sending an email to TSC Board members or submitting the PR on GitHub.
- Passive withdrawal: If an organization member fails to perform their duties or violates regulations, the organization member will be removed by a simple majority vote from TSC Board members.
Special Interest Groups (SIGs) are sustained and open teams in the open source community that focus on a specific technical or specialist area or areas. The team achieves specific delivery targets through regular tasks and activities. A SIG is open and transparent and welcomes developers to join and contribute. SIGs can be initiated by TSC members or Organization Members. Members of a SIG are recruited from the community. SIGs can cover a wide range of research solutions, technologies and applications related to federated learning or privacy computing.
- The SIG initiator invites other like-minded people to start the SIG together through the mailing list provided by the community.
- The SIG initiator submits an application to the TSC for the starting of the SIG. The SIG’s objectives, organizational structure and other relevant information should be submitted with the application. 1-2 people should be nominated as the person in charge.
- Voting rule: The SIG will be formally established by a vote of the existing TSC Board members, with more than 2/3 of the votes casted.
- The first 3 months after the forming of the SIG is the trial period. During the trial period, the SIG should prepare and recruit contributors, and recruit at least 3 companies as participants;
- At the end of the trial peroid, the SIG is required to report to the TSC on the results of the trial period, including the content of outputs and the active status of members. The TSC will then vote on whether the SIG will formally enter the operational phase. If the number of votes exceeds 1/2, the trial SIG will be approved to officially enter the operational phase, otherwise it will remain in the trial phase.
- The fully operational SIG shall report the work progress to TSC regularly (quarterly).
The SIG leader should organize regular meetings and discussion of relevant task progress among the members, who should in principle meet at least once per quarter. If the SIG is unable to organize activities with a certain number of participants on a regular basis or is unable to fulfil its organizational management responsibilities, the TSC may archive the projects it has developed and, if appropriate, have it dissolved.
- If there is no activity for 3 months or more, the SIG should be dissolved. At this point the SIG can be treated as a trial SIG as mentioned above. The SIG can be reactivated following the "trial - fully operated" procedure to avoid dissolution.
- If there is no activity for 6 months or more, the SIG must be dissolved. The community will archive the projects developed by the SIG and may reactivate them when a new SIG is formed.
- 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.