[std-proposals] Procedure for proposal submission

[m***@visma.com]

Hello,

I need a little clarification on the proposal submission process. I'm sorry
if this has been answered already, but I could not find it on the forum.

I read the explanation for how to make a submission from here
https://isocpp.org/std/submit-a-proposal but it's unclear. It says that one
should post the idea here, then draft a proposal, post that here, iterate
and improve it until it's in a mature form that can be submitted. And then
what? It does not say where or how to send the proposal. There is another
document
https://isocpp.org/std/standing-documents/sd-7-mailing-procedures-and-how-to-write-papers
that is for WG21 committee members only.

So where do I send a proposal?

Thank you,
Marius

[Tom Honermann]

Unless things have changed recently, despite what that second document
states, submissions are accepted from non-members per the described
procedures.  Perhaps Hal would be willing to clarify.

Tom.

Post by m***@visma.com
Hello,
I need a little clarification on the proposal submission process. I'm
sorry if this has been answered already, but I could not find it on
the forum.
I read the explanation for how to make a submission from here
https://isocpp.org/std/submit-a-proposal but it's unclear. It says
that one should post the idea here, then draft a proposal, post that
here, iterate and improve it until it's in a mature form that can be
submitted. And then what? It does not say where or how to send the
proposal. There is another document
https://isocpp.org/std/standing-documents/sd-7-mailing-procedures-and-how-to-write-papers
that is for WG21 committee members only.
So where do I send a proposal?
Thank you,
Marius
--
You received this message because you are subscribed to the Google
Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f900bd92-c0f7-4b80-bd6e-d754d478f68c%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f900bd92-c0f7-4b80-bd6e-d754d478f68c%40isocpp.org?utm_medium=email&utm_source=footer>.

[Ville Voutilainen]

Post by Tom Honermann
Unless things have changed recently, despite what that second document
states, submissions are accepted from non-members per the described
procedures. Perhaps Hal would be willing to clarify.

There are all kinds of rules, and there's a chance that some folks
don't really pay attention
to the strictest interpretation of all kinds of rules. I suppose,
considering my position, that that's as much as I should
say about this. :)

[Arthur O'Dwyer]

Post by m***@visma.com
Hello,
I need a little clarification on the proposal submission process. I'm
sorry if this has been answered already, but I could not find it on the
forum.
I read the explanation for how to make a submission from here
https://isocpp.org/std/submit-a-proposal but it's unclear. It says that
one should post the idea here, then draft a proposal, post that here,
iterate and improve it until it's in a mature form that can be submitted.
And then what? It does not say where or how to send the proposal. There is
another document
https://isocpp.org/std/standing-documents/sd-7-mailing-procedures-and-how-to-write-papers
that is for WG21 committee members only.
So where do I send a proposal?

https://isocpp.org/std/submit-a-proposal
https://isocpp.org/std/standing-documents/sd-7-mailing-procedures-and-how-to-write-papers
are both correct.

Formal ISO meetings are held several times a year; the next one is in
Jacksonville, Florida, 2018-03-12. Each meeting is preceded by a
"pre-meeting mailing," which goes out to meeting attendees and paper
authors. This "mailing" contains all the papers that were submitted before
the deadline; the pre-Jacksonville deadline is 2018-02-12. Each meeting is
followed by a "post-meeting mailing" which again goes out to all meeting
attendees and paper authors.

First of all, if you aren't sure your paper/proposal is ready for the Big
Leagues of a formal ISO meeting — then the rest of these instructions are
not for you. You should post your proposal in this newsgroup, or on the
cpplang Slack channel, or in some other less-formal venue, to gather
technical feedback *and* to gain an understanding of the appropriate
"style" for WG21 proposals. In other words,
https://isocpp.org/std/submit-a-proposal
is correct.

Papers should have paper numbers — generally of the form P1234R0. You can
submit a paper with a number of (literally) PxxxxR0 and, in your email
body, ask Hal to give you a new number. This process is detailed correctly
on
https://isocpp.org/std/standing-documents/sd-7-mailing-procedures-and-how-to-write-papers

Okay. If you're sure your paper has been appropriately vetted, and you just
don't understand where to send it: read
https://isocpp.org/std/standing-documents/sd-7-mailing-procedures-and-how-to-write-papers
and send the paper to Hal Finkel.

Notice that WG21 meetings are open to anyone; you don't have to be an ISO
member. Notice that anyone can submit a paper to WG21. Notice also that if
nobody at the actual committee meeting is interested in discussing a
particular paper, then that paper will not get discussed. If you want to
ensure that a paper is discussed, then you must ensure that somebody is
interested in discussing it. Typically this is done by making *yourself*
that person. Frequently this is done by finding a "champion" to be that
person (e.g. if you cannot attend the meeting for some reason). Very
occasionally this is done by making the paper *actually compelling* even to
people who hadn't heard of it before (but this is difficult, what with the
volume of papers WG21 gets).

