I would like to add that this set of goals have served us well through the incubation and graduation processes.
That is precisely the reason why the goals should be crisply added to the project homepage and documentation. So far, there were only a few people contributing to the project and now there would be many more. The goals were clear to these early contributors but it would start causing confusion moving forward.
Our project has to have a clear set of bylaws defining, among other things, set of voting rules, and so on and so far. So, let's deal with that first and foremost.
+1 on the need to have clarity on the bylaws. But that doesn't seem to suggest that we shouldn't improve wiki navigation and fix general documentation.
1. A component be part of the Apache Hadoop ecosystem (per your comment about "Big Data" we need to define that better but I'd start with integrates with and/or is powered by Apache Hadoop).
2. A requirement that all components are added to trunk before release branches. We articulate something similar in Hadoop (see http://wiki.apache.org/hadoop/Roadmap), in general it's good to be trunk first so different Bigtop releases don't have inconsistent components
+1, The community already has several commercially supported Hadoop distros - that are meant to be stable and have inconsistent set of components for their respective corporate reasons. These are already causing plenty of confusion in a user's mind. Bigtop distro doesn't necessarily need to be a production ready distro and doesn't need to have inconsistent branches. Bigtop is first and foremost serving the purpose of being a bleeding edge collection of hadoop components, and so it needs to grow up in one direction. With that thought a Trunk First Model sounds fundamental to Bigtop, IMO.
3. A requirement that new components work with all of the existing components before they are included in a release. New additions can bake in trunk or a feature branch but we shouldn't release them until they work with the rest of the stack (for the other parts of the stack they interact with).
4. I'd clarify that the projects dependencies need to be ASFv2 compatible (which is implied but better to be clear)
+1, It is better to be clear and even more so now
5. I'd consider making integration testing a hard requirement
+1, Without integration testing it would be become a mess