Description of problem: Current Groups in Zanata is Project Version Groups. There is no way of grouping projects. Organizations = groups of projects Groups = project version groups [releases?}
Update from meeting: Initial Plan: - Users create an Organisation as maintainer/owner - Maintainer/owner can add/remove other users as maintainer/owner - Can only remove self if > 1 maintainer/owner - Adding a project to an org allows all maintainers/owners of the org to maintain the project - existing Project Maintainers are removed from the project - Projects can be part of only one organisation - Projects can transfer ownership between orgs and users (especially needed when namespaces are added) - Organisations list page (part of browse eventually) - Organisation available in global search (along with groups and languages) - Organisations added in the menu bar (until browse menu item is available) - Project has an indicator of Organisation membership (This will be more obvious with namespaces) - We can add this near the project title once we only allow 1 owner of a project (with everyone else being maintainers/collaborators) - Org ids cannot be same as usernames Next revision: - Include teams - Allow multiple teams with custom permissions per team - Teams can be assigned to each project an organisation owns - A project can have multiple teams - Have a way to list all projects for a team from the org page I am hoping to get even more detail about this bug. It will need to be broken down into smaller bugs.
This sounds great base. Let me allow to picture an example. (In reply to Luke Brooker from comment #1) > Update from meeting: > > Initial Plan: > > - Users create an Organisation as maintainer/owner A user who can create an Org should be able know current size of Org and possible growth which can impact the server resource/performance and the people translators. Naturally it should not allow every user to create Org easily. This user is kinda org admin? Who is eligible? What is the condition? For example, Fedora, I may prefer to have ORG per development cycle. One ORG follows one development cycle. Any projects follows this particular development cycle join this ORG, but basically not allowed to create separate ORG without clear reason. Otherwise some projects just want to create own ORG, and over time the number of ORGs will become uncontrollable.
Hi Noriko, For your situation, the way to handle that would be with teams inside of an organisation. Users can be assigned to teams and each team can be assigned to multiple projects. This doesn't mean this is our final solution though, as to get this right (especially in Fedoras case) it will need further thought and discussion.
(In reply to Luke Brooker from comment #3) > Hi Noriko, > > For your situation, the way to handle that would be with teams inside of an > organisation. Users can be assigned to teams and each team can be assigned > to multiple projects. > > This doesn't mean this is our final solution though, as to get this right > (especially in Fedoras case) it will need further thought and discussion. What's difference between team and organization? It looks like we need to implement team before organization. Otherwise according to what I perceive, FESCo is not going to like the idea of thousands of maintainers can push and pull one another projects.
Ding, as I understand it an Organization is a group of projects, while a team is a group of people. An organization will eventually (**not part of this initial feature**) have multiple teams all with potentially different permissions over the projects of the organization. I share your concern over permissions for projects in an organization, but there is still some discussion to be had on that front and I think we haven't arrived at a final implementation decision.
Migrated; check JIRA for bug status: http://zanata.atlassian.net/browse/ZNTA-320