[CCWG-ACCT] Improvements to review team processes

Steve Crocker steve at shinkuro.com
Sat Jul 18 16:43:23 UTC 2015


Seun,

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 :)

Steve

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.
> 
> Regards
> 
> Sent from Google nexus 4
> kindly excuse brevity and typos.
> 
> On 18 Jul 2015 5:31 pm, "Steve Crocker" <steve at shinkuro.com> wrote:
> Folks,
> 
> As Bruce said, he expressed his personal opinion.  He suggested three things:
> 
> 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.
> 
> Steve
> 
> 
> 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.
>>  
>> Regards,
>> Bruce Tonkin
>>  
>>  
>>  
>>  
>> _______________________________________________
>> Accountability-Cross-Community mailing list
>> Accountability-Cross-Community at icann.org
>> https://mm.icann.org/mailman/listinfo/accountability-cross-community
> 
> 
> _______________________________________________
> Accountability-Cross-Community mailing list
> Accountability-Cross-Community at icann.org
> https://mm.icann.org/mailman/listinfo/accountability-cross-community
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/accountability-cross-community/attachments/20150718/95d86682/attachment.html>


More information about the Accountability-Cross-Community mailing list