Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Deeper guide: FL algorithms, FL setups, and worked sketches beyond MNIST

Open
  • Is something wrong?
#240 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
48/100
Issue type
Documentation
Clarity
Clearly specified
Activity status
Active
Tech stack
python
Domain
documentation

Research direction

Start with Documentation/public/what-can-be-trained.md and services.md, then inspect client.py and aggregator.py to map the listed algorithms and FL setups to the train → audit → aggregate loop. Keep tested behavior distinct from untested sketches, and cover evaluation beyond MNIST. Done when the companion page is linked from both existing pages and gives model owners the requested service map and two non-MNIST sketches.

Written by the indexing model from the issue text.

Description

documentation good first issue

Related: issue No. 157, PR No. 189, P3-DOC1, P3-DOC4

Why this would help

Issue No. 157 produced Documentation/public/what-can-be-trained.md, merged in PR No. 189. That page deliberately stays short and separates what has been tested from what is only possible. The proposed outline on issue No. 157 also had deeper sections that weren't shipped. A model owner who already knows FL can't yet see how a particular algorithm or FL setup maps onto DIN's train → audit → aggregate loop, or what a non-MNIST task would look like in practice.

Suggested next step

Write a companion page for readers who want more detail, linked from what-can-be-trained.md and services.md. Keep the tested-vs-possible labeling the current page uses, and cover:

  • FL algorithms: how FedAvg, FedProx, FedOpt (FedAdam/FedYogi/FedAdagrad), SCAFFOLD, FedNova and q-FFL fit the GI loop, and which service file each one touches (client.py, aggregator.py). Also how Byzantine-robust aggregators (Krum, trimmed mean, coordinate-wise median) sit alongside auditor scoring.
  • FL setups: horizontal (the default), vertical (entity alignment, split-model services), heterogeneity-aware (HeteroFL/FjORD-style sub-models), personalized, and federated transfer learning. For each, what changes in the services.
  • Worked sketches, each clearly labeled as untested:
    • a FedLoRA/FedQLoRA LLM fine-tune where only adapter weights move through IPFS
    • a tabular regression model with its own scoring function
  • How results are evaluated beyond MNIST: choosing a held-out test set and a scoring function that fits the task, and how that relates to auditor/BlockFLow scoring.

Expected outcome

A model owner can see which service changes their algorithm or FL setup needs, and has at least two non-MNIST sketches to start from. Nothing untested is presented as supported.

Turning any of these sketches into a tested reference implementation is a separate task.

Dominant language
Python
Stars
4
Forks
7
Avg merge
3d 5h
Merged PRs (30d)
34

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from InfiniteZeroFoundation/DevNet

All issues in InfiniteZeroFoundation/DevNet

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.