[J3] [EXTERNAL] Re: posts

[Van Snyder]

On Wed, 2020-01-22 at 10:16 -0700, 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?

J3 has difficulty multitasking because essentially everything of
consequence is done in the meetings, and we reduced our schedule from
four meetings (sometimes five because of separate, not joint J3 and WG5
meetings).  We do very little of consequence by e-mail.

P1788 was completed without any face-to-face meetings.  Most of the WG9
work is done by e-mail, with one yerly meeting jointly with WG9,
Ada-Europe, and the conference on software reliability.  They maintain a
list of "Ada Issues."  Each one is a complete proposal, working on its
own schedule with its own team of volunteers.  Nothing about it, other
than "pursue this," is done in plenary, until the team thinks it's
complete.  Then plenary votes it up or down.  If it fails, it goes back
to offline work, or maybe gets dropped or put on the back burner.

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

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