ChiliProject is not maintained anymore. Please be advised that there will be no more updates.
We do not recommend that you setup new ChiliProject instances and we urge all existing users to migrate their data to a maintained system, e.g. Redmine. We will provide a migration script later. In the meantime, you can use the instructions by Christian Daehn.
ChiliProject.org Roles (Task #83)
| Status: | Closed | Start date: | 2011-01-20 |
|---|---|---|---|
| Priority: | Normal | Due date: | |
| Assignee: |  Felix Schäfer |
% Done: | 0% |
| Category: | ChiliProject - Organization | ||
| Target version: | - | ||
| Remote issue URL: |
Description
Which roles should we use for the project? I'm thinking of modeling them after the Teams:
- Project Lead
- Development Team
- Issue Triage Team
- Documentation Team
- User Support Team
- Infrastructure Team
- Security Team
But this would make "joining a team" a process and I think having more self-organizing teams would be better for the project.
Or should we have:
- Project Lead
- Team Leaders
- Security Team - so people know who to talk to if there is a security issue (in addition to the email)
- Infrastructure Team - so people know who to talk to if there is website issue
Thoughts?
History
Updated by Muntek Singh at 2011-01-20 02:58 am
I vote the latter, we need to keep things flexible so teams and such emerge organically and remove any additional "pressure" joining teams or contributing.
Updated by Wieland Lindenthal at 2011-01-20 10:25 am
I think roles are no titles but define a set of permissions that you have within this installation. So a role name should make (more or less) clear what a person is allowed to do.
I think it is nice to name roles in a way that you could say "Holger is comitter". That sounds better than "Holger is development team".
I would suggest at least the following roles for dividing permission sets. A person can take several roles within a project:
- Administrator
- Committer
- Issue manager
- (Wiki) author
Updated by Felix Schäfer at 2011-01-20 10:42 am
I'd also favor a role-based permission set, i.e. have one role for people with some sort of decisional position (project lead, team leaders), one for contributors with commit rights, one for contributors without commit rights (might happen if/when we have infrastructure people who don't care about code or whatnot).
The different team responsibilities (infrastructure, code, documentation, …) are rather categories than roles.
So I suggest:- Leaders: full permissions in the project, commit rights,
- Committers: probably also full permissions in the project, commit rights,
- Contributors: whatever permissions are needed to take care of the forums, wiki, tracker.
Updated by Eric Davis at 2011-01-21 06:13 pm
Felix Schäfer wrote:
- Contributors: whatever permissions are needed to take care of the forums, wiki, tracker.
What about "Moderators" instead of Contributors? I want anyone to be able to become a Contributor just by helping out the project but that shouldn't give any extra permissions (and I don't want to have to add new users to that role for every accepted patch, etc).
Updated by Felix Schäfer at 2011-01-21 06:23 pm
Eric Davis wrote:
Felix Schäfer wrote:
- Contributors: whatever permissions are needed to take care of the forums, wiki, tracker.
What about "Moderators" instead of Contributors?
Sounds great.
Updated by Holger Just at 2011-01-22 01:22 am
- Security (if actually needed as a role)
- Development team / Committers
Also I like the moderators role with slightly extended rights on forums. Here we can easily have more people. As a staring point, all the support team people could be moderators.
For the leaders role mentioned above, I'm yet undecided. I absolutely dislike the name as it implies the distinction between us and them. I want to always be on eye-level with people. I would use the term contributors, for the people who have a permanent bound to the project and can thus do things like editing categories and locked wiki pages.
The infrastructure team doesn't need a special role per-se as these guys should have admin rights on the system. But we nevertheless introduce one as a way to tell people: These are the guys running the site. So merely a tag than a premissions/workflow role.
For the internal organization and security projects, I would propose to have an additional member role with full rights.
In general, I would like normal users to have some more rights than on redmine.org, e.g. editing own stuff in forums.
Updated by Felix Schäfer at 2011-01-30 04:31 pm
Regarding the "special" roles like security or administration: I don't think we need those as extra roles here if we make the mail addresses explicit enough/if we advertise them enough. I'd rather have people contact the mailing lists so that they reach everyone in the team rather than try to contact people directly, be it in turn or all at once. We could make prominent links to the team page/team's pages so that people can see who is in there though, for transparency and/or to give them the opportunity to contact people on IRC for example, but the primary means to contact those teams should be the mailing lists.
In light of this, that's what I think everyone can agree on regarding the roles in the ChiliProject project:- non-members: can post stuff and edit what they have written,
- moderators: same + permissions to edit stuff from others and locked wiki pages,
- committers: same + commit rights (might want to rename that to developers though?).
I'll implement that tomorrow evening (CET) if I don't hear any naysayers :-)
- Assignee changed from Eric Davis to Felix Schäfer
- Status set to In Progress
Updated by Felix Schäfer at 2011-01-31 08:45 pm
Felix Schäfer wrote:
I'll implement that tomorrow evening (CET) if I don't hear any naysayers :-)
See here, reopen if this needs more discussion. I can also provide a webshot of the page if someone not currently in the infrastructure would like to participate to the discussion.
- Status changed from In Progress to Closed
Updated by Felix Schäfer at 2011-01-31 09:13 pm
Ah, and while we're at it: do we need the manager/developer? Member might be needed for other projects.
Updated by Holger Just at 2011-01-31 09:21 pm
I vote for renaming Manager to Member (for special projects) and dropping Developer and Reporter.
Updated by Eric Davis at 2011-01-31 10:30 pm
Thanks Felix. A few thoughts from reviewing these:
- Remove Manger Role
- Remove Developer Role
- Remove Reporter Role
- Make people Moderators on the special projects
- Remove "Manage issue relations" from Non-Member. Issue relations are not logged so it would be easy for someone to change them without anyone noticing. (Ideally adding/removing a relation should create a journal entry but that's for later)
- Add "View Watchers List" to Non-Member and Moderator. I think the watchers is a good way to see how popular an issue is.
- Add "Move Issues" to Moderator. This permission is based more on what projects you have access to, so Moderators who can see other projects should be able to Move Issues.
- Remove all "Time Log" permissions
- Status changed from Closed to In Progress
Updated by Felix Schäfer at 2011-02-01 10:25 pm
Ok, I added/changed all of this save for the role for special projects: I've made a new one called "Member" (seemed somewhat willy to name it moderator…) which is a copy of "Moderator". I've also made everyone in ChiliProject a moderator except for Eric, there's still a few tasks open for the other committers ;-)
Edit: Eric, as you had the most comments, I'll let you close if you're OK with the changes too.
Updated by Eric Davis at 2011-02-02 01:32 am
Thanks Felix.
After looking at this, I think Committer could just be an empty Role that only has the "commit access" and "manage files" permission. That would simplify the Workflows a bit. But we can wait, it's not really an issue for now.
We will have to see how the Member Role works. I know it would make coding funky ;)
1member = Member.create(:project => @project, :roles => [Role.find_by_name('Member')], :user => @user)
- Status changed from In Progress to Closed