<p dir="ltr">+1 to Steve so long as the number is not reduced to the extent of being too small to ensure diversity in the group.</p>
<p dir="ltr">Regards</p>
<p dir="ltr">Sent from Google nexus 4<br>
kindly excuse brevity and typos.</p>
<div class="gmail_quote">On 18 Jul 2015 5:31 pm, "Steve Crocker" <<a href="mailto:steve@shinkuro.com">steve@shinkuro.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Folks,<div><br></div><div>As Bruce said, he expressed his personal opinion. He suggested three things:</div><div><br></div><div>o Fixed number of members</div><div><br></div><div>o Open to participation by others</div><div><br></div><div>o Prioritization of the recommendations</div><div><br></div><div>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.</div><div><br></div><div>Steve</div><div><br></div><div><br><div><div>On Jul 17, 2015, at 7:33 AM, Bruce Tonkin <<a href="mailto:Bruce.Tonkin@melbourneit.com.au" target="_blank">Bruce.Tonkin@melbourneit.com.au</a>> wrote:</div><br><blockquote type="cite"><div lang="EN-AU" link="#0563C1" vlink="#954F72" style="font-family:Cambria;font-size:18px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">Hello All,<u></u><u></u></div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">(Disclaimer: - my comments below are my personal view, and don’t relate to the views of the Board or other Board members)<u></u><u></u></div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">Just following up on my comments about the structure of review teams.<u></u><u></u></div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">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.<u></u><u></u></div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">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.<u></u><u></u></div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">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.<u></u><u></u></div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">The organisation can then focus on implementing the high priority requirements within a short time frame to get the most benefit.<u></u><u></u></div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">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.<u></u><u></u></div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">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.<u></u><u></u></div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">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.<u></u><u></u></div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">Regards,<u></u><u></u></div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">Bruce Tonkin<u></u><u></u></div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div></div>_______________________________________________<br>Accountability-Cross-Community mailing list<br><a href="mailto:Accountability-Cross-Community@icann.org" style="color:rgb(149,79,114);text-decoration:underline" target="_blank">Accountability-Cross-Community@icann.org</a><br><a href="https://mm.icann.org/mailman/listinfo/accountability-cross-community" style="color:rgb(149,79,114);text-decoration:underline" target="_blank">https://mm.icann.org/mailman/listinfo/accountability-cross-community</a></div></blockquote></div><br></div></div><br>_______________________________________________<br>
Accountability-Cross-Community mailing list<br>
<a href="mailto:Accountability-Cross-Community@icann.org">Accountability-Cross-Community@icann.org</a><br>
<a href="https://mm.icann.org/mailman/listinfo/accountability-cross-community" rel="noreferrer" target="_blank">https://mm.icann.org/mailman/listinfo/accountability-cross-community</a><br>
<br></blockquote></div>