Keith M Wesolowski wrote: > 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.
Eric might be able to fill us in more here; but I believe it involves being a Jive administrator and a Mailman administrator. From my experience, the jobs done by the latter can be fairly easily automated (command line scripts to create new lists, etc. etc.). I don't know that the former can be easily automated though. > Would you feel better if section 3 were marked '(Informative)'? Yes, thanks. >> 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. Agreed; but the flip side of that argument is that until we have the tools/infrastructure to implement the policy we want - we can't have it. Yes, it provides impetus and possibly even priority to drive towards the tools needed to implement the policy, but that's not a guarantee on anything. >> 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. Good point; I think it might still be nicely to provide a reference policy for communities to follow. Even if it as simple as something like: - A majority of the core contributors must vote in favour - Only two core contributors must be a favour - A timeout period of one week is set - Dissenting votes automatically negate one positive vote - No clowns are allowed to vote Just something general for people to take into consideration when drafting their own community's policy. cheers, steve -- stephen lau // stevel at sun.com | 650.786.0845 | http://whacked.net opensolaris // solaris kernel development
