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

Hi all,

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.

J, I'm glad you got to take a look good look at redmine. I'm not against using it as it does have pretty much everything we'd need. My primary reason for initially being against it is that it's Ruby, and thus would have a much smaller amount of contributing coders, and less server support, than either PHP or Python. It seems a lot of Project Management webapps are coded in Ruby for some reason.

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.

Wow, lots of great comments…

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…

Hey, just saw the latest comments (I was on a business trip to Italy last week that was a little busier than planned, so I have fallen a little behind in my email).  I have just taken a quick look at the trac-inspired/based options listed above, and I think my overall conclusion is to echo antinode in that we will need to customize anything we start with.  And I would add that it looks like these tools have a different set of strengths and weaknesses from redmine, so I am not sure from a feature set point of view there is a clear winner (though having python developers but not ruby ones is a clear mark against redmine).  

I think the one thing I liked from redmine that I have not found material on in these projects is extensibility.  Redmine has what looks to be a failry flexible plugin architecture, making many enhancements possible without going into the primary codebase (which means it would be easier to track the core development with our work).  Assuming that one or all of these trac-like projects has a similar capability, then I would be happy starting with one of these projects instead if we have the python developers but not the ruby developers.  But I really think we need to put up something sooner rather than later because there is not substitute for code in an open source project (a lesson I was reminded recently at the Open Hardware Summit).

One last thing, here are two links that I think look interesting for further reading/discussion:

• Dr Dobbs article on project hosting portals (by way of Basie)
• Pre-release of the call for proposals for DARPA's vehicleforge site – compare to our list of requirements, and I think you will see that the two lists are very close, which I take to mean we have done a good (enough) job of generating first tier requirements and that it really is time to put something up to test out

So, it sounds to me like one of the questions that is still lingering is which of the two Trac forks we would want to use assuming we went that way.  I have done some more in depth review of the content at both sites and have some comments about both.  But the bottom line is I am not really excited by the state of either project.  Which is not to say I'd be against this strategy, just that things look a little shaky this way, too (as compared to going with Redmine which is very shaky for us since we don't have any Ruby developers).

Dr Project – https://www.drproject.org/ - It looks to me like development on this project has all but come to a halt.

• https://www.drproject.org/DrProject/query?status=open&order=created&desc=1 - all recent bug reports have gone unassigned since the middle of 2008
• https://www.drproject.org/DrProject/browser - the most recent commit to their code repo is 8 months ago

I am not super excited about using a project as the foundation of our own work that has no existing participation.  I think we are bound to need support from the folks that already know the code.  Of course, one could argue our activity may get things going again, and that could happen.  But my first choice would not be to depend on that.  So, not great news.  But, at least they are using DrProject to manage their own work.  It must be at least reasonably stable as of the last release.

Basie – http://basieproject.org/ - It looks to me like this project must be undergoing a significant reboot.

• http://blog.basieproject.org/ - The blog is very active.  It has almost weekly posts of meeting minutes (very exciting), but it appears to be completely stand alone from their own code.
• http://code.basieproject.org/ - Source code appears to be displayed directly from SVN, instead of through an installed copy of Basie.  It makes me a little nervous that they are not using their own code to manage their work.
• https://basieproject.org/stable/basie/ - And their link to the "Development Portal" (which I assume would be running Basie) is down.  

So, more mixed news.  Very active development, but the developers are not using Basie to manage their own work.  Still, I think I'd prefer an active community to polished source code, I think…  It may just be that they need admin help or something to get back into Basie.  Who knows.  If someone at CSTART could get a live demo of Basie working, I'd be more inclined to go this route.  We could also drop the developers a note and see if they would be receptive to our extending Basie to suit our needs.

One final thought.  I was thinking about the idea to use Open Atrium again yesterday because I was watching a webinar on Drupal Commons.  I still don't like how some of the Open Atrium stuff worked (in particular the "wiki" and the over all feel of things), but I wonder if we could install issue tracking and repo modules for Drupal into Drupal Commons and get something that worked well.  

I am going to try a couple of things out on my box at home and see if I get any traction and post a follow up to this idea.  In the mean time, could someone else try to get a copy of Basie working to see where it really is in terms of function?

Later,

 -J

I would love to.  Where is the announcement of the meeting so I can find out date, time, etc?