> No is _easy_, the submitter often put hours of work into understanding the codebase [...] And maintainers will put many, many more hours into maintaining it.

> No is _easy_, the submitter often put hours of work into understanding the codebase [...] And maintainers will put many, many more hours into maintaining it. The submitter only has to interact with us once. We have to interact with their code for a long time. > How we structure work on these projects needs to be rethought [...] Most projects work the way you described (including Docker). You open an issue (and/or send a mail to the mailing list) describing the problem and a proposal to fix it. We then discuss the design and once the maintainers all agree with the design (more or less) you move onto creating a PR. Sometimes maintainers won't agree, and it'll take writing a PR to convince them that it will work (this does happen). But in most cases, the design is the important part (if it's a non-trivial change). The only counter-example I can think of is the Linux kernel. But that's an extreme example and usually a dummy PR will be enough to convince them to discuss your idea.