See "Interlude — How the standards committees work" by Francis Glassborow
in *Overload 15 <https://accu.org/var/uploads/journals/overload15.pdf>*,
August/September 1996. The organizing principles of WG21 have not
*significantly* changed from what he describes.

Post by m***@visma.com
Any proposed substantive change to the Working Paper ... must be

supported by a paper that describes the change and the reasons for it.
These papers can be very brief, but they must exist. They can be written by
anyone but must be funnelled through the C++ specialist group of a National
Body ...
[This requirement for NB sponsorship might have changed, or the US NB might
auto-sponsor everything by default, or Hal as a member of the US NB might
auto-sponsor some things by default. Anyway, I've never had trouble
submitting occasional papers.]

Post by m***@visma.com
The most critical stage for any proposal is that of getting through the

work group to reach the full committees. It is assumed that those proposing
changes will have enough personal interest to be present and to support
their proposal. Only the most clear cut changes ... will get through a work
group if the proposal’s author or another ‘champion’ isn’t present.

HTH,
Arthur

[Marius Bancila]

Thank you, that clarifies it quite well.

Post by m***@visma.com

Post by m***@visma.com
Hello,
I need a little clarification on the proposal submission process. I'm
sorry if this has been answered already, but I could not find it on the
forum.
I read the explanation for how to make a submission from here
https://isocpp.org/std/submit-a-proposal but it's unclear. It says that
one should post the idea here, then draft a proposal, post that here,
iterate and improve it until it's in a mature form that can be submitted.
And then what? It does not say where or how to send the proposal. There is
another document https://isocpp.org/std/standing-documents/sd-7-mail
ing-procedures-and-how-to-write-papers that is for WG21 committee
members only.
So where do I send a proposal?

https://isocpp.org/std/submit-a-proposal
https://isocpp.org/std/standing-documents/sd-7-
mailing-procedures-and-how-to-write-papers
are both correct.
Formal ISO meetings are held several times a year; the next one is in
Jacksonville, Florida, 2018-03-12. Each meeting is preceded by a
"pre-meeting mailing," which goes out to meeting attendees and paper
authors. This "mailing" contains all the papers that were submitted before
the deadline; the pre-Jacksonville deadline is 2018-02-12. Each meeting is
followed by a "post-meeting mailing" which again goes out to all meeting
attendees and paper authors.
First of all, if you aren't sure your paper/proposal is ready for the Big
Leagues of a formal ISO meeting — then the rest of these instructions are
not for you. You should post your proposal in this newsgroup, or on the
cpplang Slack channel, or in some other less-formal venue, to gather
technical feedback *and* to gain an understanding of the appropriate
"style" for WG21 proposals. In other words,
https://isocpp.org/std/submit-a-proposal
is correct.
Papers should have paper numbers — generally of the form P1234R0. You can
submit a paper with a number of (literally) PxxxxR0 and, in your email
body, ask Hal to give you a new number. This process is detailed correctly
on
https://isocpp.org/std/standing-documents/sd-7-
mailing-procedures-and-how-to-write-papers
Okay. If you're sure your paper has been appropriately vetted, and you
just don't understand where to send it: read
https://isocpp.org/std/standing-documents/sd-7-
mailing-procedures-and-how-to-write-papers
and send the paper to Hal Finkel.
Notice that WG21 meetings are open to anyone; you don't have to be an ISO
member. Notice that anyone can submit a paper to WG21. Notice also that if
nobody at the actual committee meeting is interested in discussing a
particular paper, then that paper will not get discussed. If you want to
ensure that a paper is discussed, then you must ensure that somebody is
interested in discussing it. Typically this is done by making *yourself*
that person. Frequently this is done by finding a "champion" to be that
person (e.g. if you cannot attend the meeting for some reason). Very
occasionally this is done by making the paper *actually compelling* even
to people who hadn't heard of it before (but this is difficult, what with
the volume of papers WG21 gets).
See "Interlude — How the standards committees work" by Francis Glassborow
in *Overload 15 <https://accu.org/var/uploads/journals/overload15.pdf>*,
August/September 1996. The organizing principles of WG21 have not
*significantly* changed from what he describes.

