[KI-LC] Charter Approval Process Proposal

[Eve Maler]

Wow, I'm very glad to see Brett's read on the proposal.  As Secretary  
(am I "interim" or permanent at this point?), I'm certainly happy to  
be in the review role Brett has outlined below -- and it's obvious I  
need to study the operating docs closely to get more intimately  
familiar with them.

Whatever remains of the original proposal, I think it's best if we can  
do it as a light "profiling" (if you'll excuse the term) of the  
operating procedures and RROR, vs. a long numbered list.  We want to  
encourage people to propose charters, and also to do the work  
necessary to make the charters meet the minimum requirements.  A nice  
lightweight process description, plus lots of examples of approved  
charters and handy templates, will help proposers meet with success.

	Eve

p.s. I must send regrets for this Wednesday's meeting...  Once we  
settle into a routine meeting time these bumps will smooth out, I  
promise!

On Jun 1, 2009, at 7:10 AM, J. Trent Adams wrote:

> Bob and Brett -
>
> I'm digging the detailed read on the Operating Procedure and how it
> dovetails with these steps.  For the record, I don't think the LC was
> proposing a modification to the rules, but rather to clarify the steps
> from proposal to ratification.  The goal is to make it crystal clear  
> for
> a newcomer hopping on board, not rewriting previously well-considered
> documents.
>
> With that, it'd be great to hear from anyone else who wants to toss
> their opinion into the mix.  Otherwise, I'll take a whack at a clean
> rewrite (perhaps on the wiki) following this guidance.  I hope we can
> close it out on the next call in order to put the process into  
> practice.
>
> IMO - I hope this process can be written in accessible language that's
> devoid of the circumlocution that often characterizes a treatise
> authored by those skilled in the legal arts.
>
> Cheers,
> Trent
>
>
> Brett McDowell wrote:
>> Trent,
>>
>> I commend you on thinking through and laying out such a complete
>> process.  My observation would simply be that what you have outlined
>> is nothing more than the process the Chair is employing, which --
>> except when in direct conflict with bylaws or operating procedures  
>> (as
>> Bob has pointed out and I have added a few more in my comments below)
>> -- is simply under the purview of the Chair.  As the Acting Chair you
>> are simply being highly transparent by laying this all out for
>> everyone to review and comment on -- kudos to you!  But this doesn't
>> appear to be a "policy" in the sense that it is either an addendum to
>> the Operating Procedures or a new Controlling Document that the Board
>> of Trustees would co-approve with the Leadership Council.  So I
>> encourage you to carry on but not position this as a formal policy,
>> simply how you'd like to facilitate these approvals in accordance  
>> with
>> the Controlling Documents (which leaves many of the details to be
>> sorted out/decided by the Chair).
>>
>> That being said, I have a few more specific comments on your planned
>> process (see below).
>>
>> Brett McDowell | +1.413.652.1248 | http://info.brettmcdowell.com
>>
>> On May 29, 2009, at 7:28 PM, Bob Pinheiro wrote:
>>
>>>> From Step 13 below: "/Ratification requires a simple majority of  
>>>> the
>>> full LC/."
>>>
>>> Not to be picky, but the Bylaws define a Simple Majority as "/more
>>> than 50% of all those casting a vote (excluding abstentions)./" [Not
>>> 50% of the full LC]
>>
>>>
>>>
>>>> From Section 5.3 of the Bylaws: "/Approval for the formation of a
>>> Work Group requires approval of the Work Group Charter by a Simple
>>> Majority vote of the Leadership Council./"
>>>
>>
>> Bob is correct and this is very important.  These voting %'s were
>> chosen carefully and the "bar" was set rather "low" for approving WG
>> charters deliberately by the founders.
>>
>>> So I'd propose replacing Step 13 with "/Ratification requires a
>>> Simple Majority vote of the Leadership Council./"  [Meaning more  
>>> than
>>> 50% of those voting]
>>>
>>>
>>> Also, just to be clear, I'd propose changing Step 5 to read: "/A
>>> ratification vote date is set for no later than 30 days after
>>> notification of the LC Secretary/."  [So as to be consistent with
>>> Section 3.1 of the Operating Procedures: "/The Leadership Council
>>> must consider any properly submitted proposal for the creation of a
>>> Work Group and vote on it within thirty (30) days of its submittal  
>>> to
>>> the LC Secretary./"
>>>
>>> Now, if a vote on a proposed charter is delayed due to a deferral  
>>> (as
>>> in Step 12), does that mean that a new vote must still be scheduled
>>> within 30 days of the original date of notification of the LC
>>> Secretary, even if the next LC teleconference is after the 30 days?
>>> One way to be absolutely consistent with the Operating Procedures is
>>> to "notify" the Secretary only after the initial LC discussion takes
>>> place.  That would give the proposer 30 days to make any  
>>> adjustments,
>>> if there is a deferral.  If there is an immediate vote (and no
>>> deferral), the Secretary would be "notified" during the call, prior
>>> to the vote.
>>>
>>
>> The Operating Procedures are unambiguous on this point... the vote
>> must be taken within 30 days of the submission: "The Leadership
>> Council must consider any properly submitted proposal for the  
>> creation
>> of a Work Group and vote on it within thirty (30) days of its
>> submittal to the LC Secretary".  Note this only starts the clock if
>> the charter is "properly submitted" meaning everything was filled-out
>> correctly and it had appropriate sponsorship.
>>
>> It is not within the purview of the LC to change that requirement
>> without first changing the Operating Procedures (which requires a
>> co-approval by BoT).  Note: it doesn't mean the vote needs to pass,
>> but it must be taken.
>>
>>
>>> Bob Pinheiro
>>>
>>> J. Trent Adams wrote:
>>>> All -
>>>>
>>>> Following our call on Wednesday, we discussed formalizing a  
>>>> process for
>>>> ratification of WG and DG charters.
>>
>> Again, I think this is fine as a way of getting everyone on the same
>> page, especially in these early days.  But I don't see this as a
>> formal Controlling Document/Policy of the organization.
>>>> Based on the discussion, and in consideration of the Operating  
>>>> Policies
>>>> (section 3.1) [1], I've worked up the following proposed process:
>>>>
>>>> 1. The proposed charter template is filled out and
>>>>     sent to a staffer (e.g. Joni) to make sure it is
>>>>     filled out correctly.
>> That works for now, but once we have a LC Secretary all such charters
>> need to be sent to that elected person.  They can (and I would
>> recommend they should) be CC-ed to Joni as well.
>>>> 2. Once it passes staff review, the staff adds the
>>>>     proposed charter to the wiki and notifies the
>>>>     LC Secretary that it is ready for LC review.
>> I do not believe this is an accurate application of the Operating
>> Procedures or their intent.  The intent here is that the actual LC
>> Secretary will do this review and will be the point person for any
>> charter application.  This is because the review is simply to catch
>> administrative deficiencies with the charter.  For example, we
>> "failed" do properly perform this review with the VIP Tech charter
>> because that charter actually failed to meet one of the
>> requirements... which I see Iain is now fixing.
>>>> 3. The proposed charter is added as a topic to the
>>>>     next LC teleconference for initial discussion.
>> That depends on when the next LC teleconference call is.  Remember,
>> the LC must vote on the proposal within 30 days (and the intent is to
>> do so ASAP, which hopefully is less than 30 days under normal
>> circumstances).
>>>> 4. During the initial LC discussion, one of the
>>>>     LC Members volunteers to help shepherd the
>>>>     proposed charter through ratification by
>>>>     reviewing it as well as guiding the proposers
>>>>     through the process.
>>>>
>>>>     NOTE: I suggest that in case no one volunteers,
>>>>     the LC Chair will (respectfully) assign it to
>>>>     one of the members as deemed appropriate.
>> I believe this is left someone open-ended in the Operating Procedures
>> and I can appreciate why you are trying to close the loop and have a
>> firm plan in hand for helping applicants through the process.  So I'd
>> simply suggest a friendly edit that the Secretary is the default
>> person to work with all applicants and therefore if the work load is
>> unusually high (like right now!) I suggest the Secretary be the lead
>> on delegating this duty to one of the members of the LC.  This just
>> keeps the root responsibility with the Secretary which I think is
>> appropriate given they are the point of contact for all applications
>> and it's within their general scope of work.
>>
>>>> 5. A ratification vote date is set for no more than
>>>>     30 days from when the charter is accepted by
>>>>     the LC.
>>
>> This is another item that is simply in conflict with the Controlling
>> Documents.  The 30 day clock starts when the charter is submitted to
>> the LC Secretary.  This is deliberate.
>>
>> The other problem with this proposed modification to the process is
>> that it essentially creates an extra approval.  Now all charters are
>> approved twice... they are "accepted" then "ratified".  That is also
>> in conflict with the Controlling Documents.  Charters as simply
>> "approved".  They are assumed to be ready for approval when they are
>> submitted to the LC Secretary.  In truth, it is highly likely (as was
>> the case with all current charters) that these charters were worked  
>> on
>> by the staff *before* they were sent to the LC Secretary.  So it's as
>> much my fault as anyone's that we didn't have the VPI Tech charter
>> completed correctly for our first vote.
>>>> 6. It is written into the minutes that the charter has
>>>>     passed staff review, has been accepted for
>>>>     consideration, and the date for the ratification
>>>>     vote.  The minutes should also include the
>>>>     name of the LC shepherd for the record.
>> Again, I don't agree to this extra step.
>>>> 7. The staff then announce the proposed charter
>>>>     on public web pages and discussion lists to
>>>>     solicit feedback from the broader community,
>>>>     directing comments to the proposer and to
>>>>     the named shepherd.
>> This should be done as the very next action by the LC Secretary (or
>> designee) once they have done their own review for completeness.  I
>> suggest we come up with a mechanism of listing proposed charters in
>> one place online, sending an email to the community@ list when we  
>> know
>> they are going to be on the LC agenda for vote, and making sure all
>> such charters are indeed on the LC agenda for vote within the 30 days
>> (something the Chair would see to per the notification he/she  
>> received
>> from the LC Secretary).
>>
>> BTW, the Operating Procedures require this in 3.1 when it states:  
>> "All
>> proposed and approved WG Charters must be made available for public
>> review."
>>
>>
>>>>
>>>>
>>>> 8. It is the responsibility of the shepherd to
>>>>     review the proposed charter and evaluate the
>>>>     merits of the proposed work as related to the
>>>>     Kantara Initiative mission and in the context
>>>>     of other existing work.
>>
>> This is another conflict.  It may not be a huge conflict with the
>> written word of the Operating Procedure or ByLaws, but it is a rather
>> huge conflict with the intent of those words.  The founders debated
>> this specific issues when writing the bylaws.  The intention is that
>> LC does not ever refuse to approve a charter based on how it might
>> relate to existing work.  Therefore, it should not be a criteria for
>> review.  Instead, what should happen is a quick information exchange
>> just to make sure the proposers are aware of the existing work, but
>> then move forward and approve the charter simply based on the fact
>> that they have followed the application process.
>>
>> With that additional background I think it's clear we do not want to
>> articulate this step in this manner, but the idea of informing the
>> applicant I think is still quite important and hopefully would have
>> happened before a charter was ever sent to the LC Secretary, but
>> having it in this work flow ensures this is addressed eventually even
>> if not up-front.
>>
>>>>     NOTE: I suggest that this review period
>>>>     include close coordination between the
>>>>     shepherd and the proposer in order to
>>>>     quickly address any issues that might
>>>>     arise (e.g. similar work in other groups).
>>>>
>>>> 9. On the announced ratification date, the
>>>>     proposer of the charter joins the LC
>>>>     teleconference in which it is officially
>>>>     presented for a vote.
>> I'd just tweak this to say the Chair will invite them.  I say this
>> because even if they are not present, that is still not grounds for
>> declining the charter or postponing the vote.
>>>> 10. During the time in the agenda for voting on
>>>>     the proposed charter, the LC Chair calls for
>>>>     discussion and the shepherd presents any
>>>>     comments.  The discussion is then open to the
>>>>     full LC, including participation of the proposer.
>> I don't think you need to document this to such a level of detail,  
>> but
>> if you do want to get this specific then I'd suggest a modification  
>> to
>> make this better comply with Robert's Rules of Order:  The LC Chair
>> would ask for a motion to approve the charter, then ask for a second,
>> then introduce discussion (where hopefully the applicants are present
>> to answer questions), then would call the vote.
>>>> 11. The Chair calls for a motion to either vote
>>>>     on the proposed charter immediately, or
>>>>     to defer the vote until a future date (in order
>>>>     for the proposer to address any issues
>>>>     surfaced in the discussion).
>>>>
>>>>     NOTE: I interpret a "no" vote as being one
>>>>     in which the charter is rejected, and cannot
>>>>     come back for vote without substantive
>>>>     rework (i.e. it must start back at step one),
>>>>     hence my proposal for a deferral.  Otherwise,
>>>>     it's possible to see that a charter could
>>>>     continually eat up procedural time that has
>>>>     zero chance of approval.
>> The Operating Procedures simply don't give you this much flexibility.
>> You would have to call the vote unless you have enough time left in
>> the 30 day window to postpone the vote.  This was deliberate and it
>> protects the applicants.  If there isn't time, the vote is called for
>> and it either fails because of the vote or it fails to get moved &
>> seconded.
>>>> 12. In the case of a deferral, the proposed
>>>>     charter is put back on the agenda of the
>>>>     next LC teleconference for a vote.
>>>>
>>>>     NOTE: I would suggest only one deferral be
>>>>     allowed before a vote must be held for the
>>>>     same reason as the previous note.
>> Again, no deferral unless there is time in the 30 day window.
>>>> 13. In the case of a vote, the LC Chair calls
>>>>     for a vote of the members on the proposed
>>>>     charter and the outcome is officially recorded.
>>>>     Ratification requires a simple majority of the
>>>>     full LC.
>>
>> This is actually an official responsibility of the LC as stated in  
>> the
>> bylaws (5.3): "The Leadership Council shall provide timely notice of
>> the formation and chairperson of a Work Group to all Participants. "
>>
>>>> I'm sure there's some tweaking we should do to this process, but  
>>>> I like
>>>> the concept of the LC Member Shepherd.  This is similar in nature  
>>>> to the
>>>> IETF process where an Area Director fills the same roll.  Also, by
>>>> publicly naming the shepherd we're able to clarify for the  
>>>> community who
>>>> they should contact with comments or questions.
>>>>
>>>> What do folks think about this flow?
>>>>
>>>> - Trent
>>>>
>>>>
>>>> [1]
>>>> http://kantarainitiative.org/confluence/download/attachments/2293776/Kantara+Initiative+Operating+Procedures+_V1.0_+2009-04-03.pdf?version=1
>>>>
>>>>
>>>
>>> _______________________________________________
>>> LC mailing list
>>> LC at kantarainitiative.org <mailto:LC at kantarainitiative.org>
>>> http://kantarainitiative.org/mailman/listinfo/lc_kantarainitiative.org
>>
>
> -- 
> J. Trent Adams
> =jtrentadams
>
> Outreach Specialist, Trust & Identity
> Internet Society
> http://www.isoc.org
>
> e) adams at isoc.org
> o) 703-439-2149
>
>
>
> _______________________________________________
> LC mailing list
> LC at kantarainitiative.org
> http://kantarainitiative.org/mailman/listinfo/lc_kantarainitiative.org


Eve Maler                                          eve.maler @ sun.com
Emerging Technologies Director                    cell +1 425 345 6756
Sun Microsystems Identity Software                www.xmlgrrl.com/blog