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
