It would be funny if they were doing this in hopes of just one-upping the BCN devs and their 2 year head start. That's not what's happening here right?
It sounds to me that it is.
I hope they include you. Would be a huge mistake to not.
I'm not interested in participating in a secret process. I'll comment on public proposals, as I have time available and if they're remotely interesting.
It's almost like these people have never been involved with Bitcoin development. I mean, I can understand plans for BCN still being secretly discussed at this time, but to do that with community-oriented clones? What a joke.
They haven't, as far as I know.
In the case of exploitable vulnerabilities keeping people safe can be at odds with transparency. In Bitcoin what we've tried to do is narrow any vulnerability down the a non-consensus behavior where implementations would reasonably expect to differ, or the smallest 'bad' behavior, the corner case the attack requires that no one had previously considered, and narrowly fix that... The idea is that the broad behavior of the system is part of the contract between all of the users that no one has the right or ability to just unilaterally change— but some "it crashes in this case" wasn't part of the contract, and if we carefully remove only the crash via a not-very-transparent change which is compatible with people continuing to run the old code, then we've done the minimum evil there.
Changes to the long term, broad scale behavior, stuff which isn't an immediately exploitable vulnerability— that stuff absolutely must be discussed in the open. It's hard enough getting quality review for complex design decisions in cryptographic protocols which are openly discussed, moving in the shadows is suicide. It's true that in theory people can suss out the behavior of these things from the code-drop patches and decide to run them or not— call the alarm bells that the developers have hidden some kind of concerning change, but the cost of reliably finding that stuff is high. If a situation is created where a publicly used cryptocurrency has a cabal that is making large design changes in secret, then thats not a really decenteralized system. Technical compeition isn't an excuse for undermining the decentralization that supposedly makes this stuff valuable in the first place, it's just another example of the shittyness of the altcoin space— they're often developed by greedy people who put their profit first. This has been a complain I've raised a couple times with the Bytecoin-forks, their openness-relative-to-bytecoin sales pitch doesn't really seem to agree with their behavior.
Of course, that kind of hyper competitive approach also makes it hard to report actual vulnerabilities— the more competition there is, the more concern that if you report it to them they'll just use it to attack each other.
In this case perhaps the brain damaged block sizes are more immediately exploitable that I suspected, I was expecting it to be discussed in the open because I believed it was only a long term disaster, not also a short term one too. If so, I'm sorry for whining that the development of the fixes isn't in the open; though I'd still encourage everyone to separate narrow fixes from more substantive changes.
As you can see from these posts, the need is there. As they say in marketing, "See a need and fill it." 
