Organizations, accounts, governance and commit rights

Gouvernement ouvert Open-Source Contribution Policy
#1

Usually, administrations have an organization account to centralize all their newly contributed projects. Members of this organizations are usually only the civil servants working for that organization.

  • Civil servants might create a small f/oss tool under their personal account. When should it be moved to the organization account?
  • When should a project be moved from the administration’s account to an organization account that is not only controlled by the administration? Is the nature or type of project relevant?
    • Best would be to use existing free/open-source organization
    • If none is interested what should the newly created organization respect?
  • What about inventory needs?
1 J'aime
Open-sources licenses choice
#2

This is probably part of a wider discussion (do you use your company email or personal email address on a public forum, for instance)

At Fedict, we have indeed an organizational account on github (https://github.com/Fedict/), and I’m also using my personal account. Although not carved in stone, the github « rule » that I use is that I use the organizational account for projects that are work-related, however small. So I use my personal account for things like Coursera-assignments and hobby-projects.

Sometimes I voluntarily « promote » a project from personal to organization (never the way around), because some hobby project becomes somehow interesting for my organization.

But it really depends on the project for existing projects:

Fedict also has account(s) on drupal.org for hosting Drupal-related modules and distributions. Now the Drupal.org community encourages individual accounts (instead of organizational accounts), to make it easier to give credit to individuals (and to check code quality I guess).

So I think it boils down to:

  • use the organization account if it has the potential to be reused and/or is done during work
  • make sure there are at least two people that have full rights to a repository (just in case someone is not available / leaves the organization etc)
  • if an inventory is desired, simply create a page / website / document in your organisation listing the links to the different repositories (and make sure the list is maintained / updated)
2 J'aime
#3

Hello, I would think that a project should be on the organization account if the organization has the will to endorse it. That is mostly, is ok to maintain the software, is ok that it’s published in its name. This also means project maintainer will be someone of the organization, even when original creator leave organization.
Sometimes the organization want’s the project to be endorsed by some other organization (be it an open-source software foundation, or some other informal organization), because it feels it is more a contribution to the eco-system. I think most of the time those thinks are clear after a discussion between, the main developer, the organization and eventually part of the community.

1 J'aime
#4

Isn’t this question too detailed for the policy template?

1 J'aime