Meta: how proposals are developed

[certik]

@zjibben and I would like to summarize this in the README, so that we are all on the same page what the process is.

In fact, there seems to be a little disagreement how new features should be developed at the Committee. Some members of the Committee prefer to start with writing down requirements, pass it. Then develop specification (specs) based on the requirements. Pass it. Then develop syntax, pass it. And finally edits to the standard and pass it. 4 papers.

@zjibben and I think we should instead use the following approach, which is similar, but different:

1. Proposal: Develop a proposal that discusses use cases both before and after the feature. It discusses syntax and how the new feature should be used. The proposal does not have to have all the details fleshed out, but it needs to be clear to the reader what the feature should be and it concentrates on syntax and properties of the new feature.

2. Requirements: From the Proposal, extract Requirements.

3. Specification: From the Requirements only, logically derive Specification.

4. Syntax: From the Specification, logically derive and propose Syntax.

5. Iterate: Does 3. and 4. agree with the Proposal at 1. ? If it does not, then we need to iterate the process 1. - 4. until it agrees and is self consistent.

6. Edits: Write Edits to the standard.

The advantage of this approach 1. - 6. is that it ensures both:

a) The feature is what the community wants (this is ensured by 1.)

b) The feature is the best way to achieve something, i.e., there is not an alternate way to develop a feature (this is ensured by extracting the abstract requirements in 2. and then ensuring that the feature in 3. and 4. logically follows from it, and that it agrees with 1., as ensured in 5.)

On the other hand, by starting with Requirements right away, we ensure consistent feature, but we cannot ensure we end up with a feature that the community wants. In fact, by observing how features get developed at the Committee, very often we see features that are not what the community wants, because 1. was skipped, and we went straight to 2.

Example:

An example proposal that got recently passed by the Committee that follows this process is #161, where:

1: https://j3-fortran.org/doc/year/18/18-273r1.txt
2, 3, 4: https://j3-fortran.org/doc/year/19/19-201r1.txt
5: In this case 3. and 4. agree with 1.
6: https://j3-fortran.org/doc/year/20/20-116.txt

cc @FortranFan.

[FortranFan]

Please see this: https://mailman.j3-fortran.org/pipermail/j3/2018-July/010806.html

My understanding is the J3 approach has a subtle but important attribute in that items 2 and 3 are "Formal Requirements" and "Formal Specifications" i.e., the term "Formal" brings these 2 aspects closer to the "standardese" used in the IEC ISO document.

But for proposals developed on a forum such as this one, I suggest focusing on simple language during the initial steps and inserting a step after 1 in the list above which is Needs where the proposer can explain in simple terms what the proposal should achieve i.e., add to or extend or not be affected in the language due to proposal e.g., with #156, the Needs section might clearly state "it must be possible to define a variable of a derived type with a protected component in an intrinsic assignment.