On Wed, Jul 22, 2009 at 6:58 PM, Jim Grisanzio<Jim.Grisanzio at sun.com> wrote: > ... That draft specified a core set of roles from which > rights can be assigned. So, for instance, in the Contributor section of that > document it says this: "A Contributor may be given additional rights and > responsibilities, for example, to edit web pages, commit code to source > repositories, help moderate associated mailing lists, etc."
I believed then (and still do) that this says that some individual contributors may be given additional rights and responsibilities, not that all contributors are given every right and responsibility. That is, roles and abilities may be per-role or per-user attributes. To pick on one specific right, we need to be able to define, for a particular collective, whether the "edit website" right is one that is granted en-mass to all Contributors in the collective, or if it should be explicitly granted one by one on a per-user basis. The website collective may choose one way, while the security collective may choose the other. Unfortunately, that's not what was implemented, and the Auth architecture that Alan developed doesn't support per-user rights, only per-role rights. When we had this discussion last year, we were informed that the auth app wouldn't work the way we wanted, and there wasn't anything we could do about it - the decisions had already been made without community discussion or input. Somehow the bidirectional nature of "communication" and "community" got lost in this effort. -John
