How we use Issues & Discussions

[ianscrivener]

With the move from Filips' private GH repo to MFlux-Community, we have started the move to GitHub Discussions.

Issues Refactored: I've done my best to sort out the old GH Issues into Open Issues, Discussions and have close off issues that have been resolved or expired. Apologies if I've made any mistakes.   

---

Should GitHub Issues be for Issues Only?

1. One view is that GitHub Issues should be only for bugs/issues identified as problems with the code.
2. GH Discussions seems to be a better place for user support, questions, suggestions, feature requests, model requests and discussion...

---

New Models

• We can expect to see many new models emerging over time. IMO we don't want to clutter MFlux by trying to support ALL models.
• IMO a new model that MFlux does not support is not an issue - it should be suggested model in GH Discussions, and the MFlux-Community & maintainers can decide (vote?) on if the new model should be supported or not.

---

Feature & model support discussion & prioritization

• Should we / how should we prioritize the features and models that we want to support?
• Should we have some kind of (monthly) feature plan?

[anthonywu]

appreciate you being the de facto community manager/lead.

[ianscrivener]

thanks Anthony...

[anthonywu]

a while ago I proposed a plugin architecture based on namespace packages

instead of adding common models N+1 to the repo, other repos/pypi-artifacts can "plug in" to the mflux.whatever namespace and when users install mflux and mflux-whatever, then the libraries just discover each other and work together.

This would be a more decentralized way to support all models and the perk would be each little projects can release at their pace, using their rules.

[ianscrivener]

I just want to call out that there's multiple levels of conversations that I feel we should have.

WHY

• Why does MFlux exist? What place in the open source AI image generation system ecosystem do we want to occupy? What is our purpose? What is in scope, what is out of scope?
• Who are our customers, our constituents? Other than ourselves... who are we building MFlux for?
• Are our target users humans or AI Agents?
• What do our end users really want from MFlux?

WHAT

• Should we go for quantity or quality? Should MFlux try and support every image & video model on HF OR should we just support the best ones and try to reduce friction and increase performance on a subset or the best models?
• Do we want to make the best & fastest AI image generation on Mac... or just good Python MLX AI image generation on Mac?
• If we had to choose... which is more the important part of MFlux - the CLI or the Python module system?
• Are MCP & SKILLS essential functionality... or a nice-to-have?
• Filip suggested a refactored to CLI interface... is that important?
• Now that MLX has good support for CUDA - should we also consider it to be a first-class citizen, alongside METAL?

HOW

• a plugin architecture
• DEV branch or namespaces

[ianscrivener]

Some thoughts

A couple of weeks ago, before committing to MFlux-Community, I spent a couple of days doing an audit of what exists in the ecosystem of local AI image generation for Mac Metal. What else is out there? Should I invest my time in MFlux? C++, Rust, Swift, other MLX/python projects (mlx-gen). Each tech stack has its pros and cons.

sd.cpp & mlx-gen are well worth looking at.

Also DrawThings, the core tech is opensource, surprisingly, it's neither Swift nor MLX. Liuliu has developed and opensourced, ccv/nnc, s4ncc & dflat. DrawThings renders faster than MLX - pretty impressive for a one-man band!

So why Python?
C++ and Rust are of course faster than Python... and Swift plays really well in the Apple ecosystem - especially iOS & iPadOS. But:

1. Performance-wise, all of the above are constrained the same by Metal & GPU... and that is perhaps 98% or the time/size/memory... So perhaps the actual coding language doesn't make much difference for this type of workload.
2. Python without a doubt is the default language of AI and ML.
3. Even dumb LLMs have a pretty good understanding of Python... and a few test have shown that Python is more token-efficient than statically typed languages like C++ and Rust.
4. Python is a more more newbie and end-user friendly... a more accessible language.

The drawback for Python is that it's harder to integrate into desktop apps and mobile apps.

Personally, Image quality is #1. I am motivated by great performance and smart/rich functionality. I'd rather have a tool that supports three models and is faster than any other tool... than a tool that supports 10 models but is slower.

That's why I'm interested in optimizing quants for text_encoders and transformers separately. NVFP4, TAEF & Teachache. mlfux-gerrate-server... perhaps using TAEF on CPU. How to use NPU? What can MFlux borrow from DrawThings? How to shape MFlux for convenience & optimal performance on Macs with 16Gb, 24Gb, 36Gb memory?

For a genius ML researcher/developer, downloading 40 or 60 gigabytes.. then converting a model to test it is fine. But for the average Mac user, that's a deal breaker. That's why MFlux-Community on HuggingFace was absolutely essential IMO.

IMO mflux-generate-zimage -p "a puffin" should check what hardware it's running (Metal or CUDA), the available memory etc, download the optimal model for that environment and just work.

Or maybe "Hey Siri, use MFlux and zimage model to generate me a photo of a puffin sitting on a cliff".

"Simplicity is complexity resolved" - Constantin Brâncuși

[fxd0h]

A process idea for this thread: when a new issue lands, whoever is going to look at it self-assigns and drops one line saying what they'll check. The commitment is evaluation: reproduce it, report what you find, then keep it or unassign. No board, no new labels.

The assignee field becomes each maintainer's actual backlog, and whoever reported an issue sees that someone took it instead of guessing. #469 has been open since July and #312 since January without an owner. Stale assignments get cleared after a week of silence, by yourself or by anyone.

We already do this when we remember to. This would make it the default.

[ianscrivener]

Good idea... a simple ticket assignment system

IMO adding labels would be good "assigned" & dev_name

• UX: gives the issue submitter & MFlux all users that message MFlux is responsive and alive... that someone's looking at their issues.
• DX: busy maintainers can skip already taken issues and focus their precious time on the ones that haven't been assigned.

Do you have any specific reasons to not want labels?

[fxd0h]

Do you have any specific reasons to not want labels?

No, not really.