I guess with this definition, something like "Project Rocket" would be a Program, and the different Stages within it would be Projects?

That's what I was thinking. Each individual "module" be its own "project". Programs are made up of multiple projects which are then used

concurrently to carry out the "missions" that the "stages" describe. Project Mannedflight would be made up of at least the RM and OM as it's currently stated, both which would be best developed as individual projects in the ODE. As the Wikipedia definition states, new projects could be added that are in the category of Manned Flight — such as a lunar lander, or a space suit.

Antinode, I agree that simplification, where possible, is very important.  As Greg pointed out, some of those tabs are in the screenshots because we wanted to see what they were, not necessarily because we thought they should be there.  The question about calling project related work "issues" or "tasks" is one I am on the fence about.  I am not sure I like either very well, but could live with either if other folks were attached to one or the other.  If I think of a third option I like better I'll be sure to post it.  

Regarding files, wikis, documents, and repositories...  This is actually something that I think we need to work on a little bit more.  I have seen engineering teams try to cram their work into traditional source code control systems (SVN, bzr, etc) and for anything beyond small projects it just does not seem to work.  Too many of the files that are generated are one off things such as wind tunnel data or the results of a CFD run(so version control is not exactly helpful).  Those that are good for versioning are often binary files (which is something source code control systems really are not geared toward handling either).  And then there are the large files (video, CFD or FEA output files, etc) which can be in the GB size and will break most source code control systems.  And all of that is before we talk about how best to organize the files with respect to projects and sub-projects or what content should be stored in files and what content should be in the wiki (for easy editing and sharing).  Like I said, I think there is some work to be done here.  I will try to put together some concrete examples to discuss over the next few days.  

Luke, regarding a version 0.0 of ODE that focuses on the basics and then working toward adding in project management tools...  This is what Mach 30 folks concluded was the best course of action when we were discussing this in house.   I think our primary reasons were that the scale of projects we will be starting with don't strictly require a sophisticated management tools and as you pointed out using the tool will hopefully inform us about what kinds of management tools we really need in ODE.  Here are the minutes from the meeting where we discussed this last at Mach 30.

Like I said, I'll try to put some examples about content storage together soon.  Until then...

Programs are made up of projects. Projects also have start and end
dates and are specific to deliverables, whereas programs do NOT have a
specific end date as they are created to meet a strategic or tactical
aim. e.g Program might have a main objective to improve customer
service and there will be more than one project created to meet that
aim such as project to improve delivery times, project to shorten wait
on phones, project to create and ringback and follow-up. New projects
are added (and removed) depending on changes in strategy, budget,
resources and are prioritised accordingly.

I guess with this definition, something like "Project Rocket" would be a Program, and the different Stages within it would be Projects?

I've been thinking more about the program/project thing.  I don't know how universal this is, but to me, "program" has connotations of a long-term endeavour, with lots of individual steps, with an uncertain total duration.  The "X Program" sounds like it should have "X 1", "X 2", etc, for as long as it takes us to complete the program's goals.  In contrast "project" sounds to me like more of a one-off, clearly defined effort without subdivisons.  Do other people have this intuitive understanding?  If so, how do we think this applies to our projects/programs/whatever.

On the one hand, the currently proposed 4 projects/programs do have a stage structure, which is inline with the pluralistic interpretation of "program".  On the other hand, I envision them as being efforts to produce the technology to enable other projects/programs which will be even more program like.  E.g. once we have a proven generic CubeSat infrastructure, we might decide to use it to investigate some specific scientific phenomenon, and that could be a long term endeavour that we don't immediately know the duration of - we might have to keep laucnhing ever more advanecd satellites as part of that Program until we finally have all the data we need for our purposes.  Compared to something like, something like "Project Rocket" seems fairly limited in scope.

Perhaps I'm making too big a deal out of this.  What do other people think?

I notice that NASA don't seem particularly consistent in their use of these words.  This page seems to use some definitions whereby "Project Apollo" was a "Program", which I consider somewhat confusing.