Post by m***@visma.com
Any proposed substantive change to the Working Paper ... must be

supported by a paper that describes the change and the reasons for it.
These papers can be very brief, but they must exist. They can be written by
anyone but must be funnelled through the C++ specialist group of a National
Body ...
[This requirement for NB sponsorship might have changed, or the US NB
might auto-sponsor everything by default, or Hal as a member of the US NB
might auto-sponsor some things by default. Anyway, I've never had trouble
submitting occasional papers.]

Post by m***@visma.com
The most critical stage for any proposal is that of getting through the

work group to reach the full committees. It is assumed that those proposing
changes will have enough personal interest to be present and to support
their proposal. Only the most clear cut changes ... will get through a work
group if the proposal’s author or another ‘champion’ isn’t present.
HTH,
Arthur
--
You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an
To view this discussion on the web visit https://groups.google.com/a/
isocpp.org/d/msgid/std-proposals/b5349a2f-cdbb-4b65-
942c-5de8179c9639%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b5349a2f-cdbb-4b65-942c-5de8179c9639%40isocpp.org?utm_medium=email&utm_source=footer>
.

[m***@gmail.com]

Have to agree with the OP, the situation is very confusing.

What it makes it even more so is Call for Library Proposals
<http://open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3370.html>

Which for example points not Hal Finkel, but <lwgchair at gmail.com> to
send to.

And there is also How To Submit a New Issue / Defect Report
<https://isocpp.org/std/submit-issue> that also adds <wmm at edg.com> "for
core language issues."

This leads indeed to the assumption hfinkel at anl.gov is *only *fro for
WG21 committee members,
which in tern makes one wonder "If for Library I must send to lwgchair, and
I am not a member, then probably, for EWG, there is some

Post by m***@visma.com
Hello,
I need a little clarification on the proposal submission process. I'm
sorry if this has been answered already, but I could not find it on the
forum.
I read the explanation for how to make a submission from here
https://isocpp.org/std/submit-a-proposal but it's unclear. It says that
one should post the idea here, then draft a proposal, post that here,
iterate and improve it until it's in a mature form that can be submitted.
And then what? It does not say where or how to send the proposal. There is
another document
https://isocpp.org/std/standing-documents/sd-7-mailing-procedures-and-how-to-write-papers
that is for WG21 committee members only.
So where do I send a proposal?
Thank you,
Marius

[Bryce Adelstein Lelbach aka wash]

The C++ committee has been around for a long time; unfortunately, our
infrastructure hasn't aged or scaled as well as we might have hoped.

We are actively working on improving C++ standardization infrastructure.

