Derek Cicero wrote:
3) Specific access rights for XWiki
XWiki has chosen to utilize the existing roles as provided in Auth and
map those roles the editing rights in its application. I believe this is
the fundamental issue that some folks are questioning. This has no
direct relationship to the architecture for Auth, but is rather an
integration decision on the XWiki side, one which will need to be made
by any developer that authenticates via Auth, of which XWiki just so
happens to be the first.
While I understand that not everyone agrees with how XWiki is assigning
privileges to role names, I believe it's been shown that the assignments
have been thoughtfully made. For example, if someone is given Core
Contributor status within a Community Group, it seems logical that they
are in a leadership role and therefore should have leadership privileges
across the associated sub-systems on the site. The alternate possibility
of being made a Core Contributor and then having to request, and be
assigned, specific privileges similar to that role, within each
application, would not seem to scale from a management perspective.
Derek,
Using the current Constitution as a guide to map Xwiki access
privileges is not a good idea, and the OpenSolaris Constitution
does not require this. Having a CC or anyone make a simple
request to a Xwiki leader to get admin rights is a small price
to pay compared to the impact it can have (see below).
Here's a short list of issues that are caused be combining the
Constitutional Community Group (CG) Core Contributor (CC) Role
with the website admin role:
1. Delay and Many People Involved in Granting CG Xwiki Admin Role
Unlike Projects and User Groups where any leader can simply
grant vetted team members the admin website role, CGs will be
required to go through the formal CC approval process which
takes a minimum of 72 hours not including the time it takes
for the CC sponsor to prepare and communicate the CC candidate
information for voting. In addition, more time is needed to
verify the newly minted CC understands their voting
responsibilities per OGB_2009/007 and this information is
communicated to the OGB. Not only does the process normally
take around a week at the minimum, it involves all CG members
and the OGB in terms of email communications alone.
2. CGs Can't Delegate or Control Xwiki Admin Role
Many CGs choose to delegate webpage maintenance to users that
don't otherwise make significant contributions to a CG. This
is done for many reasons including, leveraging individual user
admin skills across many CGs, allowing CCs from other CGs to
maintain selected CG webpages that have overlapping topic areas,
or the CG definition of significant contribution simply doesn't
related to website admin skills or time to perform website admin
activities. For example, the ARC CG only has current or former
ARC members as CCs. PMs and others would not be able to maintain
the webpages. In addition, many CGs including the ON CG only
grant a small fraction of its CCs webpage admin access to better
control webpage content. CGs need the freedom to decide who
should be CCs without artificial website constraints.
3. Role Overloading Causes Role Dilution
Having the CC role used for both governance and website admin
purposes weakens both roles. We can end up with website users
being promoted to CCs to achieve short term website content
objectives who aren't interested in voting or otherwise don't
make significant contributions, or we can end up with CCs being
forced to perform webpage management that is better preformed
by non-CCs.
The Contributor CG role has similar issues.
I will be clarifying this more in an OGB Guidance proposal that
gives the website team more latitude in how access privileges
can be organized so they don't impact Xwiki users and the
OpenSolaris electorate.
BTW. Please don't use the "it's in the Constitution line" unless
you can point to where it says Constitutional Roles must be
implemented as Website Rights.
Cheers,
Jim
--
Jim Walker, http://blogs.sun.com/jwalker
Sun Microsystems, Broomfield, Colorado
_______________________________________________
website-discuss mailing list
[email protected]