J. and I have had many discussions about exactly how much management support this tool should provide.  Where exactly is the line between design work & project management and how does systems engineering process apply here?  I think schedule and budget are reasonable discussion topics when deciding on which features to include.  I can think of reasons to include these features, but also understand the desire to simplify version 0.0 and develop a core capability first, on which to build.

I think that this is probably going to be one of the hardest things about this project to get right.  Everything else, like management of files and repos, issue lists, Wikis, discussion and messaging, etc. is relatively clear cut compared to high level project management.  I do have to admit being tempted by the option of going ahead with a 0.0 version which leaves most of this out and adding project management stuff slowly as we get experience using the 0.0 version (and hence get an idea about which project management features are most needed), but I am aware that if we have some ideas from the start we may be able to design the general architecture of the app so as to better facilitate the later project stuff.

I'm still undecided to the use of a seperate project Wiki. I think it would make more sense to have the top level "Wiki" information be contained on the project overview/landing page, which contains links to the subsystem pages, rather than having two seperate project info pages.

My biggest concern with per-project Wikis is that if the work involved in each "top level project" (e.g. projects like OHKLA, CLLARE) is divided up into sub-projects (and I think we are all in agreement about this being a good way for things to work), it means that Wiki material relevant to a single top level project will be extremely scattered.  There won't be an "OHKLA Wiki", there'll be an "OHKLA Propulsion Wiki" and an "OHKLA Avionics Wiki", etc, etc.  I think it would be best to have any Wiki-esque material for a given top level project in a single Wiki, for the sake of simplicity and clarity.

@antinode: 1) Excellent comments, and I appreciate the desire for simplicity.  2) You mentioned that you have also made an initial mockup.  I must have missed it if you made it available to view from this forum.  Is it possible for you to repost the link so that I can check it out?  3) I agree, and was confused when it came to the nuances between Documents, Wikis, Repositories and Files, and I did not get enough hands on experience to understand the different uses for each.  Simply, they were all included in the basic redmine functionality and therefore easy to turn on and off for testing.  4) J. and I have had many discussions about exactly how much management support this tool should provide.  Where exactly is the line between design work & project management and how does systems engineering process apply here?  I think schedule and budget are reasonable discussion topics when deciding on which features to include.  I can think of reasons to include these features, but also understand the desire to simplify version 0.0 and develop a core capability first, on which to build.  In terms of naming "tasks" vs "issues" the decision is again about how much management to include.  For a project managemnet application using the term "tasks" is the way to go, but as an developmental engineer I prefer the term "issues" to represent the fluidity of the design process.  The misplaced negative connotation comes from managers who treat any deviation or delay in the product lifecycle as a failure.  There is nothing wrong with taking a step back to analyze a certain aspect of the design, or the need to make  modifications if something is not working (…alas, I find myself on a soapbox, unintentionally!  Sorry about that).  To generalize, my philosophy when developing this application concept has been to find the minimum set of capability needed to facilitate the systems engineering design process for projects of varying scales. 

@Luke, Thank you for your lengthy and insightful posts, both in this and other forums. 

This online collaborative design methodology for physical items (SourceForge for hardware) is different than any type of process that has been tried before and I guarantee that we will need many iterations before we "get it right."  Using asynchronous distributed collaboration to develop it is even more of a challenge so I want to congratulate everyone for working together on it.  Comments and quetsions are welcomed.  I'd encourage open communication.  I am glad that we have found some traction and I look forward to continuing progress.

The views/architecture is something I considered a lot when I made my initial mockup. I considered existing architectures for both open and closed source project managment web apps, as well as the features that our app would need. I found a lot of overcomplication. Your mockup for instance has Files, Documents, and Repository tabs, which could better be simplified into one tab that manages all files in a repository frontend. Likewise Issues and New Issues would better be combined into one tab, with various views, perhaps including Gantt. I personally prefer calling them Tasks rather than Issues as calling them Issues makes them seem like a problem. Discussions would best be tied to the actual individual tasks and the tasks tree, rather than a seperate forum, though a place for non-technical discussions is probably a good idea. I'm still undecided to the use of a seperate project Wiki. I think it would make more sense to have the top level "Wiki" information be contained on the project overview/landing page, which contains links to the subsystem pages, rather than having two seperate project info pages.

