[KI-LC] Charter Approval Process Proposal

[Brett McDowell]

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
> http://kantarainitiative.org/mailman/listinfo/lc_kantarainitiative.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kantarainitiative.org/pipermail/lc_kantarainitiative.org/attachments/20090601/9cc60963/attachment-0001.html>