Re: [text] [review] Text formal review result

From: Jeff Garland (azswdude_at_[hidden])
Date: 2020-06-28 16:16:01

On Sat, Jun 27, 2020 at 9:22 PM Edward Diener via Boost <
boost_at_[hidden]> wrote:

> On 6/27/2020 1:55 PM, Ville Voutilainen via Boost wrote:
> > On Sat, 27 Jun 2020 at 18:48, Edward Diener via Boost
> > <boost_at_[hidden]> wrote:
> >> You have raised a bunch of hackles here. The LEWG, along with all other
> >> C++ standard committees, seems to me so much less open to debate than
> >> Boost is that it is hard to know what to say about your assertion that
> >> "This list is not very welcoming". Nor can anything ever be found out
> >> from the C++ standards committee why such and such was accepted or
> >> rejected, or what the arguments were about after the fact.
> >
> > Have you tried asking a committee member, or just asking on
> std-discussion?
> > It also seems to me that there tends to be a multitude of meeting trip
> reports
> > that cover why such and such was accepted or rejected.
>
> I do not find that the reasons why a proposal is accepted or rejected,
> as well as the differing opinions of those reviewing the proposal, are
> available for C++ Standard committees. Yet anyone can search Boost
>
archives for discussions regarding a library submitted to Boost, since
> they are all part of the Boost developer mailing list. Therefore while I
> respect the expertise of those on the various C++ standard committees,
> and while I understand that those who are on the various C++ standard
> committees change over time, the lack of historical information
>

I guess I don't see this as generally the case wrt specific proposals.
Most papers, tend to maintain a running history of relevant decisions and
that's usually the best source of what transpired.  Look at one of mine --
on page 2 there there's a summary related to LEWGI and SG10 feedback.
Section 6 goes into more detail on a number of these. Authors do this to
help remind themselves and help committee members (meaning cut down
rediscussion of already hashed thru points) that aren't able to be in every
single discussion of the paper.  To me this is actually better than trying
to search the mailing list.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1750r1.pdf

> regarding proposals is a huge negative IMO. I am not against experts
> making decisions in any field, but I am always against those decisions
> not being open so that other people can see the reasons, even after the
> fact, for decisions being made. This is especially true in our age,
> where digital records can provide information much more easily than
> libraries of printed information could in the past. I believe everyone
> has a right to protect personal information, but at the same time I
> believe public information should be open to anyone.
>

98% of it is.  Of course it just won't have the fidelity of have 'been in
the room'...

>
> >
> >> poobahs of the C++ standard committee I have often found to be largely
> >> unfriendly and closed in their determination that only they really know
> >> what is good or not for C++.
> >
> > Sure; some of them need a fairly strong rationale to be convinced
> otherwise. :)
>
> I think it is more like some of them are too egotistical to even listen
> to others who do not have their own reputation.

If these people exist, I haven't met them yet.  And I've spent an unhealthy
amount of time participating....

> But that is true in any
> field and while I have encountered some who were like that I have also
> dealt with some others who were pretty open to technical arguments.
> Nonetheless I find that even if the debates in Boost get fairly
> contentious sometimes, it is always better to have the debate rather
> than avoid argumentation out of some preconceived notion of "niceness".
>

'Contentious debate' over things that should be non-issues is a feature of
our current broader context.  To give a Boost example, though, I find all
review comments of the form "this doesn't solve my use case so I won't use
the library - I vote to reject" hostile and not helpful.  The fact that a
library doesn't solve your use case is one 'data point' -- good, supply
that as a fact.  The question at hand in a review is if the library solves
a need for many users.  If you would vote against something that others
might find useful that lessons the value of your opinion in my book.

Jeff