No worries about the 3 week delay!  It's not like the rest of us have been busily carrying on without you!

I'm going to use what spare time I have tonight to make blog posts about the current directions of the org, but the next time I get a chance I will look over all the links etc. you just posted in some detail and get back to you.  After a very quick cursory glance at your ODE pdf, however, I can say that it looks really good and is definitely on track with what I had in mind.

Glad you think this is coming along well.  The idea of adding the software projects to that page is an excellent one which should have been obvious!  Thanks for catching that, I'll update it soon.

I can't believe it has been 3 weeks since my last post about this project.  Too long, too long...  This is my last quarter of classes for my PhD and it has been a killer.  Here's hoping I can keep with this now that classes are just about over.  

Luke, thanks again for the feedback.  My rather belated reply is basically "I can get behind most of that".  :)  In terms of licensing, it is much more important to me that we have an open license than a specific one (though I am still a proponent of the "add on to an existing tool" approach which probably requires adopting whatever license it is using, so I don't really want to get hung up on the licensing at this point anyway).  Regarding the name and having more details first, totally agree with all of that.  Though I am a little partial to the name ODE, but not so much that I can't get behind another name.

Rizwan, I'd like to get back to your idea about looking at wireframes/mockups of functionality.  Greg and I got together this weekend and did some screenshot of redmine as an ODE mockup.  The choice of redmine was much less about "let's use redmine" and more about playing with a new piece of tech.  I just stumbled across Turnkey Linux, and they have a redmine appliance, which just worked.  Once I had it running, I figured we should take it for a spin (kicking the tires of redmine has been on our to do list at Mach 30 for some time now) and while we were at it, take some screenshots and then draw over them where we thought things should change.  The pdf I linked to is the result.  While we were doing this, I also did some work organizing the features list in the wiki.  

Comments?    Alternative concepts for the views in the pdf?  Concepts for views that are missing?  

TL;DR - Thx Luke re: comments; Posted screenshots of redmine as mockup to discuss.

Just wanted to say that I think this is a good idea and is really shaping up.  Greg and I just had a conversation along similar lines for the Mach 30 website (basically coming to the conclusion that there needs to be more top level summary info about our current work that is easy to find).  I'll be sure to forward these pages to the rest of the Mach 30 board to take a look at to get the conversation going over here.

Luke, you might also want to list the software projects on the project page.  I am thinking about both the analysis codes I saw forum posts about (there is a reentry one I can't find off hand and USOFS), and ODE (which Mach 30 will be listing on our project page when we get that going on the site).  This would give software developers a place to plug into CSTART and help promote those projects that need those skills.

Speaking of ODE, I need to go upload some screenshots Greg and I worked on to act as mock ups to discuss and post that to the ODE discussion...

I found and contributed to a thread at stargazerslounge.com discussing optical arrays. The impression is that it's currently beyond amateur capacity to do so. However radio arrays may well be possible.

http://stargazerslounge.com/eq.....ost1368331

My primary point was that the recent developments in chip-scale atomic clocks could provide a readily accessible and accurate time-base. Would the next generation of GPS satelites be able to provide the nessesary relative positioning information?

I'm more than happy to consider a project->program and phase->stage renaming, that actually sounds more sensible to me, as well, I think.

What do you think about the current page for the CubeSat program?  I still haven't done a huge amount of CubeSat research, I don't know how well my proposed phase structure makes sense at the moment.  In particular I don't know realistically how many U units would be needed to achieve certain things.  From memory at the moment I have a whole U unit dedicated to orientation control, I don't know how realistic that is.  Since you were always the person most interested in the CubeSat program I'm extremely happy to hear ideas from you on a better stage structure etc.

The Kickstart project page looks great, largely the kind of thing I had in mind.