On Thu, Jan 24, 2013 at 7:31 PM, Beman Dawes <bdawes@acm.org> wrote:
> Fernando,
>

I realise now that Andrezej, me and most likely quite a lot of the
people working on a std proposal don't have a complete understanding
about how the process actually is.
We only have some perception of what's going to happen and that
affects the contents of the proposal.

So, let me try to get a better grip of how this works.

> While std-proposals and other mailing lists are great for gettin
> community feedback, the only way to know for sure if a feature is so
> controversial that it must be pulled is to ask the LEWG, LWG, or SG
> processing the proposal for a vote at a meeting.

OK.
How do we do that?

Do we just file in the paper in a given state, wait for the meeting,
get the feedback, proceed to ++ revision, and iterate once more?

That's how I've been thinking it is, but then time is against us so we
tried to get the proposal as best as possible right now.

But maybe there is more dynamic and proactive way to scan the WG/SG
*before* filing it?

>That is particularly
> true for something like optional that has a long history of
> wide-spread use. So you should propose what you think is best for the
> standard library. Trust yourself. The committee will strike the
> function if they think it is a problem - that's part of their job.
>

Ah.. now that's interesting.

Part of my (wrong it seems) impression was that a given paper was
either entirely accepted or entirely rejected. That you wouldn't just
remove the parts that are a problem and keep the rest.

If that is the process then it means we can:

Organize the paper as a core proposal and then a sequence of optional
features. That's quite similar to what we had in mind but not quite
the same, because I planned to have the optional parts filed as
separate documents such that they might not even be ready for the next
meeting.

Other related questions about the process:

1) Is it OK for a proposal to have something like: we (perhaps
optionally) propose THIS. If THIS is not accepted then we propose THAT
instead (and possibly so on with more than one else) ?

2) Can a feature be accepted but not in the exact way proposed?
Putting it another way: is the WG/SG required to either accept/reject
or can it agree on the idea presented but give it its own
secification?  For the case of a free functions such as get_value_or,
it might well happen that the exact way in which we come up with it is
not sufficiently right, but then the WG/SG figures out the right way
to do it so the corrected version is accepted.

3) (I asked this above already) Is there a more direct way to get into
a conversation with voting committee members in preparation for a
proposal, other than here?

Best

--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.