Adding an upper limit for 'smaller contributions' is a a good idea, but since there is no public tracking about ones contribution status it is difficult to manage your time and resources spend on contributing to webpack/webpack-contrib. Contributors should therefore be at least notified if the their (monthly) limit for payed contributions is reached and that further contributions won't be payed (with the intend to devote your time to something else instead). This encourages to manage ones workload/time within a range that is substainable for the individual and the project itself. A notification handles the substainable part on the individual side of affairs

Contributor proposal

Title of the existing project?

Currently https://github.com/webpack-contrib/uglifyjs-webpack-plugin,
In next week in my plan will do release terser-webpack-plugin, also i think we should take care about https://github.com/webpack-contrib/babel-minify-webpack-plugin.

Which contributors should be added to the project?

@evilebottnawi

Do the budget need to be increased to cover the new contributors?

I think no

Why do you think these contributors will help the project succeeding?

At the moment I'm the only one supporting this plugin

Any other comment?

Plan to create abstract-minimizer-webpack-plugin (which contains all the logic for cache, parallel, sourceMap and etc options). terser-webpack-plugin and babel-minify-webpack-plugin should extend abstract-minimizer-webpack-plugin with own minify function. This will allow you to spend less time supporting. Also it is allow to create new minimizer plugins for css/html/etc assets without copy-past code for cache, paralle, sourceMap and etc options.

Goal changes proposal

Describe your changes?

Merge webpack-command into webpack-cli to avoid confusing and duplicate development

Remove this.

Why are you proposing these changes?

There is plenty of room in the ecosystem for more than one CLI. Taking choice away from users for the sake of whatever you believe this will accomplish is ludicrous.

webpack-cli is quite frankly, poorly managed and a poor experience. It was a bad project when it was part of the core. It has been and continues to be a poorly managed and poorly architected project with a substandard user experience. Additionally, the main webpack org isn't managed nearly as well as webpack-contrib. webpack-command was created to escape the poor organization management and to address the myriad of shortcomings in webpack-cli. And even now, you have the primary maintainer of that project spending organization money to reproduce what webpack-command has already accomplished, and it's a personal affront that it's being directly supported by @sokra. If that isn't recognized as a prime, working example of poor management, then I don't know what else to tell you.

You may choose to defund webpack-command or not to support it, but you may not, under any circumstances, merge the codebase into webpack-cli. The level of which I and my efforts were mistreated, the absolutely abhorrent communication, and the back-room discussions held without my involvement on the future of this project were and still are unacceptable.

I would even go so far as to say I would be happy to have the repo ownership transferred back to my personal account and maintain it on my own.

As the author and primary contributor I do not consent to webpack-command being merged into webpack-cli.

I want to note for the record here that I gave @TheLarkInn multiple opportunities to have an actual, real discussion with me about this, yet no discussion ever occurred. I'm extraordinarily disappointed in the leadership of webpack, or general lack thereof. Without my consent, you're copying my work. And that would appear to go against the goal of "Be an example for a good sustainable Open Source project"

You all should know better, and should be better than this.

New project proposal

Describe your proposed project?

Development server webpack-serve and deps like webpack-dev-middleware and webpack-hot-client

What budget do you think is appopriate for the project?

Don't know, maybe 5k

Should there be any additional payment restrictions?

Don't know.

Which repos are affected by the project?

https://github.com/webpack-contrib/webpack-serve
https://github.com/webpack-contrib/webpack-hot-client
https://github.com/webpack/webpack-dev-middleware
https://github.com/shellscape/koa-webpack (i don't know why this project is not in webpack/webpack-contrib orgs 😕 , https://github.com/webpack-contrib/webpack-serve/blob/master/package.json#L68)
https://github.com/webpack/webpack-dev-server (maintenance only)

Which contributors should be able to work on this project?

I can, but I need at least one more contributor.

Why do you think the project is needed?

A lot of developers using dev server. Also it is part of projects like https://github.com/facebook/create-react-app and etc.

To which Short or Long Term Goals to the project contribute to (if any)?

Long Term Goals

Any other comment?

Repositories are scattered around organizations, which is not convenient for contributing, I think we should moving them to one organization.

Goal Changes Proposal

Describe your changes?

Add module types to webpack for basic building blocks of the web platform (URL, CSS, JS, WASM, HTML). Since JS and WASM are already supported, this issue is particulary concerned with adding URL, CSS and HTML module types to webpack

Why are you proposing these changes?

Currently URL, CSS and HTML need to be added via a loader for the javascript/* module type and therefore are converted to a JS Module. This additional layer is inconvienent (e.g extraction) compared to providing a separate module type with it's own Parser and Generator analog to JS and WASM

Project changes proposal

Title of the existing project?

webpack-contrib/webpack-serve

Describe your proposed changes?

Make it clear for the users that the work continues at shellscape/webpack-serve. I imagine the contrib repo could become private unless there's a better way.

Why are you proposing these changes?

Now the status of webpack-serve is unclear to the users. It's actively developed and recently gained a major bump in terms of functionality as webpack-plugin-serve was integrated to it.

Any other comment?

I know there may be some politics/hard feelings behind the current situation. That said, it would be better for the user base overall too find a good solution for this so it's clear that the development is going on in another place even if unofficially.