Thread: [Embedlets-developer] Re: Development phase game plan
Status: Alpha
Brought to you by:
tkosan
Menu
▾
▴
embedlets-developer
|
From: Andrzej J. T. <an...@ch...> - 2003-02-01 00:11:18
|
Ted suggests: > 1) That we officially choose a project manager for the project. I vote for Ted as PM. He's been doing a marvelous job so far.... > I think that everyone would probably agree that we are now ready to start > tightening up the project and moving on to the project's Development > phase. Thankfully, the Brainstorming phase of the project has provided a > rich base of ideas for us to work with. Actually, Ted, I'm going to be a bit contrary. I don't think we're ready for development yet. We haven't got an architecture yet....and then we need to spec out the interfaces and contracts that will make up this architecture. That will likely require a lot of brainstorming still. Then we'll be ready to "develop" some code. \ If you were using the term "development" in a more generic sense (develop the architecture/specs/etc) then I'm in agreement...but would caution you not to use a word that can be mis-interpreted so easily by programmer types. > I think it is important for us to keep in mind that we will be developing > a full-blown Embedlets specification which should be very similar to the > Servlet specification. The current Servlet specification is 257 pages > long, includes a large number of sections, a significant amount of > formatting and a very detailed table of contents. I think that the Embedlets spec needs to be a lot simpler than than the servlet spec, otherwise we're going to spend too long on it, and risk making things a bit too complicated for developers of Embedlets. It should also be possible to spec out certain areas and then do some prototyping of a reference implementation while other parts of the spec are still being worked on. Interative and modular approach....delivery early, deliver often. Keep in mind that documentation usually lags badly in open source projects. It would be nice if Embedlets didn't fall into this trap. Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Christopher S. <cs...@oo...> - 2003-02-01 01:02:56
|
I am in full agreement with Andrzej on the limited scope and specification process. The modular rapid design appoach is to my liking as well. I have indicated to Ted that I can offload some of the project managment tasks as I have experience in this area. (not that I like it, I just have to do it!). Source Forge has some tools for this that I will look into. Ideally we should be able to put a self-management structure in place that is really just a status reporting and synchronization procedure. -----Original Message----- From: emb...@li... [mailto:emb...@li...]On Behalf Of Andrzej Jan Taramina Sent: Friday, January 31, 2003 4:10 PM To: emb...@li... Subject: [Embedlets-developer] Re: Development phase game plan Ted suggests: > 1) That we officially choose a project manager for the project. I vote for Ted as PM. He's been doing a marvelous job so far.... > I think that everyone would probably agree that we are now ready to start > tightening up the project and moving on to the project's Development > phase. Thankfully, the Brainstorming phase of the project has provided a > rich base of ideas for us to work with. Actually, Ted, I'm going to be a bit contrary. I don't think we're ready for development yet. We haven't got an architecture yet....and then we need to spec out the interfaces and contracts that will make up this architecture. That will likely require a lot of brainstorming still. Then we'll be ready to "develop" some code. \ If you were using the term "development" in a more generic sense (develop the architecture/specs/etc) then I'm in agreement...but would caution you not to use a word that can be mis-interpreted so easily by programmer types. > I think it is important for us to keep in mind that we will be developing > a full-blown Embedlets specification which should be very similar to the > Servlet specification. The current Servlet specification is 257 pages > long, includes a large number of sections, a significant amount of > formatting and a very detailed table of contents. I think that the Embedlets spec needs to be a lot simpler than than the servlet spec, otherwise we're going to spend too long on it, and risk making things a bit too complicated for developers of Embedlets. It should also be possible to spec out certain areas and then do some prototyping of a reference implementation while other parts of the spec are still being worked on. Interative and modular approach....delivery early, deliver often. Keep in mind that documentation usually lags badly in open source projects. It would be nice if Embedlets didn't fall into this trap. Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com ------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com _______________________________________________ Embedlets-developer mailing list Emb...@li... https://lists.sourceforge.net/lists/listinfo/embedlets-developer |
|
From: Brill P. <bri...@ro...> - 2003-02-02 10:16:35
|
> I am in full agreement with Andrzej on the limited scope and specification > process. The modular rapid design appoach is to my liking as well. > > I have indicated to Ted that I can offload some of the project managment > tasks as I have experience in this area. (not that I like it, I just have to > do it!). Source Forge has some tools for this that I will look into. Ideally > we should be able to put a self-management structure in place that is really > just a status reporting and synchronization procedure. The sourcefore tools are fairly good... allowing task assignment and tracking... as well as documentation etc. (I've also got a little experience in management, but I'm not volunteering as I'm way too busy as it is). What might be a good way to go about the specs, is to assign portions of them to individuals for a period of time, then rotate them... now that I think about it, that might be a very good way to do it, a sort of modified pair-programming model ;) Anyway, we can start on setting up the task tracking etc, ASAP, as it will help give some structure to what we're doing. - Brill Pappin |
|
From: Ted K. <tk...@ya...> - 2003-02-01 07:16:20
|
Andrzej, > If you were using the term "development" in a more generic sense (develop > the architecture/specs/etc) then I'm in agreement...but would caution you not > > to use a word that can be mis-interpreted so easily by programmer types. Point taken. My main idea was to indicate that we were moving out of the open-ended brainstorming stage and into a getting-down-to-work stage. If development is not a good word to use here then what is a better way to describe this phase? Ted __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com |
|
From: Brill P. <bri...@ro...> - 2003-02-02 10:16:42
|
design, requirements management ;) - Brill Pappin > If development is not a good word to use here then what is a better way to > describe this phase? |
|
From: Brill P. <bri...@ro...> - 2003-02-02 10:11:15
|
> Actually, Ted, I'm going to be a bit contrary. I don't think we're ready for > development yet. We haven't got an architecture yet....and then we need to > spec out the interfaces and contracts that will make up this architecture. That > will likely require a lot of brainstorming still. Then we'll be ready to "develop" I don't think we even really have the user requirements yet, let alone the technical specs... How many of us have architecture experience from the *start*? Maybe someone could "port" a template document over for us, once we have the document format sorted out... I have some myself... in Word of course ;) but they could be easily ported to whatever we're going to use. Personally, I love "just doing it" but I think for this one, with so many active people working on it, we definitely need a little more structure. - Brill Pappin |