TSC Overview
The Technical Steering Committee (TSC) is the main decision-making authority of the OpenFL project. The TSC defines the strategic objective of the project, makes business & legal decisions, as well as high-level technical decisions. The TSC consists of elected members. The election takes place every year by the end of the first quarter (Q1) of the year* , but changes in the TSC may be made during the year based on the project needs and the decision by current TSC members.
The current list of TSC members is here. The number of TSC members can be increased, but up to a reasonable size (no more than 9 people). The minimum size of the TSC should not be less than 3 people.
* For 2023 there will be no elections, TSC members and Chair are defined by the founding organizations.
Expectations
The Technical Steering Committee members are deeply engaged in the life of the project, they share the mission of OpenFL, believe in its success and do everything that is needed to achieve it. They are not only decision-makers, but also evangelists of the project. More specifically, they:
- Share responsibility in the project's success;
- Have made a long-term, recurring time investment to improve the project;
- Spend that time doing whatever needs to be done.
The TSC members pledge to participate in the regular TSC meetings, vote thoughtfully and make right decisions.
Responsibilities
The TSC members are responsible for all business, legal and technical oversight of OpenFL. More specifically, they:
- Define the project strategy, including key success metrics and regularly updated roadmap;
- Coordinate the technical direction of the project;
- Organize sub-projects and remove sub-projects;
- Create sub-committees or working groups to focus on cross-project technical issues and requirements;
- Establish community norms, workflows, issuing releases, and security issue reporting policies;
- Evaluate and form list of Maintainers;
- Make decisions about adding new TSC members, replacing or removing current TSC members, as well as electing a TSC Chair;
- Coordinate any marketing events, or communications regarding the project.
03-21-2023
Agenda: https://docs.google.com/document/d/1bjcoDNk0pESBSEP2fD8SmqDZX5akxbWkwdG-EtZ9gJo/edit
...
Meeting recording:
| View file | ||||
|---|---|---|---|---|
|
Presentation:
| View file | ||||
|---|---|---|---|---|
|
Meeting Notes:
Attendees: Daniel Beutel, Layne Peng, Prashant Shah, Hasan Kassem (MLCommons), Patrick Foley, Sarita Regmi, Micah Sheller
...
- There are several reason why standardized components would benefit the wider FL community
- Micah: Flower baselines could be a good source of inspiration for this
- Framework interoperability - i.e. pairing a FATE / Flower Client with an OpenFL server, or vice versa. Allows for larger heterogeneous federations that bring strengths from individual implementations (ex. TFLite support for Flower, TEE’s with OpenFL)
- Standardization of communication mechanisms is a key step in achieving hybrid deployments (along with weight setting / extraction, task representation)
- Aggregation algorithm / research verification - standardization could allow for portability of aggregation algorithm implementations across frameworks Micah: Flower baselines could be a good source of inspiration for this
- Could allow for higher level interfaces to be built on top of OpenFL / Flower / FATE backends
- Micah: Excited for when standards solve common problems, and various teams can focus on their areas of specialty and cover more of the FL problem space. This is so large that a single entity cannot take it on by themselves. Governance and the way that models get persisted would also be good candidates for standardization.
- Federation governance / TEE support could eventually be in scope for use not just in OpenFL Security, but also Flower / FATE
...
- Live note during the meeting
- Google doc might be the platform [i.e. HERE]
- Meetings are Meetings are recorded
Brainstorming how to grow the OpenFL Community?
- We have been increasing public facing blogs in the last 6 months
- Starting with GaNDLF (UPenn) and how to make these models run in a federated way with OpenFL
- Blog highlighting the need and goals for Federated Learning Standards
- These span release announcements to research that builds on OpenFL
- ML privacy meter was a highlight from the OpenFL 1.5 release
- EDEN compression algorithm (VMWare)
- Other ideas:
- Starting with GaNDLF (UPenn) and how to make these models run in a federated way with OpenFL Blog highlighting the need and goals for Federated Learning Standards
- Other ideas:
- Create pipeline for contributors to become eventual project maintainers (akin to a technical promotion path)
- For future TSC members:
- Have a recommendation about contributing code back to the framework
- Not strict but recommendation
- Being hands on with implementation will help in setting the technical direction
- Micah: Standardization will help bring in a new community (and combined PR people) pushing cross contributions between frameworks.
- Incentivizing research:
- This is a role that Intel Labs has helped with. OpenFL maintainers should prioritize this to the extent that they can
- Not just writing blog posts, but helping researchers with a well defined tutorial that accompanies the blog would be great for them (Andrew Trask (head of PySyft)) puts a lot of personal effort into tutorials because they are so important for community building). This is a role that Intel Labs has helped with
- . OpenFL maintainers should prioritize this to the extent that they can
- Daniel: We should move from discussing standards in google doc and have some version control. Some community examples that have a well defined standards proposal process. :
- Python PEP: https://peps.python.org/pep-0000/
- Kubernetes enhancement proposals: https://github.com/kubernetes/enhancements/blob/master/keps/README.md
- Flower Lab: Work has continued on Baselines
- FedAvg, FedProx was just merged
- There is some work in taking research code and bringing it to the format of baselines (this is expected)
...