On Wed, Apr 18, 2007 at 10:00:36AM -0700, Stephen Lau wrote: > I'd be more comfortable if this said: > "The OGB temporarily designates a role..."
Well, the policy itself creates the role. The designation of someone to fill it is explicitly temporary. > While Eric has performed this in the past (and may agree to perform it > in the future until such time when it becomes automated), it's not a > guarantee. We could (and maybe should?) open this up to be a position > that someone else can fill if Eric wishes to decline filling the role. One of the things I'd like to understand is what infrastructure changes, if any, would be required to permit an arbitrary Participant (or, better still, a robot) to perform these functions. Would you feel better if section 3 were marked '(Informative)'? > Is this the current mechanism whereby Communities endorse Projects? Or > are we talking about additional webapp development needed? The current one; as Alan pointed out, it lacks a notification mechanism. I'm trying to avoid the pitfall of writing a policy based on the limitations of the existing infrastructure. That hasn't been working well to date. If we need changes to implement the policy efficiently, let's figure out what those are and find a way to make them happen. The policy should reflect the process we want, not the tools we have. > Perhaps we should give a reference policy for communities to follow? Is > the OGB going to reserve the right to approve or reject community > policies? i.e.: what if a community decides to set an arbitrarily > restrictive policy: "Project proposals must include $50 bribes and/or a > 6 pack"? Sec. 8.6 limits the ability of the OGB to require a Community Group to act in a particular way, but it also allows appeals. If a Group imposed unreasonable or inadequate requirements, we'd be well within our rights to take one of the remedial actions described there. -- Keith M Wesolowski "Sir, we're surrounded!" FishWorks "Excellent; we can attack in any direction!"
