[Coin-discuss] encouraging contributions to COIN

Wed May 1 20:44:14 EDT 2002

Brady:
Great posting. You brought up a lot of good issues and questions -- I'll
try to answer what I can from my viewpoint.

The operating processes for COIN-OR are for the most part quite informal.
Better ways to do things, and the people with vision and time to make them
happen are welcome with open arms. Don't all the people volunteering time
to COIN-OR want to see the contributions and the community grow? If the web
page or our current modus operandi are giving any other message, then --
let's fix it.

There hasn't been a contribution to COIN-OR that has been rejected so far.
You specifically mentioned two examples of code that seemed to linger:
OsiDylp and the OsiSimplexInterface. In retrospect, I do think that a
better job could have been done of keeping the community informed of the
status of OsiDylp. But no one should be shy about piping up and asking
about the status of things on the list. There were some things happening on
the contributor's side over which the COIN-OR team had no control, but to
answer the real question you raise, I hope Lou Hafer will weigh in on his
experience contributing code.

My recollection of OsiSimplexInterface was it precipitated a major design
discussion which has not yet concluded. Maybe Laci Ladanyi can comment on
that one.

There are contributions underway that don't get much visibility on the
discussion list. For instance, there's a very nifty new non-linear package
that's approved and the author is just putting some final touches on the
documentation before announcing it (you know who you are -- hint, hint!! :
-) and 3-4 other projects in the pipeline that I know about. Personally,
I'd like to see more of the "work-in-progress" kinda of postings, but I
feel that it's up to the contributor to make those announcements, so all I
do is encourage them off line.

- Do we want people to contribute code?

Absolutely.  Especially code where the authors are looking to collaborate
with others on developing.

- How should people submit their contributions?

Send a note to the coin-discuss mailing list, and/or anyone on the
core-team.

- Is there a procedural difference between submitting bug fixes,
 improvements to existing code, and wholly new elements?

Yes. Submissions which are relatively minor (e.g., small bug fix), follow a
 different procedure than the contribution of a new project (e.g.,
 contribution of a non-linear solver).

- What will happen after it's submitted?  For example, will a
  developer with CVS privileges keep the contributor posted on where
  things stand?  How long do we expect the process to take?

The way we've informally self-organized to date is that we nominally have a
  core-team member associated with each module in the CVS directory. The
  core-team member has day-to-day responsibility of their module. If there
  is a disagreement about what goes in a module (and there's never been one
  yet), decisions are made by a consensus of the core-team. The responsible
  core-team member should keep the contributor posted on the status.  The
  core-team members are volunteers. Most everyone is pretty responsive,
  although work demands/deadlines get in the way.  We've discussed other
  ways to structure the group, but in the end we decided to morph as the
  need arose.

- Who decides whether bug fixes and improvements to existing code are
  actually put in the distribution?

The core-team member associated with the module to which the contribution
  is being made.

- Is there some approval process for new contributions?  If so, what
  sort of contributions are we looking for?

We haven't rejected anything to date. There is a bureaucratic approval
  process to ensure that the software contributions are being contributed
  by their legal owners. This involves certificates of originality, etc. It
  can take a while to sift through the legal ownership questions. The
  author isn't necessarily the owner, depending on who employees and funds
  the owner and what other software was embedded in the contribution.

- Are there technical requirements for new contributions?

I think there should be technical "quality" standards, but right now it's
informal.  Everything is looked at on a case-by-case basis.

- Are changes that only affect documentation handled differently?

No.

- At what point do contributors gain CVS upload privileges?

When a new project is contributed, a new core-team member is named to run
that project (i.e. the contributor).   Again, this was one of those
organizational questions that we left to address when the need arose.

Robin

----------------------------------------------------------------------------------

Robin Lougee-Heimer
IBM TJ Watson Research Center
ph: 914-945-3032   fax: 914-945-3434
robinlh at us.ibm.com
http://www.coin-or.org

Brady Hunsaker <hunsaker at isye.gatech.edu>@www-124.southbury.usf.ibm.com on
05/01/2002 05:31:52 PM

Please respond to coin-discuss at www-124.southbury.usf.ibm.com

Sent by:    coin-discuss-admin at www-124.southbury.usf.ibm.com

To:    coin-discuss at www-124.southbury.usf.ibm.com
cc:
Subject:    [Coin-discuss] encouraging contributions to COIN

In order for COIN to really prosper, it seems to me that we need more
people using COIN and more people contributing to COIN.  Based on the
relatively low level of activity in the mailing lists, I don't get the
sense that the COIN community is as large as it could/should be.

While there are a number of possible reasons for this, there is one
that I would like to address: encouraging contributions.

How should programmers submit bug fixes or new code to COIN?  I have
been using COIN and following the mailing lists for more than six
months, but I still don't know the preferred method for people
(without CVS upload privileges) to submit code.  What seems to happen
most is that people post their contributions on coin-discuss.  The FAQ
on the web page has no question on how to submit code or what kind of
code we'd like to have submitted.  There is a question about reporting
bugs, but the link it gives is broken.  I think this all sends the
message that we don't really want people to submit code.

In the cases where I've seen new code offered, results have been mixed.
I was happy to see OsiDylp appear in the CVS repository yesterday, but
it was reported as being almost ready in early March.  The
"contribution" of OsiSimplexInterface for low level control like pivots
was made in February, but has never made it into the distribution.
Perhaps there is a reason for this, but I have never seen it
mentioned.  Again, the message I get is that contributions to COIN
will take a long time to make it into the distribution if in fact they
ever do, so it's probably better to concentrate my creative energy
elsewhere.

I believe that like any open-source project, COIN's strength will come
from an active, diverse group of contributors.  Right now I don't
think we're encouraging the formation of such a group.  I think it
would help to publicly address the following questions:

- Do we want people to contribute code?

- How should people submit their contributions?

- Is there a procedural difference between submitting bug fixes,
 improvements to existing code, and wholly new elements?

- What will happen after it's submitted?  For example, will a
  developer with CVS privileges keep the contributor posted on where
  things stand?  How long do we expect the process to take?

- Who decides whether bug fixes and improvements to existing code are
  actually put in the distribution?

- Is there some approval process for new contributions?  If so, what
  sort of contributions are we looking for?

- Are there technical requirements for new contributions?

- Are changes that only affect documentation handled differently?

- At what point do contributors gain CVS upload privileges?

I really like the ideas behind COIN, but right now I think we're not
encouraging outsiders (like me) to get involved.  I'm not sure what the
best way to improve the situation is, but I think we need to discuss
it to see if there are any changes that would help.

Brady

----------------
Brady Hunsaker
Georgia Institute of Technology
Program in Algorithms, Combinatorics, and Optimization
School of Industrial and Systems Engineering

E-mail address:   hunsaker at isye.gatech.edu
_______________________________________________
Coin-discuss mailing list
Coin-discuss at www-124.ibm.com
http://www-124.ibm.com/developerworks/oss/mailman/listinfo/coin-discuss