On Thu, Sep 17, 2009 at 11:53 AM, Jim Grisanzio <Jim.Grisanzio at sun.com> 
wrote:
> John Plocher wrote:
>>
>> ? ?1) A new contributor is identified in a collective.
>>
>
> No, not identified. A new C or CC is voted on by the CG`s CCs. All the
> important decisions about CCs are made at the CG level by other CCs.

Give me a break, Jim.  This is exactly how the community's voting
process works - it starts when someone in the community identifies a
potential new [C/CC] for that community and suggests a vote be taken
in the community.  I'm not suggesting anything sinister or malign
here, or asserting that the OGB is out to eat the world.  Geeze.

>> ? ?2) The facilitator in that collective [does some web stuff]
>
> I don`t know what the web stuff is.

I was simply referencing your suggestion that:
    "then the CG Facilitators enter the appropriate data into
     their CG Electorates in Auth."

>> ? ? ? ?and a new contributor is born.
> No. My impression is ...

OK, so let me try again, in excruciating detail to make sure we are on
the same page:

Jim's proposal layered on top of the current process is:

 1) A new contributor is identified in a collective.
    The community's voting process starts when someone in
    the community identifies a potential new [C/CC] for that
    community and suggests a vote be taken in the community.

    The community votes on the nomination using whatever
    voting mechanism is appropriate.

     Assuming that the vote is positive...

2)  The facilitator in that collective has to then go to
     ogb-discuss to alert the OGB that this vote for a
     new C/CC has occurred.

     The OGB makes sure the new CC signs off on the
     policy that this current OGB put in place to make
     sure that new CCs realize that they should vote
     with their new CC status.

  [Jim's addition]
     DELETE:
     3) The Secretary puts the new name into poll/Auth.

     ADD:
     3) The OGB Secretary responds with an "approval email"
          to OGB-Discuss and/or the Facilitator stating that the
          OGB's processes have been successfully followed.

          The Facilitator goes into Auth, and for each candidate
          modifies their official database entry to show the
          promotion
   [end of Jim's addition]

4)  the Auth application and the official poll database shows
     this person as a new C/CC.

My counter proposal (with several implementation suggestions
that are simply suggestions) is

 1) UNCHANGED

2)  REPLACE WITH:
     The facilitator in that collective interacts with the
     nominee to get their response to 2008/007.  The
     facilitator enters the appropriate data into their CG
     Electorates in Auth.  (extra credit for having text
     fields where the facilitator can copy/paste mail archive
     references to the above discussions)  The Auth web
     application notes that this Auth change still needs OGB
     Secretary approval. and adds the request to the
     Secretary's work queue.

     The Auth app could generate a message (or a
      daily digest or ...) for ogb-discuss that notifies the
     OGB and the extended governance community of
     these pending changes.

3)  The OGB secretary accesses the Auth web app and is
     presented with a list of all pending C/CC grants, along
     with a mechanism to
        Approve each request,
        Flag it as something that needs more attention, or
        Deny it.

     (I visualize this as a list of names with radioboxes and
     a Submit button)
     I would expect Denials to be rare indications of a process
     malfunction or an facilitator error, and Flags to result in a
     flurry of email to a facilitator or community requesting
     clarification.  Flags will eventially migrate to Approvals
     or Denials.

     Things requiring clarification may be "no obvious record of
     a vote in the group's mail archives", "a  -1 vote by an existing
     CC", "no indication that the candidate agreed to 2009/007",
     and the like - i.e., process irregularities.

     Once a nominee has both the facilitator's and secretary's
     "approval", the Auth application changes the official database
     to include this person as a new C/CC, and removes the name
     from the work queue.  Denials simply remove the name from
     the queue.

     The Auth app could generate a message (or a
      daily digest or ...) for ogb-discuss that notifies the
     OGB and the extended governance community of
     these new changes.

4) UNCHANGED


  -John

Reply via email to