While we welcome all participants, not all participants will be able to contribute effectively in all fields. Therefore, we will start with one gatekeeper--myself, Bruce Webster--and slowly expand the list of those who will examine and accept or reject what is contributed.
From the white paper:
The dictionary defines expertise as "expert advice or opinion...specialized knowledge or skill". Expertise is an obvious essential factor in the quality of software you're developing. Studies have borne this out (e.g., Boehm, 1981), showing that the skill and the experience of the people involved in a software project are the most significant predictors of whether that project will succeed. Indeed, many organizations come to rely (unwisely) upon "hero-based" management, development, and/or quality assurance to deliver software.
In this context, expertise resides in the people involved in the software development process and comprises at least three factors:
understanding of the relevant field, topic, or activity, including competing theories and approaches;
significant experience (time * effort) in the relevant activities;
demonstrable skill at successfully producing the relevant deliverables.
You must seek out expertise for all roles involved: managers, analysts, domain experts, architects, development and quality engineers, and so on. Again, this appears obvious, but often the importance of expertise for certain roles is minimized, such as (ironically) for quality engineers. This can be a bit like grabbing the random stranger off the street and asking him or her to wallpaper the interior of your house. You may actually get someone who happens to have the experience and/or skill to do a good job, but in all the other cases, the results will be less than desirable.