Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move contrib, plugins & themes, to dedicated accounts #1488

Open
naturallymitchell opened this issue Oct 1, 2014 · 11 comments
Assignees

Comments

@naturallymitchell
Copy link
Contributor

@naturallymitchell naturallymitchell commented Oct 1, 2014

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:

@naturallymitchell naturallymitchell changed the title Factor out Pelican contributions (plugins & themes) Separate contrib (plugins & themes) to dedicated accounts Nov 6, 2014
@naturallymitchell naturallymitchell changed the title Separate contrib (plugins & themes) to dedicated accounts Move contrib, plugins & themes, to dedicated accounts Nov 6, 2014
@naturallymitchell

This comment has been minimized.

Copy link
Contributor Author

@naturallymitchell naturallymitchell commented Nov 12, 2014

Ok. They're ready.

@naturallymitchell

This comment has been minimized.

Copy link
Contributor Author

@naturallymitchell naturallymitchell commented Nov 29, 2014

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

This comment has been minimized.

Copy link
Contributor Author

@naturallymitchell naturallymitchell commented Nov 29, 2014

Sill learning github.

@naturallymitchell

This comment has been minimized.

Copy link
Contributor Author

@naturallymitchell naturallymitchell commented Dec 2, 2014

@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

This comment has been minimized.

Copy link
Member

@avaris avaris commented Dec 2, 2014

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

This comment has been minimized.

Copy link
Contributor Author

@naturallymitchell naturallymitchell commented Dec 2, 2014

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

This comment has been minimized.

Copy link
Contributor Author

@naturallymitchell naturallymitchell commented Mar 12, 2015

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

@leotrs

This comment has been minimized.

Copy link

@leotrs leotrs commented Aug 14, 2016

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

@liltinkerer

This comment has been minimized.

Copy link

@liltinkerer liltinkerer commented Dec 27, 2016

Is this project stalled?

@justinmayer

This comment has been minimized.

Copy link
Member

@justinmayer justinmayer commented Dec 27, 2016

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

@justinmayer

This comment has been minimized.

Copy link
Member

@justinmayer justinmayer commented Mar 15, 2019

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! 🎉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.