[CCWG-ACCT] Improvements to review team processes
otieno.barrack at gmail.com
Mon Jul 20 04:37:31 UTC 2015
Hi Steve and Bruce,
I think the IANA transition presents a unique dilemma in terms of the
requirements for obtaining a good product and the time frames within
which we should work and whereas the suggestions you make have been
tried and tested , we might just need to work with the current 'broad
based all inclusive' model to attain our objectives. I think the
co-chairs and various appointed representatives from the SO's and AC's
have done a great job which is a result of the experience gained
serving in their respective communities. That said you have a valid
On 7/18/15, Steve Crocker <steve at shinkuro.com> wrote:
> Thanks. Yes, a team could, at least in principle, be too small. I didn’t
> address that side of the “engineering problem” because we’re NEVER in danger
> of too few people :)
> On Jul 18, 2015, at 12:40 PM, Seun Ojedeji <seun.ojedeji at gmail.com> wrote:
>> +1 to Steve so long as the number is not reduced to the extent of being
>> too small to ensure diversity in the group.
>> Sent from Google nexus 4
>> kindly excuse brevity and typos.
>> On 18 Jul 2015 5:31 pm, "Steve Crocker" <steve at shinkuro.com> wrote:
>> As Bruce said, he expressed his personal opinion. He suggested three
>> o Fixed number of members
>> o Open to participation by others
>> o Prioritization of the recommendations
>> Also speaking for myself and not on behalf of the whole board but with the
>> experience of having been a co-selector of the ATRT2, I think it matters
>> how many people are involved, particularly when f2f meetings are involved
>> and travel expenses are provided. As a rule of thumb, there are big
>> difference between, say, a group of 8, a group of 12, a group of 16, a
>> group of 20 and a group of 24. As the group gets larger, it becomes
>> harder and harder to make arrangements, to make sure everyone has spoken
>> and to reach consensus. Openness and broad participation are important,
>> but efficiency and effectiveness are also important.
>> On Jul 17, 2015, at 7:33 AM, Bruce Tonkin
>> <Bruce.Tonkin at melbourneit.com.au> wrote:
>>> Hello All,
>>> (Disclaimer: - my comments below are my personal view, and don’t relate
>>> to the views of the Board or other Board members)
>>> Just following up on my comments about the structure of review teams.
>>> I am in favour of making review teams more open – (ie option 2) which
>>> consists of a fixed number of members and an open number of participants.
>>> It avoids the situation where it is the usual suspects that are on
>>> every review team.
>>> My concern though is that a review team basically comes up with a list of
>>> requirements for improvements. The larger and more inclusive the group
>>> – the larger the list of requirements. Unless a requirement conflicts
>>> with another requirement it is likely to be added to the list.
>>> I think we should explicitly note that review teams should be required to
>>> provide a prioritised set of requirements. This is always harder to do,
>>> but is the real work that needs to be done.
>>> The organisation can then focus on implementing the high priority
>>> requirements within a short time frame to get the most benefit.
>>> My comment comes from a long experience managing software projects where
>>> there are always more requirements than resources to implement those
>>> requirements in a reasonable time frame.
>>> We are doing new releases of critical parts of the organisation on a
>>> cyclical basis – and need to ensure we focus on the key requirements for
>>> each release.
>>> In terms of whether this is a new idea – I am trying to create a balance
>>> between allowing review teams to be larger and more inclusive, and
>>> ensuring we don’t get an unrealistically long list of requirements that
>>> can’t be implemented in a timely or cost effective fashion.
>>> Bruce Tonkin
>>> Accountability-Cross-Community mailing list
>>> Accountability-Cross-Community at icann.org
>> Accountability-Cross-Community mailing list
>> Accountability-Cross-Community at icann.org
Barrack O. Otieno
More information about the Accountability-Cross-Community