From owner-sc22wg5@dkuug.dk Tue Apr 6 23:33:11 2004 Received: (from majordom@localhost) by dkuug.dk (8.12.10/8.9.2) id i36LXBeQ096603 for sc22wg5-domo; Tue, 6 Apr 2004 23:33:11 +0200 (CEST) (envelope-from owner-sc22wg5@dkuug.dk) X-Authentication-Warning: ptah.dkuug.dk: majordom set sender to owner-sc22wg5@dkuug.dk using -f Received: from out0.mx.nwbl.wi.voyager.net (out0.mx.nwbl.wi.voyager.net [169.207.3.118]) by dkuug.dk (8.12.10/8.9.2) with ESMTP id i36LWnE7096591 for ; Tue, 6 Apr 2004 23:33:02 +0200 (CEST) (envelope-from Craig_Dedo@execpc.com) Received: from execpc.com (d129.as14.nwbl1.wi.voyager.net [169.207.90.3]) by out0.mx.nwbl.wi.voyager.net (Postfix) with ESMTP id 163FDF2459 for ; Tue, 6 Apr 2004 16:33:02 -0500 (CDT) Message-ID: <40732217.2000702@execpc.com> Date: Tue, 06 Apr 2004 16:33:11 -0500 From: Craig Dedo Reply-To: Craig Dedo Organization: Elmbrook Computer Services User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: WG5 Mailing List Subject: 8-Point Difficulty Scale for Fortran Features (Was: Plans for the next revision) References: <200404061457.i36EvhXU091826@dkuug.dk> In-Reply-To: <200404061457.i36EvhXU091826@dkuug.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0 () Sender: owner-sc22wg5@dkuug.dk Precedence: bulk WG5: I really like this approach to scoring the likely difficulty of developing new features for Fortran. Many thanks to John Reid, Richard Maine, Van Snyder, and Malcolm Cohen for developing this scale. It would be useful if we could also develop a second scale for scoring the difficulty of implementation. Although there is some correlation between difficulty of development and difficulty of implementation, the two do not always coincide. It is possible to create a feature that is easy to develop but difficult to implement or difficult to develop but easy to implement. Any ideas? John Reid wrote: >WG5, > >In my draft plan, I used the terms 'significant features', >'minor enhancements' and 'editorial improvements', but I have come >to the view that this is too imprecise. Different people have >different views on what these mean. Here is a first try >at an 8-point scale of severity, based on things that we have done >recently. > >I would like to thank Richard Maine, Van, and Malcolm for commenting on drafts of this scale. > >Best wishes, > >John. > >................................................................. > > >1. Minor editorial (less than 10 lines altered). > >2. Significant editorial (up to a page altered) with no technical change. > >3. Very minor technical change. An example is adding the optional > argument KIND to IACHAR (see 1.12 in N1509). > Also major editorial (up to a chapter altered) with no technical change. > >4. Minor technical change. An example is changing type-bound generics to > be sets of specific named type-bound procedures (see TC4 in N1506). > >5. Technical change likely to need more than two J3 meetings to develop. > An example is reallocation of allocatable arrays (see TC11 in N1506). > >6. Technical change likely to need more than a year to develop. > The modules and allocatable TRs are examples. > >7. Technical change likely to need more than 2 years to develop. > The IEEE TR is an example. > >8. Technical change likely to need more than 3 years to develop. > Interfacing with C and the OO features are examples. > > >Notes. > >1. The level of a technical change is likely to be affected by whether > necessary edits are scattered over the document of mostly confined > to one place. > >2. The level of a technical change should be influenced by how difficult > it is to implement. > > > > -- Sincerely, Craig T. Dedo 17130 W. Burleigh Place E-mail: Craig_Dedo@execpc.com Brookfield, WI 53005-2759 Voice Phone: (262) 783-5869 USA Fax Phone: (262) 783-5928 "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- Benjamin Franklin (1759)