[KI-LC] Charter Approval Process Proposal
J. Trent Adams
adams at isoc.org
Tue Jun 2 10:44:24 PDT 2009
All -
I have taken the comments I received and reworked my proposed Work Group
Process. It corrects mismatches with the bylaws and operating
procedures as well as simplifying the process:
http://kantarainitiative.org/confluence/x/K4FJ
Please feel free to edit the wiki, send any more comments, or we can
simply talk about it tomorrow.
Cheers,
Trent
Eve Maler wrote:
> 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
>
>
> _______________________________________________
> LC mailing list
> 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
More information about the LC
mailing list