Triage proposals into three tiers

[certik]

@klausler suggested in #122 (comment):

I suggest that the proposals can be triaged into three tiers: (1) fixes to actual bugs in the language, (2) features that enable new usages that are impossible or impractical today, and (3) conveniences.

[certik]

I think this is a good idea. We can use labels for that. What labels should we use?

• bug
• new feature
• convenience

There might be some overlap between "new feature" and "convenience". I think there could be other categories:

• meta (we already have and use this label)
• workflow (perhaps Consider releasing Fortran standard every 3 years instead of 5 #36 could fit)
• community (something that is not directly related to a standard as a work item for the J3 or WG5 committees, but we still want to see happen in the Fortran community; Standard library proposals #104, Create a testsuite for the standard #57 could fit)

[klausler]

I didn't use the term "new feature". Most of these items are new features. The distinction between tier (2) and tier (3) is that tier (2) items are "must haves" that enable capabilities that are not possible today, while tier (3) items are "nice to haves".

[certik]

@klausler can you propose names for labels you would like to use? Perhaps bug, must have, nice to have. I don't know.

[klausler]

Bug, essential, nonessential.

[klausler]

Example: I consider some kind of parametric polymorphism to be essential, not a convenience -- the alternatives are too painful, and it is a scandal that one cannot quickly instantiate a linked list for a new derived type. But I admit that's a subjective judgement.

From the perspective of this implementer, the distinction seems to be how I would react if a feature showed up on an RFP (tier (1) is "obviously we have to do that",tier (2) is "I can see why you need that", and tier (3) is "let's ask whether this is a deal-killer").

I guess that I'm just asking for some kind of prioritization that isn't obviously too far out of whack with reality.

[FortranFan]

@klausler suggested in #122 (comment):

I suggest that the proposals can be triaged into three tiers: (1) fixes to actual bugs in the language, (2) features that enable new usages that are impossible or impractical today, and (3) conveniences.

WG5 Fortran committee in collaboration with the national bodies (particularly J3) already does all that with a lot of regimen and with extensive focus on prioritization as dictated by their schedule, especially with point (1) re: fixes to bugs in the language standard.

J3 and WG5 effectively do their own "triaging" with the proposals presented to them and they have a methodology as well as extensive experience in doing so. Not only I see little value in replicating such "triaging" here, I find little of the collaborative skills and organization structure here yet which are needed toward such attempts.

Any further reclassification of issues posted here and reduction of ideas and suggestions (such as what might be one coder's enabling facility getting needlessly labeled by an implementor as mere "convenience") will be a disincentive "to collaborate on ideas and proposals with the Fortran community."

Towards the "idea for this repository is to act as a public facing discussion tool to collaborate with the user community to gather proposals for the Fortran language," there is already the "workflow" of "negative feedback" that envisages a closure to a discussion and "positive feedback" which promises a "drafting a formal proposal to be submitted into Documents for the US committee".

I suggest continuing with this workflow and refining it as needed e.g., get the OP's who posted issues that received positive feedback to work with those who provided the "thumbs up" (as well as anyone else who has the time and inclination to assist) to develop their issues into proposals, so their ideas can be forwarded for consideration by the standard committee. #67 with proposal in https://github.com/marshallward/fortran_proposals/blob/namelist_delim/proposals/namelist_delimiters/namelist_proposal.rst is a good example to follow.