[AMBER-Developers] Ground rules for discussion of Amber12

From: case <case.biomaps.rutgers.edu>
Date: Fri, 4 Nov 2011 23:28:03 -0400

I'm happy to see so much interest and passion about how to make Amber better,
but we need some ground rules, before productive discussions become
flame wars:

1. Please don't post things that can be construed as attacks of other
   developers. Go out of your way to be polite, and edit your posts (before
   hitting "send") with this in mind.

2. Keep your posts short and on-topic. It helps to see the gist of
   ideas for making things better, but at this stage the details of the
   implementation can be a distraction. If you really need a lot of space,
   use an attachment to hold the details.

3. I think the general outline of what will happen with Amber12 is actually
   pretty clear, and doesn't involve radical changes:

   a. AmberTools will still exist (because people are used to it, and because
      a growing number of projects outside of Amber make use of it.)
   b. Amber will still exist, as a paid-for entity, but our goal is to make
      the combination of Amber+AmberTools as useful as possible to ourselves
      and to the community, not to maximize the revenue we receive.

   c. I'm leaning towards keeping sander as a part of Amber. It would be
      considerably simpler to move it to AmberTools (as Jason, Tyler,
      Taisung and I have argued), but this might represent a bigger change
      than we want to tackle right now. Comments on this item are welcome
      (consistent with points 1 and 2 above), but mainly from those who
      have not already weighed in on this topic before.

   d. We can take useful steps to simplify the building and testing of our
      codes. A lot of this can be done by improving the Makefiles and scripts
      we already have. Jason has some good ideas about how to manage bugfixes
      and updates. Bigger changes (cmake might be an example) can be
      considered, but time is short.

   e. Having a bias toward reducing the number of separate programs is fine,
      but each project is different, and I don't see us changing from offering
      a "package of molecular simulation programs" that work reasonably well
      together. It's unfortunate but probably telling that (aside from
      Romain) we've not had a single comment about improving the documentation
      or the tutorials. Limitations there are probably more harmful to users
      than are any bad decisions about programming languages or about how
      and where to implement some new feature.

OK, I've violated my own rule about keeping posts short...just shows how
useful "rules" are for Amber developers.... :-)


AMBER-Developers mailing list
Received on Fri Nov 04 2011 - 20:30:02 PDT
Custom Search