Derek Cicero wrote: > Jim Walker wrote: >> 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. > > A C in a CG can edit pages XWiki. The mechanism by which someone becomes a CC > has nothing to do with any application that polls the Auth interface for role > status.
Derek, This document directly ties the CC role to CG website admin rights. Therefore, if I want CG admin rights, I must go through the CC approval process outlined above. http://opensolaris.org/os/community/web/transition-roles-collectives/ >> 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. > > Are any of those people not C's? The old "Leaders" are now CC's and C's. Is a > contributor that you want editing a web page in a CG not a contributer? As I described, in some cases, it is desired by CGs to grant full admin rights, not just edit rights to non-CCs. In addition, some CGs will want to limit admin rights to a few people. Having 50+ admins isn't normally a good idea. >> 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. > > Auth simply stores the data. That information is available via the interface. > Are you saying that everyone that uses the Auth interface has to have > approval from the OGB about how their application provides access to the > data? No. > Or that no one can use the CC roles in any way to provide access as > this might confuse them? Sort of. Using CC roles for access control causes all the issues that I stated above and is in no way required by the Constitution, and should not be done to kill two birds (tracking and access control) with one stone. Cs should not be used for access control either, since many communities follow the same approval process as CCs and they can have similar issues as stated above, and we would be in essence granting Cs editor rights for life per the Constitution. > The Constitution says nothing about how applications may use a role listed in > Auth to provide access rights. Exactly! This statement is false: "NOTE: The only roles available are those defined in the OpenSolaris Constitution." http://opensolaris.org/os/community/web/transition-roles-collectives/ We need to track CC and Cs per the Constitution, but we are not required and should not use CCs and Cs to control website access rights. We have been using "Leaders" in CGs for years which is fine. Admin and Editor roles are fine too, but we need to keep them separate from the C and CC roles, otherwise we get into trouble as stated above. The website community of all groups should be aware of the importance of limiting admin rights to only those people who truly need them. As mentioned before, I recommend that two new website roles be added to CGs (Editor and Leader) to eliminate the above issues. And so that the Contributor and Core Contributor roles are only used in a manner consistent with the Constitution. Cheers, Jim
