[J3] posts

Ondřej Čertík ondrej at certik.us
Wed Jan 22 14:07:59 EST 2020

Hi Keith,

On Wed, Jan 22, 2020, at 10:16 AM, Keith Bierman via J3 wrote:
> On Wed, Jan 22, 2020 at 9:17 AM Vipul Parekh via J3 
> <j3 at mailman.j3-fortran.org> wrote:
> ...quoting OO above My own opinion is also that we absolutely have to 
> give some feedback for every proposal.
> > 
> >  Or is the view here that J3 is unable and/or unwilling to multitask
> >  even a little?
> I can't comment on the committee's current workings or thinking. But 
> recalling similar discussions and some unfortunate outcomes from the 
> past ....
>  1. Do not underestimate how hard it is to get consensus on WHY. 
> Feedback to a proposal other than "thanks for your input" can take an 
> almost unbounded amount of time. People can agree it would be nice, 
> disagree as to why it is nice, how it should be implemented, how fast 
> it should be implemented, whether it can be implemented. Having opened 
> up the box of snakes, it takes a long time to put them back. Also, any 
> entrenched hard feelings dug up by such discussions can impede other 
> work, where painful compromises have already been made, but not 
> completed.
>  2. What the committee *has* to do is defined by ANSI (and/or ISO 
> depending on context). What the committee should do may be very 
> different. If a debate about *has* to do is required, quote chapter and 
> verse from the relevant organizational documents.
> The pain, suffering, and delays of F9x should never be repeated. A 
> focus on consensus positions on public comment was certainly not the 
> root of all problems ... but it certainly was seriously unhelpful.

Thanks for the feedback. As I mentioned a few times, I am proposing so spend 5 minutes per proposal, and I will bring a timer, and when it rings, that's it. We move to the next proposal. Furthermore, I propose to only do 2 such "community" proposals per day. (If this is successful, we can try 10 minutes per proposal at our next meeting.) This addresses your concern about "unlimited time" in point 1. Regarding your other concern about "is this useful", yes, this is absolutely essential to give feedback (even if it is brief), so that the community knows if they should continue developing the proposal and refining it and improving it for the next meeting, or if the committee was against it mostly, and so it has low chance of getting in.

I am not proposing some revolutionary concept. I am new to the Fortran committee, but I have sat at many committees in my life (from hiring committees, so all kinds of grant committees, summer student selection committees etc.) and not reviewing a proposal or an applicant is unheard of and unacceptable. The way every other committee I have been on works is that all the hard work is done *ahead* of time, so all the proposals are reviewed and discussed ahead of time over email, or in our case also GitHub (https://github.com/j3-fortran/fortran_proposals). Then once people meet in person, typically we get N proposals and we have M minutes. So we allocate M / N minutes per proposal, set a timer. Then one person presents the proposal, it gets discussed (people either pull out their notes that they prepared ahead of time, or simply remember their feedback), when the timer rings the discussion is stopped and we move on to the next proposal. So I am proposing exactly the same concept for the 202Y proposals that will get submitted, and limit discussion to 5 min per proposal and only do 2 proposals per day. That gives 10 proposals total --- and if more are submitted, then we will use GitHub to decide (ahead of time) which top 10 proposals we want the Committee to look at to provide feedback. These issues are all solvable.

As Van just mentioned in another email:

> J3 dribbles in little bits and pieces of each project, and spends a lot
of time, especially subgroup time, doing things that could be done

Yes! I 100% agree. But I think we have now the infrastructure to fix this, and we have made lots of discussions offline already (https://github.com/j3-fortran/fortran_proposals) and I encourage wider participation from other committee members.


More information about the J3 mailing list