As the creator of the SE Stack Exchange proposal, let me address some points made in this question.
I assume this will not be the case on the Software Engineering site. The Engineering site can, and should, insist on non-subjective questions, insofar as such questions can be made non-subjective with respect to the Software Engineering process.
That is my intention. I would suspect that the Programmers would be a home to more subjective software engineering questions, as well as subjective programming questions. There are a number of very objective software engineering questions, as long as they are framed within a given context.
A question like "What’s the best method for estimation?" by itself is very subjective. However, given additional information about the project and team, it's very possible to make a right decision between the major methods of software estimation: Wideband Delphi, COCOMO, SLIM, Function Point Analysis, PROBE, Planning Poker, and Evidenced Based Scheduling. I would suspect that the question of estimation (as an example) would be asked again and again, but framed within a very different context, making different answers appropriate.
Part of the problem goes back to the limited nature of Area 51 - we were defining types of questions that were on-topic, not specific questions (this was discussed repeatedly in the comments, where someone said the idea was on-topic, but the question would need additional information to be acceptable). The example of "best estimation method" being an on-topic question doesn't mean a question "What is the best estimation method?" would remain open - I would vote to close it ASAP unless it was in a particular context.
Justification for prototyping is probably answerable in a non-subjective way.
Indeed it is. The good thing about software engineering is the body of research available through organizations such as the ACM, IEEE, and BCS (among others). You can site specific business and software engineering reasons for prototyping.
In theory, there should be a clear difference between "programming" and "software engineering", with questions on the former going to SO and questions on the latter going to this new site. In practice, it's all the same elephant.
Programming is not the same as software engineering in practice. Programming (formally called Software Construction by the IEEE) is one of 11 Software Engineering Knowledge Areas defined in the Guide to the Software Engineering Body of Knowledge. The SE Stack Exchange is for the other 10.
The limited description space available did not allow me to enumerate all of the on-topic knowledge areas for the Stack Exchange. All specific, objective questions related to requirements, design, construction (aside from implementation-specific questions), testing (aside from test implementation questions), maintenance, configuration management (aside from specific tool questions), SE management, SE process, and quality will be on topic.
In addition, questions about computer engineering (computer architecture and organization, digital logic, distributed systems, embedded systems, networks, VLSI), computer science (HCI, basic computer science theory [more advanced questions should be moved to the Theoretical Computer Science exchange]), management (law, human resource management, economics, business policies), mathematics (calculus, statistics, discrete mathematics), project management, quality management, software ergonomics, and systems engineering would be on-topic if and only if they were related directly to problem a software engineer would face. Removed per comments - and I agree, now that I see more proposals for these areas. When I created the SE Stack Exchange proposal, the only related areas that had a proposal was Computer Science.
Software Engineering.SE is only for high-level topics; anything specific is off-topic and belongs on another site. Why not ask the high level questions on the more specific sites, then?
To reinforce my previous point, the only questions that would be off-topic would be in the knowledge areas defined by the IEEE as supplemental to software engineering and only if a more appropriate Stack Exchange existed. These areas are computer engineering (no exchange yet), computer science (Theoretical CS Stack Exchange), management (no exchange yet), mathematics (Mathematics and Statistical Analysis Exchanges), project management (no exchange yet), quality management (no exchange yet), software ergonomics (potentially the User Interface Stack Exchange), and systems engineering (no exchange yet). Specific implementation and tool questions can be directed to Programmers and/or Stack Overflow as appropriate, as well.
This is similar to how there was more latitude on Stack Overflow to system administration questions before Server Fault opened, and the fact that Stack Overflow continues to allow questions on requirements, design, architecture, process, and more even through a strict interpretation of the SO FAQ would make these questions off-topic.
These are only tangentially related to software engineering and would be best to move them to an appropriate Stack Exchange, leaving the Software Engineering Stack Exchange to focus on the 10 core Knowledge Areas defined by the IEEE in the Software Engineering Body of Knowledge.
I think it makes more sense to let Programmers.SE get through beta before deciding we need another site covering similar ground: maybe it's the case that Programmers.SE is unviable, and Software Engineers.SE winds up being a better reformulation of the same concept.
I think this is the best option. We should let Programmers, Stack Overflow, and Software Engineering co-exist for a while and define boundaries. Once Programmers and Software Engineering have a chance to go through betas, then the possibility of merging or redefining can be discussed. But right now, I see a clear separation.
So far, the definition of the SE Stack Exchange is pretty much mine and mine alone, based on the IEEE and ACM definitions of software engineering as well as my university's curriculum for an undergraduate degree in software engineering. I would suspect that the community would help to narrow or at least better define the exact scope down during the private beta, and perhaps even into the public beta.
My feeling on this, and the reason I didn't bother committing to the Software Engineering SE, is that the definition of the SE.SE proposal blows chunks.
I wrote it, and I agree with you. See above - the space I was given to write the definition was insufficiently small. If I had about 5000-7500 characters, I could have done it and done it well. I was trying to boil down the IEEE and ACM definition of software engineering to 500 characters, and it didn't work that well.
But, as I said, the actual definition of the SE.SE proposal sucks because, perhaps rather predictably, the majority of votes went to loosey-goosey discussion questions like "What's the best method for estimation?"
The reason for the loose questions is because Area 51 didn't allow anyone to write up a full question. As discussed above and in comments on Area 51, if the question was not well framed in a very specific context, I would expect it to be closed. The best method for estimation depends on a lot of variables. If you define the variables, then it's a good question. Asking questions about the best X without providing a situation Y would be, I would hope, disallowed by the community as there's no value there.
Apparently Scrum is "software engineering" now.
It is. Scrum is an agile process methodology, and software engineering processes, process methodologies, and process models are a core component to software engineering. In fact, I would argue that process is one of two things that separates a software engineer from a programmer. The other being a full life cycle approach to problems.
Software Engineering is not even actively practiced or understood by most programmers.
YES! And I'm hoping that this Stack Exchange can help change that in some small way. Along with the much more powerful efforts of organizations such as the IEEE, ACM, and universities who offer Software Engineering degrees at the undergraduate or graduate levels.
I'm currently in the middle of a quarter here at school, so I might not be browsing the Metas as often as I did over the summer, but I'll still be browsing SO, Programmers, and the SE Exchange if it ever goes beta. If anyone raises a point that they want me to explicitly address quickly regarding this proposal, shoot me an email - email@example.com. I can't promise an immediate response, but it'll happen faster than if I had to mosey back here to read anything new.