To address your comment about "initial
components", are you thinking that we should list particular components of
STEM's architecture, for instance it's component UML models, or specific
plugins? What are you thinking would be considered a
"component"?
[kosta] No need to be terribly
specific. I would certainly not list plugins. Just list the various broad
functional areas. I was mainly suggesting this because it struck me that a lot
of the content in your scope section described current components rather than
setting the boundaries for the project.
To address your comment about "near-term
specifics", are you looking for a development plan? If so, wouldn't
that make more sense in the "Tentative Plan" section?
[kosta] Nope. The thing to
understand is that the scope section is the only part of the project proposal
that remains relevant long after the project is created. You want it to be
worded such that five years down the road when you’ve moved to tackling
different parts of the problem, the scope is still relevant in guiding the
project.
The last
paragraph you refer to, explains that STEM has general features that make
it applicable to more than the specific domain of disease modeling. It
was included to clarify the technical aspects (scope?) of STEM that make it
more than just a niche project. This is important because niche projects
will have trouble attracting a large enough community to sustain them and from
which to recruit committers.
[kosta] It is definitely
important to not create scope that is too constricted for your future needs,
but at the same time the last paragraph is too general. It can be read as
modifying the scope to be as general as anything modeling related. I am sure
that’s not your intention, but that’s why I am saying that you need
to be more specific here. If you goal is to create a more general project than
one that just focuses on disease modeling, that’s fine, but then your scope
section needs to carefully explain the territory that you are staking out in
sufficient detail so that your scope can be differentiated from scope of other
projects (such as EMF). Note that it is not a requirement that projects don’t
have overlapping scope, but the more overlap there is, the more questions will
be raised regarding collaboration rather than competition.
Hope this is making sense.
- Konstantin