Post by m***@gmail.com
Have to agree with the OP, the situation is very confusing.
What it makes it even more so is Call for Library Proposals
<http://open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3370.html>
Which for example points not Hal Finkel, but <lwgchair at gmail.com> to
send to.
And there is also How To Submit a New Issue / Defect Report
<https://isocpp.org/std/submit-issue> that also adds <wmm at edg.com>
"for core language issues."
This leads indeed to the assumption hfinkel at anl.gov is *only *fro for
WG21 committee members,
which in tern makes one wonder "If for Library I must send to lwgchair,
and I am not a member, then probably, for EWG, there is some

Post by m***@visma.com
Hello,
I need a little clarification on the proposal submission process. I'm
sorry if this has been answered already, but I could not find it on the
forum.
I read the explanation for how to make a submission from here
https://isocpp.org/std/submit-a-proposal but it's unclear. It says that
one should post the idea here, then draft a proposal, post that here,
iterate and improve it until it's in a mature form that can be submitted.
And then what? It does not say where or how to send the proposal. There is
another document
https://isocpp.org/std/standing-documents/sd-7-mailing-procedures-and-how-to-write-papers
that is for WG21 committee members only.
So where do I send a proposal?
Thank you,
Marius

--
You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5c35e7ea-08ef-48bb-81eb-f8596e5c94fb%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5c35e7ea-08ef-48bb-81eb-f8596e5c94fb%40isocpp.org?utm_medium=email&utm_source=footer>
.

[p***@lib.hu]

The C++ committee has been around for a long time; unfortunately, our
infrastructure hasn't aged or scaled as well as we might have hoped.

Post by Bryce Adelstein Lelbach aka wash
We are actively working on improving C++ standardization infrastructure.

I have to agree with OP that the information on the site is only half
helpful. I suggest to add Arthur's excellent answer to the
submit-a-proposal page or place it right after. While at it links to some
moral documents created recently could be added, like Bjarne's Remember the
Wasa. Along with quote from D&E where the old policy was to require each
submission also donate a kidney.

If the current somewhat obscure path is intentional to deter half-baked
papers and general flood, it's not really working looking at just the most
recent list of submissions.

[Jake Arkinstall]

The whole process looks like something you'd expect from a Vogon town
planning committee, not one of developers with a massive following of
people who would be more than happy to contribute their time. If I see code
with large amounts of comments to help a user understand what it does, the
first thing I think is that the code must be pretty bad. Here I'm seeing a
process that has a variety of documents to explain the process, and that
makes me think that the process is pretty bad.

The problem is not that we have such a large community that proposals are
hard to manage. It's that the wider community isn't being leveraged - the
very means by which low quality submissions are shut out (by making the
process opaque and awkward) is the direct cause of the growing pains, from
what I can see, because the community simply can't help with the
discussions.

It would be beneficial, IMO, to have a centralised place to have this all
in the open. A submission could create a git repo equipped with a weighted
voting system. No more baffling red/green inline edits because there's a
commit history, and we can save proposers time by having proposals in HTML
rather than typesetting for PDF (with a standardised stylesheet and
bootstrap document to start from). Summaries of meeting discussions can be
provided in a discussion file in the paper repo so that everyone knows
what's going on.

The up vote system is how you'd select papers for discussion. Members of
differing relevant experience can have different weights on their votes,
and, once a threshold is passed, a paper number is allocated (committee
members having a vote weight on the order of the passing threshold, and
brand new members having negligible weight to counter spambots). Downvotes
exist too, so controversial proposals (E.g. Named parameters) need to make
headway enough to convince downvotes to flip.

That's how a standardisation process might look if it was designed in the
21st century. *I know I'm a newbie, so there will be details I'm not aware
of that prevent such a system from being implemented*, but I can't see how
the current approach is going to cope with the growing community for more
than a few more years, and IMHO the only way of truly coping with a growing
community is to *use* the community to help you narrow down proposals.

[Matthew Woehlke]

Post by Jake Arkinstall
we can save proposers time by having proposals in HTML
rather than typesetting for PDF (with a standardised stylesheet and
bootstrap document to start from).

