CSTART/Mach 30 Joint Venture for Web Based Engineering Project Management | Software projects | Forum

Post edited 11:47 pm – July 3, 2010 by J. Simmons

Luke,

First, just wanted to apologize for the delay in replying to your earlier post (I have been down most of the day with a migraine…).  Second, I want to thank you for your candor in both of your replies.  I think this is all good stuff to discuss.  I also wanted to say that the massive brain dump in my first post was only meant to give folks the full background of the work done to date at Mach 30, and not intended to say "we have the one right answer, let's go code some RoR," so please do not take the inclusion of redmine as a final solution from Mach 30's point of view.  It is just the best fit we have found to the project with what we had seen as the items needing to be addressed.

Speaking of items needing to be addressed, if it is alright, I would like to take a half step back from the details of our posts and pull out the "values" that I believe may be represented by the stated "positions" (this is a common part of the Mach 30 consensus process, and is how I often work with people to resolve difficult decisions; I am not sure how well this will work over a forum, or if I am overstepping my bounds by applying Mach 30 processes in the CSTART forums, so please excuse any pits I may be about to fall into).  Here are the broad values that I hear/read in the above posts, and the positions that I am drawing them from:

• Need something that works better than what "we" have now (CSTART has the wiki+forums+polls+version control system?, Mach 30 has its forums+phone bridge) <= see most of Luke's 2nd post, and the beginning of my post where I just comment that we need a system
• Getting something sooner would be better than later [was: Need to have something in place ASAP] <= I believe this comes out in both of Luke's post (both in terms of specifically calling for something very soon and in stating concerns about using tools he is unfamiliar with), and is really what motivates Mach 30's interest in building upon an existing system (redmine) and starting with a version 0.0 release that is made up entirely of existing features of that system
• It would be better if we can share the work and the rewards of developing this system both between CSTART and Mach 30 and with the larger community <= Mach 30 is specifically looking to share this with anyone that is interested and would love to work together with CSTART, and Luke expressed a desire to work together if possible both in this thread and in the previous thread that started this conversation
• Beyond having something ASAP, should aim to "release early, and release often" <= this is really what motivated the proto-road map at the bottom of my first post
• A key feature is the ability to manage "engineering decisions" <= Luke very eloquently described part of this feature in his 2nd post, and it is also roadmap item #3 from the Mach 30 discussions
• Need to be able to actually write the code for the solution <= this is my attempt to summarize Luke's concerns about redmine being RoR (after all you can't code well the first day you are using a new tool chain), and I want to completely agree with that concern, we selected redmine as a possible foundation based on its features not its tool chain, as we were going to have to look for coding help no matter what we chose, so the specific tool chain was not something we were selecting for at the time

I am pretty sure I am missing one or two things (it can take a little while to tease this kind of stuff out of a conversation), but I think this is a decent first stab.  If I am close on capturing these values (and please, please let me know if I am missing something or overstated something), then I think we are pretty close in terms of what we want to accomplish (which is the biggest hurdle to overcome).  Then I think the work would turn to looking at the differences in positions (for instance using redmine as a foundation) and looking for alternate solutions that better cover the values above (for instance perhaps looking for a php coded tool similar to redmine or looking for RoR coders that are excited about CSTART/Mach 30 and are looking for a way to get involved or something else entirely).

If this process looks like something that everyone is willing to try, I honestly think we could work through this decision process in a matter of days (though again, I usually do this real time, so it may be a bit bumpy over forums).  Let me know what you think.

——-

PS – Luke, you should check out the Architecture Decision Plugin (more details here) for redmine (not as a reason to go with redmine, but as a possible structure for the kind of engineering decisions you were talking about in your second post, I think you will find its features very interesting).

Luke,

Thanks for understanding, and yes I am doing much better today.  I am also very excited about working together on this project, and very happy to hear you are, too.

In terms of moving forward, here is what I propose.  First, I made a quick edit to the values above to (I hope) more accurately capture the degree of urgency based on the feedback in your last post.  Let me know if it is a better summary.  

