Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [technology-pmc] STEM proposal

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

Back to the top