This page describes the basic procedures for handling contributions to COIN-OR projects so that the legal and technical standards of COIN-OR are upheld. This description (or checklist) is geared towards the project managers (for contributions to existing projects) and submission managers (for new projects).
Contributors will probably find the Contributions page more helpful; it contains similar information but with their viewpoint in mind.
The official procedures are contained in the Contribution Procedures document that is written by the Technical Leadership Council (TLC). The guidelines on this page are intended to assist you in following the procedures.
For those who are even more interested in the structure of COIN-OR, the procedures must comply with key policy points that are established by the Strategic Leadership Board (SLB) in the official COIN-OR Repository Management Policy.
The most common situation is for someone to submit a contribution that affects an existing project. If you are a project manager for an existing project, this is the section that will be most important for you.
After receiving a possible contribution, project managers should consider the following points:
- Do you want to include the contribution? Does it meet the technical standards of the project?
- Has the contributor agreed to release the contribution under the same license as the project?
- Has the contributor previously filled out a Contributor's Statement of Respect for Ownership?
Do you want to include the contribution? Does it meet the technical standards of the project?
As project manager, you decide whether or not you want to include each contribution. Until a contribution reaches the level that you wish to include it in the repository, there is no need to do anything.
Has the contributor agreed to release the contribution under the same license as the project?
The procedures require that all parts of a project be released under the same license. It is possible to release a contribution under a different license as a different (but related) project. If the contributor wishes to do this, then their contribution will be handled differently. See the section below on New Projects.
Has the contributor previously filled out a Contributor's Statement of Respect for Ownership?
The procedures require that all contributors fill out a Contributor's Statement of Respect for Ownership. Only one of these needs to be filled out, however; not one for each project.
You can check whether the contributor has already filled one out by checking the List of Contributors. If one is on file, then you may accept the contribution. If one is not on file, then instruct the contributor to contact the COIN-OR Secretary at email@example.com to fill one out. Do not put the contribution in the repository until the contributor's name appears on the list.
Important Note: The goal of the Contributor's Statement of Respect for Ownership is to help educate the contributor on their responsibility to verify agreement from all copyright holders before submitting a contribution. You are not required to do this verification for them. However, if you find that you have doubts about a contribution (for example, it looks like it contains code from another open-source project that uses a different license), then try to clarify the situation with the contributor before accepting the contribution. If you would like assistance with a difficult case, contact the Secretary at firstname.lastname@example.org or a member of the TLC or SLB.
Include the Contributors Name in the CVS Log and in the AUTHORS file
When the contribution is included, it is important to record the contributor. Please include the contributor's name as part of the log message when you check in the changes with CVS. This gives us a record that we can use in case we need to identify contributions made by specific contributors. Also, record the contributor in the AUTHORS file.
All contributions that would form new projects should be directed to email@example.com.
A submission manager appointed by the TLC will be in touch with the contributor about the process of accepting new projects. The submission manager's manager checklist include the steps below. A detailed description of each of the requirements are in the Contribution Procedures document.
- Is the contribution of use for Operations Research professionals or students?
- Is the project's goal to build or otherwise support the development or use of O.R. software?
- For software projects, is the project a development project or a production project? (In short, a production project is a project that when compile produces running code, while a development project just provides easily accessible space for collaborators working on a project. When a development project matures, i.e., reaches the stage that it produces running code, it can be turned into a production project
- For development projects, did the contributor submit a project description and road map?
- Does the submission include the AUTHORS, INSTALL, README, and COPYING or LICENSE files?
Build, Installation and Testing
- Do the build and installation procedures described in the INSTALL file work (the code builds and installs without error)?
- Is some form of a unitTest documented?
- Does the unitTest run and indicate success?
- Is there a simple methodology for adding tests in the future?
- Is the contribution being made under the Eclipse Public License (EPL)?
- If not the EPL, is the license certified by the Open Source Initiative?
- If not the EPL, is the contributor aware of the issues related to using their contribution with contributions licensed under the EPL?
- Do all authors have a completed Statement of Respect for Ownership on file? This form is available in pdf, tex, and plain-text formats.
- Have Documentation of Ownership and Licensing for New Projects and Owner's Confirmation of Licensing forms been filed? The first of these forms lists the owners of the contribution (among other things), while the second is filled out by all owners listed in the first one. These forms are also available in pdf, tex, and plain-text formats.
Project MaintenanceThe next three items are probably satisfied, since most likely the contributor will be the Project Manager (PM).
- Has a PM been named?
- Has the PM agreed to maintain the code on COIN-OR?
- Is the PM familiar with the process for accepting contributions and is willing to follow them?
- Has the PM filled out the standard summary page about the project (briefly descriping purpose, robustness, build process, environment, etc. about the project) page? The format of this page is still under discussion, for now all such information should go into the FAQ of the project.
- Has the PM agreed to moderate the project mailing list?
- Are all web pages the PM has created have a last modified date?
Administrative responsibilities of the submission managerThese steps happen after a new project has been accepted. The submission manager need not necessarily do these himself (herself). Actually, there are some steps he can't do, but he has to make sure they happen :-). If in doubt, turn to the TLC.
- Subscribe the PM to the PM mailing list.
- Import the project into the repository and give write access to the PM.
- Establish a project mailing list .
- Offer full membership in the COIN-OR Foundation to the PM.
- Announce (or rather let the PM have the honor of announcing) the project on the coin-announce mail list when the contribution process is complete and the project web site is live
- Update the COIN-OR umbrella pages to include the project web page.
If you have questions about the contribution process, you are encouraged to contact a representative on the TLC. We are still in the process of ironing out the details, and we expect that questions will arise.