On 10/19/18 4:45 AM, Andrey Semashev via Boost wrote:
For the sake of mailing list and similar conversations, including the review, real names probably don't matter that much. Although, frankly, on this list there aren't many regular participants who use an alias.
Boost traditionally has encouraged participants to use real names. I think this is a good thing and I think keeps discussions from going down hill - on other forums as well as boost. I was suggesting that this might be an exception to our normal policy.
But there are contexts where real names are required or simply appropriate. For example, in copyright notices in the source code or documentation. Or IRL communication, should one happen e.g. in C++Now or somewhere else.
Of course
There is also an awkward moment when you reveal the author's name, who was previously known by an alias, at which point you only cause confusion. And probably either you or the author has to prove his authentity.
Hmm - I'm not seeing this - but maybe.
My idea was that making it more attractive for potential submitters, we might draw more submissions than we otherwise might and hence end up with a better one.
That's part of my argument - you're trying to attract submitters that would normally not want to make the submission and potentially don't want to be part of Boost. At least, that's what the document draft says. This is bad for Boost and the potential submitters.
So one who is uncomfortable about revealing his true identity might have difficulties when his identity is revealed in dealing with the reality that is boost. I can certainly see your point here. As I've said - it's an idea and I'm glad it's being discussed. For some time I've been concerned about the future of Boost as an organization. This is one idea - I'm curious about others. Here ate the concerns I have: a) With C++11, the standards committee accepted a large portion of Boost into the standard. This left it unclear as to what the future value of Boost to C++ might be. b) The standards committee has ramped up it's efforts to include library proposals directly into the standard - thus side stepping the traditional requirement of "standardizing established practice". So this has left Boost outside of the development of the C++. A example of this has been the Ranges library which as been designed and developed totally within confines of the C++ standards committee. This effectively marginalizes Boost. c) This effort by the committee is basically failing. It's creating the possibility that C++ will evolve into an ever larger and incomprehensible bag of features than it already is. It puts C++ on a slow train to oblivion. This is not usual with successful projects which expand their scope - as the committee has done. It's especially common for organizations run as a committee. Think large corporations: Kodak, Sears, All government organization, universities - etc. All one has to do to see this is look at the papers list for the san diego meeting. Also look at P0977r0. Consider that it take the committee 10 years for a proposal to evolve into something that can be delivered to users. Of course the C++ committee won't address the situation. Committees don't do that. Oh - now they want to expand scope again to include tooling. Wake up and smell the coffee people. d) Hence Boost has a reason to continue and exist. But Boost is also a committee - albeit a better designed one. It has to evolve as well. I think it can evolve if we continue to work on the stuff we've been successful at while at the same time experimenting with new ideas. This is the motivation behind this proposal and a number of ideas contained therein. Robert Ramey