Good draft. Here's some ideas (not quite proposals) that might merit discussion:
1) Upping developers from 2 to 3. I'd rather have a rule that said three that we chose to break on occasion than to have to explain why 2 is barely sufficient. 2) Alignment with existing Apache subprojects. Code that is used by many existing subprojects is attractive. Code that makes use of alternatives to Apache code exclusively is less so. 3) Warning sign: developers who ONLY work on the task because it is their job. 4) Warning sign: lack of diversity in developers. For example, if all of the developers are from the same company... - Sam Ruby -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
