Setup a forked code repository (Task #29)

The fork should be in a new github organization named directly after the new project name.

Why a Github organization? What benefit would the project get from them over a normal user account?

It would benefit from letting all of us keep our existing github accounts, and giving us a central place to manage multiple repositories. If we add/remove committers we can simply give them commit access with a flip of a switch. I'm sure there are some other reasons as well.

That said, we can get all of these and more simply by running our own git 'master' that is integrated with redmine (hey look here's a howto) which would be trivial to setup and probably has some benefits as well (custom hooks and such)

Thanks Muntek, I have no experience with Github's organizations. The only things I care about are:

• multiple repos - official Bluemine repo and official plugins
• easy contributor access
• commit hooks

I'm thinking about some integrations with Github but we should work out the commit workflow first.

Anyone else have experience with Github Organizations? Does FinnLabs use them?

Ww use it at finnlabs. All the stuff that is working with a normal user account also works with an organistion (minus the login stuff). The organization can have public (and possibly private) repositories and its members can do everything with them a normal user can do to his repos in his account. On the github website this is done through a "context" button. Thus you can decide that you (eg. edavis10) now wants to see stuff from the organization or from the normal user's perspective.

The main advantage is that you can assign rights here. There are rights for "pull only" (doesn't apply to us), "push & pull", and finally "push & pull && administration". That means, each "admin" member can add and manage members and change repository data while normal users can commit to them.

As Muntek said, you get more granularity and can keep your normal github accounts. Also, you don't need another one of those "master passwords" floating around.

@Eric, please read the blogpost on the topic I linked in Note 2.

Regarding the private git master: I'm currently against it as me still would need to incorporate the github workflow into ours to allow broad participation of people. For custom hooks, github allows those callbacks we could use to either update our own copy and run hooks there or notify a webservice to do the stuff. There is even a plugin floating around for updating redmine repos (although this is kind of crappy and has design and security issues)

Only the Intrastructure rteam should be in the owners team.

I'm currently unsure though, if there is a difference between a "normal" team with admin rights and the owners team (e.g. towards changing billing details and deleting the organization), but I guess there is. If so, the "normal" members should have at least push/pull rights and I guess admin rights too to create new repos.

Holger Just wrote:

I'm currently unsure though, if there is a difference between a "normal" team with admin rights and the owners team (e.g. towards changing billing details and deleting the organization), but I guess there is. If so, the "normal" members should have at least push/pull rights and I guess admin rights too to create new repos.

I think "owners" are the only ones having administrative control over the organization, not sure what "pull, push, administrative" can do, but I guess at least manage all repos in that team… In fact, I kicked you from owners and put you in a team with the highest permissions but without a repo, see what you can or cannot do.

More Infos about Orgs here: https://github.com/blog/674-introducing-organizations , not much Info about that specific topic though.