[Feature Request]: This project needs more Collaborators

[wywywywy]

Is there an existing issue for this?

• [X] I have searched the existing issues and checked the recent builds/commits

What would your feature do ?

Allow more people to review & approve PRs

Proposed workflow

Recruit and approve experienced engineers to help reviewing & approving PRs

Additional information

@AUTOMATIC1111 has done a fantastic job. Without @AUTOMATIC1111 we wouldn't be where we are today.

But @AUTOMATIC1111 is only one person - and a busy one at that. Moreover, this project has now grown so much that it's almost unfair to ask a single person to handle it all.

There are now over 100 open PRs waiting for review, so it's becoming a bottleneck.

So, in short, we need more dedicated people to have Collaborator access to go through the backlog of PRs.

[aliencaocao]

Second this.

[Cyberes]

We also need a group to close pointless bug reports. Bug reports are not for tech support.

Issues with "RuntimeError: CUDA out of memory" in the title should be auto-closed.

[jn-jairo]

For me the point about PRs is that we don't know what auto wants or not inside this project, some PRs may be good and with a correct code but auto just doesn't want it.

I have no idea what plans auto have to this project, so I cannot decide what to accept or deny.

Part of the problem was already solved by allowing extensions, so instead of requesting new features people can create a extension for that, just the core updates requires to be done here.

Recruit and approve experienced engineers to help reviewing & approving PRs

At the end it is auto's project alone and we just help it, it doesn't even have a clear license, so it is not clear that it will remain open or if auto will make a closed version and abandon this one.

For more experienced engineers to want to help here they would want to be sure their free help will remain open and available for the community or they would want to be payed.

I love this repo, but for big things I would rather contribuite with the InvokeAI because they have a clear license.

[ClashSAN]

you all are well-respected and have been working with this repo awhile, what is "approving PRs" to you? Closing related issues when complete?

If you want to add wiki documentation, close PR, close issues, that's what collaborator could do. For old PR's I think auto wants to eventually go through those himself, so even though at this point old PR's won't work, the potential idea remains "open" until looked at. the amount of issues rolling in was worse a few months ago, it's much better now. if you can confirm an issue, let's add "bug" tag to it.

I've had thoughts about a pattern of documenting new features added weekly through a wiki page, so an informal changelog. but that could be a nusiance and wasted efforts. All we may need for this repo to thrive are all (or 80%) of the bugs fixed, then it can rest.

[aliencaocao]

I think its more about the issues. Many of the issues I saw are either due to user's fault or a completely different downstream project that happen to use this repo as a base e.g. dreambooth. Those should definitely not be raised here, unless it can be proven that this is a bug within this repo not in the downstream implementation. I have been trying to tell people to raise the issue elsewhere whenever I see such issues.

EDIT: to add on, there are many dangling issues that are either fixed already or the OP refused/forgot to provide more debugging details. Those should be closed too. With the current count of 1.4k+ issues it is impossible for any contributor to tell which is high priority or which is invalid. There should be a team doing some filtering and closing issues where appropriate. The nature of this repo enabled many people with zero knowledge in github or zero in programming at all to use SD, and while this is a very good trend, it also causes many to open duplicate/invalid issues or simply leave it opened even when it is fixed. For example, https://github.com/AUTOMATIC1111/stable-diffusion-webui/issues/5621.

[ClashSAN]

I love this repo, but for big things I would rather contribuite with the InvokeAI because they have a clear license.

I love this project, because it's funny. All your top collaborators/contributors look like they are from botnets, ridiculous names, eg: hentailord85ez, or just the 100% anime avatars, I really didn't think we'd get to see such hilarious drama either: whether it be licensing focused, drama from reddit, novelai, voldy situation, being called a malware distributor, 1.3 leak.. so much funny stuff happens, and i'm glad to know about most of it...

the story belongs on IH

It's also not in character to sell-out after having such a history like this. but using the diffusers library will probably be the best for commercial use.

[ClashSAN]

@aliencaocao i understand. It would be good for auto to grant you and others attempting clean the issues collaborators access, but even if he does not, I will try to find issues to close via your comments, if you want: commenter:username

[Cyberes]

@aliencaocao you're spot-on about the zero experience aspect. It's wild how many people have never even used git before SD came around. Zero experience with python, zero experience with doing anything remotely technical on their computer, etc, etc. Like some people can't even copy a command right.

I have no issues with that, it's totally fine, but it's something to keep in mind and makes managing this project very interesting. Because of this there isn't an easy solution to the flood of bug reports and other issues stemming from the zero experience aspect short of hiring a team of community managers.

At a minimum we need a bot that goes through old issues and adds a stale tag.

lmao https://github.com/AUTOMATIC1111/stable-diffusion-webui/issues/5621 nuked his post after solving it