Explicit policy about submodule contributing about pelican-plugins

[justinmayer]

To clarify a bit...

We hope to soon get to a point where Pelican plugins are Pip-installable and hosted on PyPI. Moreover, we encourage plugin authors to request a repository for their plugin under the new pelican-plugins GitHub organization. That way, the Pelican Dev Team, as well as other members of the community, will be able to assist with issues, code review, and managing pull requests. To see a model for how this would work, please have a look at the Jazzband GitHub organization.

This has been discussed previously (see: getpelican/pelican#1488 and getpelican/pelican#1914) but has yet to be enshrined in our documentation. Once we start actually moving existing (and new) plugins and themes to the respective new organizations, I'm sure we'll have more canonical instructions and guidance in place.

In the interim, I think the best approach is to continue with the current monolithic repository. Hopefully we'll make more progress on this endeavor in the months to come.

[Lucas-C]

Related to #39 & #213

We now encourage dedicated repositories, with packages published on Pypi, instead of submmodules

[justinmayer]

Pelican plugins are indeed now Pip-installable as of Pelican 4.5+, so if you would like to help migrate legacy plugins to the new format, please create an issue at the legacy monolithic Pelican Plugins repository and ask a maintainer to create a corresponding new repository under the new Pelican Plugins organization and invite you to join it.