[CCWG-ACCT] Improvements to review team processes

[Seun Ojedeji]

+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/0ddd173f/attachment.html>