Second, I think it is critical that we get the other major stakeholders involved in the conversation, so we should look at moderating how much further we go forward without them (I am particularly interested in hearing from other CSTART folks as my earlier posts represent the loose consensus of the technical folks at Mach 30 and I want to make sure that those voices do not dominate the conversation).  As we get a chance to hear from new stakeholders, we could likely find additional values.  If that happens we can just add to the list.

Third, once we get the other stakeholders in the conversation (and capture any additional values), I think we go over the requirements and solutions again from the view point of the values (so for instance, what kinds of features are we really looking for when we say "Need something that works better than what we have now", or which of those features do we really want in the first release and what can wait until later when we aim for "release early, release often").  My hope is to integrate CSART and Mach 30 ideas into a joint proposed solution and early road map (similar to what Mach 30 was working on at the end of our process, but now balancing our combined needs and abilities).  This is the part that I hope to see take a matter of days (assuming we continue to be closely aligned on values).

Some tangent points to comment on.  First, in terms of Mach 30 RoR programmers, most of the Mach 30 Board members are non-programmers, so I don't immediately have someone in mind who would be interested in contributing time on an RoR project.  However, what I can do is put out a message to the members of our site and send some emails to people I know who know RoR and might be interested in this.  I'll let you know what comes of that.

Second, incorporating "engineering decisions"/life-cycles is definitely going to be one of the challenging requirements to work through.  There are several models of systems engineering processes, including the V-model.  I personally believe that we will be building a better system if we can build something that lets users work the way they want in terms of life-cycles/decision processes, by focusing on capturing the way they are working, not enforcing a particular way on them.  In some ways, that may be easier (we don't have to model every detail of any one process), but in others I expect it will be harder (what exactly do we capture in the database and how do we display it if we are not working in a single model?  do we have to support lots of specific models or is there a way to capture "events" and let users arrange them in the order that fits their way of working?)   This is the place that we left off at Mach 30, with our decision being get something up that is somewhat process agnostic for the time being and explore how the tool behaves in its own right before making decisions about process management.  We are hoping that part of the reason we felt stuck was there were things to learn about implementing process management by using the earlier versions of the tool.  We may also get some nice feedback along these lines once we have something to show people.

Finally, corny or not,  it is my very real hope that this can and will benefit the whole world.  So here's to a great start.

Rizwan and rpulkrabek, thanks for the comments.  Rpulkrakbek, I have added your feature to the "unfinished" list above since this is a first pass at discussing it (note, I have tried to expand its scope to capture the underlying value and noted your thoughts on a solution that could cover that need).  Also, thanks for the link back to the earlier discussion on project management at CSTART.  It is important that we take full advantage of the work that has already been done as we move forward.

Rizwan, first, I just want to say I think your comment regarding wordpress.com/.org succinctly and perfectly sums up the idea we have been talking about in terms of the larger scope of this project.  Thanks for that wonderful insight.  In terms of .com or .org first, I need a little more time to reflect on the question before I will have useful comments (I think there are some underlying values in this question that have not been brought to the surface yet that will help clarify the path forward, and I need a little more time to tease them out of the dialog).

I also think that the widespread availability of LAMP is a compelling issue, and that it brings up another important value to balance:

• the choice of programming language (and other elements of the software stack) impacts the ability of users to self-host, and all other things being equal, the barrier to self-hosting should be as low as possible <= clearly nudges decisions in the direction of LAMP per rizwan's comments above; should be balanced with other values that affect language choice (such as availability of developers in our two groups, and leveraging existing projects)

Finally, I think Rizwan's three questions are all very important items to discuss.  Here is my feedback concerning them:

1. License: To date, Mach 30 has been a more BSD/MIT kind of organization, because we are very interested in creating as few barriers as possible to corporate adoption of our solutions.  That being said, in terms of this project, choosing a different license is in no ways a deal breaker.  One last thought on licensing, if we do decide to extend an existing solution, we should keep in mind that we may simply have to accept the license of that solution.
2. Code repo: Given that this project will need to be able to handle source code (for control systems, engineering analyses codes, and embedded software, etc), I would actually propose that we move to self-host the code (and design decisions, forums, documentation, etc) within a copy of the system.  Obviously there is some boot-strapping to get through first, but I am a strong proponent of "eating one's own dog food", so I would love to see us have to actually use the tool to host the project.
3. Name: Yup, the name is important.  Mach 30 has had a small discussion on this and came up with one possible name:  Open Design Engine (.com, .net, and .org currently registered).  The idea for the name came out of two separate ideas.  One, at Mach 30, we have preferred the term open design to open hardware or open source hardware (I personally think it better captures the essence of what is open in openly licensed hardware, namely the design of that hardware).  And two, like source forge plays on the idea of forging code, this is suposed to evoke the antique name for a machine that performs a given function, namely engine (like the cotton gin is short for for the cotton engine).  Finally, it just happens to have the abbreviation ODE, which is kind of funny given how often ordinary differential equations show up in engineering.  However, given all of that, we are still completely open to other names.  Clearly that work was done before we started discussing this as a joint project, and it is important that the name works for both CSTART and Mach 30.

I think that is all I have for now.

Moving the discussion concerning requirements/features and their underlying values to the wiki is a good idea.  Unless anyone has a problem with it, I'll go back and review the CSTART process for project posting in the wiki and start to move the specific ideas/features/requirements/values over to the wiki.

And thanks for the compliment on the name.  Any other comments on that last round of material (especially the name, as I imagine that will be apart of the wiki page's title once selected)?

This concept has been under discussion for a while now, in IRC and in multiple threads including the one rpulkrabek mentioned that includes a thought out general project lifecycle that could be applied to such a project management system that went ignored, this thread (the "Missions" section in the chart), and a couple other random threads. I've personally put more into this including testing out various open and closed source project management web apps (including Redmine, which I was disappointed with), and created a rough design mockup that takes into account most of the ideas proposed in this thread. The best existing and most complete solution is the Drupal based Open Atrium which supports the needed features or would support existing Drupal modules that could fill any remaining needed features. This is also what Open Space Movement is basing their very similar web app on last time I checked.

I'd be against the "Open Design Engine" name. If the "Open" is in reference to what is being designed, you're assuming the users would always be hosting their projects in an open manner, and if it's not, generally open source apps do not declare their openness in the app name. You're also assuming it will be used for "Design" work, when it could very well be used to manage any type of project. "Engine" I'm on the fence about it because while it does convey images of a mechanical engine, which may or may not be a good thing, it could also lead to confusion. On a related but unnecessary note, I've personally been calling this project Spacecamp, a play on words of the very popular Basecamp hosted project management web app… and well, Space Camp. This could never be a working name of course due to trademarks. I don't have another usable name to propose at this time.

Post edited 4:42 am – July 14, 2010 by rpulkrabek

J. Simmons said:

Am I correct in assuming that the CSTART process is to continue discussing the involved decisions over here in the forums, and let users add documentation (either new feature ideas, summaries of decisions from forums, etc) to the wiki as we move forward?  If so, I would like to propose that we start with discussing the early roadmap/driving features and then move to the question of should we extend an existing system, and if so which.  

This is my understanding as well. I also think the proposal is fitting.

• A method to inform others, and possibly restrict others, that a certain item is currently being worked on, to avoid different design changes happening at the same time.
• A history or RSS feed of the most recently modified items.
• Document number generation. Possibly a running number to uniquely identify each document or part and possibly associate this number to the document. If this method is used, it's suggested that the number is also associated to a more readable description ex: ID=12345678rev01; Description=OHKLA COMBUSTION CHAMBER. Another thing to consider is variants and the numbers for that.
• Thumbnails next to each item to quickly view what each file is (useful for CAD models).
• A BOM tree to visualize the structure. Also, a method to see where a part is used in other assemblies.
• A page/site to see all available attributes, such as, ID, Description, Creater, Modifier, creation date, modified date, etc.