<i>The contrib directory is used as an unorganized (or, at best, lightly organized) bin of various useful things contributed by the community around the software, but which is not necessarily a good candidate for being a proper part of the software</i><p>I think this only works with the caveat that the core code is so well-designed that the user is capable of mixing contrib APIs with core APIs without requiring action on part of core developers.<p>For instance, TensorFlow v1 had a contrib directory that encouraged a lot of internal contributions and features to be added. This was initially quite nice due to the "batteries included" argument. However, the success of TF quickly resulted in a lot of bloat being added. There were competing ways to do the same thing within the default TF installation, and the worst part was that users expected contrib features to be interoperable with all other contrib features and core TF.
Would recommend using a dedicated repository. Can then give eager people commit access easily, and let them (help) manage contributions of more drive-by nature.<p>For this to work, contrib must be possible out-of-build/tree, which is a good thing, because it means there can be other "contrib" repositories as well - not just the single special directory in the mainline repo.
At the company where I work, if a team runs a widely depended on project, there's a better than even chance they'll host a contrib directory for exactly this purpose. A solid idea.