search

j3-fortran / fortran_proposals

Proposals for the Fortran Standard Committee
175 stars 14 forks source link

Triage proposals into three tiers #123

Open certik opened 4 years ago

certik commented 4 years ago

@klausler suggested in https://github.com/j3-fortran/fortran_proposals/issues/122#issuecomment-568540846:

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 commented 4 years ago

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

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

klausler commented 4 years ago

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 commented 4 years ago

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

klausler commented 4 years ago

Bug, essential, nonessential.

klausler commented 4 years ago

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 commented 4 years ago

@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.