Pelican: Move contrib, plugins & themes, to dedicated accounts

[naturallymitchell]

In order to provide these benefits to Pelican contributors:

• greater developer control over own projects
• lower core project maintainer overhead
• per-project git logs
• per-project issue queues
• per-project measures and graphs
• per-project maintainer oversight for approving patches and adding collaborators
• per-project starring and watching
• and many more...

I propose we use these github accounts getpelican-plugins & getpelican-themes for providing individual repositories to each project.

Summary:

• getpelican/pelican-plugins/* -> getpelican-plugins/*
• getpelican/pelican-themes/* -> getpelican-themes/*

[naturallymitchell]

Ok. They're ready.

[naturallymitchell]

Note: A quick and easy way to clone each repo in bash.

wget https://api.github.com/users/getpelican-plugins/repos
`while read line; do git clone $line; done < <(grep git_url repos | awk -F'"' '{ print $4 }')``

This also works for organizations by replacing "users" with "orgs" in wget.

[naturallymitchell]

Sill learning github.

[naturallymitchell]

@avaris: In terms of a supporting workflow, I imagine it could work something like: user with a new project asks a maintainer or posts an issue and provides their project's name. Then a maintainer, either 1) on github's website, 2) using github's api, or 3) using a cli-app, would then set it up for them. A highly simplified approach might look like: contrib [user] [project] [account] ie, contrib Avaris foobar plugin to start you up a repo called 'foobar' in pelican's plugins account, or contrib Avaris jungle theme to start you up a 'jungle' project in pelican's themes account.

There are about 5 cli github tools with varying levels of functionality that we could leverage to get a usable workflow up and running quickly, and I can provide further reports on those.

What this process could do is create that foobar repo, create a foobar-owners team, starting with its project creator as its sole owner, and perhaps, another foobar-contributors team with its owner as having admin access to add contributors with only write access, as needed.

[avaris]

Maybe I'm missing something but right now, if a creator wants to control the workflow of their plugin, they create it in their own github account and add it to pelican-plugins via submodules. Isn't this essentially the same?

[naturallymitchell]

I see a few advantages of using contrib accounts:
1) git submodules stop at a certain commit-id, whereas this defaults to putting followup commits into users' hands
2) git submodules add complications for both users and maintainers, eg learning how to set it up and with ongoing merge requests and commits
3) an automatically updated all-projects-list with modifiable descriptions (ie, like https://github.com/collective & https://github.com/purescript-contrib ) would have more robustness than copying and pasting to README.rst at first merge

[naturallymitchell]

GitHub™, Inc.'s staff marked these accounts as spammers then restored them, so we can continue using and testing with them..

[leotrs]

Did this ever get support? The old repos are still getting all the contributions, while the new ones seem deserted.
@mitchtbaum

[liltinkerer]

Is this project stalled?

[justinmayer]

This is still planned. Will hopefully get this done in 2017 2019. 😅

[justinmayer]

Very sorry to everyone for the delay in getting this endeavor going. In an effort to move this forward somewhat, I have taken the liberty of creating the pelican-plugins and pelican-themes organizations, which will eventually be the home for individual plugin and theme repositories.

Many thanks to @naturallymitchell for kick-starting this process. Much appreciated! 🎉