Enforcing a particular format for submitting proposals will certainly be
a double edged sword.

While I do like the look of the w3c template, I prefer to write my
proposals in reST. Others prefer to write their proposals in MD, and I
can only surmise that some people actually prefer tex.

Post by Jake Arkinstall
Summaries of meeting discussions can be
provided in a discussion file in the paper repo so that everyone knows
what's going on.

That would be nice. (Although, I should note that these *are* available
to some extent on the internal wiki.)

[p***@lib.hu]

2018. október 24., szerda 18:36:25 UTC+2 időpontban Matthew Woehlke a

Post by Matthew Woehlke

Post by Jake Arkinstall
Summaries of meeting discussions can be
provided in a discussion file in the paper repo so that everyone knows
what's going on.

That would be nice. (Although, I should note that these *are* available
to some extent on the internal wiki.)

Jake's system reads nice and addresses some problems. But IMHO mostly of
the theoretical kind.

However the latter is a serious issue and we could use improvements. The
internal wiki is great as long as we talk about CWG. But even that is hard
to use unless one just knows from the top of the head when a particular
proposal was discussed.

The system works okay-ish for papers that progress and eventually gets
adopted. As the authors provide summary of direction, changes, etc in the
followup.

But the information related to proposals that got outright rejected or just
die for lack of further work is (IME) lost. And that is bad. As the idea
will pop up again and waste more valuable time on repetition. Or if someone
would work on a different track, can not learn from what were the actual
concerns, that he could address right up front.

Ideally some discussion summary would be accessible right beside the paper
in the document store.

A related problem is that it is nuclear what the status of a proposal is.
Whether it is just waiting its next iteration or is abandoned.

Some of the impact may be covered by the volume of incoming new proposals,
but it is still a huge waste. And someone migh find a way to reduce it
without much extra effort.

[m***@gmail.com]

Many good points, however note that people do not do the bare minimum even
today - to have the proposal here first.
Vast majority of proposals do not get ANY feedback before published - case
in points the so called "simple papers" that someone posted on reedit last
few days.

Many of these papers would have gotten SOME feedback and some of them
would have been discouraged, like the recent "allow $ in identifiers"
OR at least a better motivation would have been advised.

Post by Jake Arkinstall
The whole process looks like something you'd expect from a Vogon town
planning committee, not one of developers with a massive following of
people who would be more than happy to contribute their time. If I see code
with large amounts of comments to help a user understand what it does, the
first thing I think is that the code must be pretty bad. Here I'm seeing a
process that has a variety of documents to explain the process, and that
makes me think that the process is pretty bad.
The problem is not that we have such a large community that proposals are
hard to manage. It's that the wider community isn't being leveraged - the
very means by which low quality submissions are shut out (by making the
process opaque and awkward) is the direct cause of the growing pains, from
what I can see, because the community simply can't help with the
discussions.
It would be beneficial, IMO, to have a centralised place to have this all
in the open. A submission could create a git repo equipped with a weighted
voting system. No more baffling red/green inline edits because there's a
commit history, and we can save proposers time by having proposals in HTML
rather than typesetting for PDF (with a standardised stylesheet and
bootstrap document to start from). Summaries of meeting discussions can be
provided in a discussion file in the paper repo so that everyone knows
what's going on.
The up vote system is how you'd select papers for discussion. Members of
differing relevant experience can have different weights on their votes,
and, once a threshold is passed, a paper number is allocated (committee
members having a vote weight on the order of the passing threshold, and
brand new members having negligible weight to counter spambots). Downvotes
exist too, so controversial proposals (E.g. Named parameters) need to make
headway enough to convince downvotes to flip.
That's how a standardisation process might look if it was designed in the
21st century. *I know I'm a newbie, so there will be details I'm not
aware of that prevent such a system from being implemented*, but I can't
see how the current approach is going to cope with the growing community
for more than a few more years, and IMHO the only way of truly coping with
a growing community is to *use* the community to help you narrow down
proposals.