Content for announcement of the the "future" mailing list

On the tlc/slb call, we decided to start a mailing list for "future" of COIN-OR discussions -- so as not to over load the technical coin-discuss mailing list. What goes in the announcement? Here's a quick something just to get it going. Please post something better. -- Robin

Strawman for announcement:

"As COIN-OR has grown, the various boards and commitees have struggled with balancing different needs, sometimes with mixed results. To "open" up the discussion a new mailing list has been created. Join the discussion. (link to new list goes here)"

Strawman for 1st post:

"COIN-OR has been moving toward making projects easier for users at the expense of increased requirements for Project Managers. For example, to provide binaries for users, Project Managers have been required to switch to SVN and adhere to new rules. One size doesn't fit all. Where should the trade-offs be made?

• Is the benefit of project set up uniformity for users worth the one-time pain for project mangers? (Imho: the decision should be left to the project manager. If they want the services for their users, they'll conform. If not, it's okay to stay as is.)"

Comment (Lou):

One approach to shaping the discussion could be this: In the 1st post, include a short table with the services we're currently offering (repository, mailing lists, trac, binaries, etc.), and the corresponding technical requirements needed to make it practical to provide the service. Perhaps with an indication whether the requirement can be optional or not. Probably best assembled by the TLC. This is one way of stating exactly where we think the tradeoffs lie. Then, solicit feedback from users to find out which (if any) of these things are factors in their choice to use COIN software. From PMs, solicit feedback about which (if any) of the services and requirements are factors in their decision to choose COIN to host their software.

There are intangibles which I don't yet have a good idea of how to address. For myself, at least, perceived quality and stability is a big factor when I'm choosing between multiple packages offering similar functionality. I see many of the changes we've made in the past 12 months as being aimed toward these intangibles. I'd like to hope that users and PMs see these as valuable. But I don't have a good idea on how ask them "How valuable?"