Here are some ways to contribute to the MOEA Framework.  We ask that all
contributions are licensed under the GNU Lesser General Public License and
are complete with any necessary documentation, tests and data files.

These tasks are organized by their level of difficulty.  Easy tasks provide an
excellent starting point for beginners and should require only a few hours of 
development effort.  More difficult tasks may take days or weeks of development
effort, and may require interaction with other contributors to plan and discuss
any changes.

------
 Easy
------

  - Upgrade to JMetal 4.4.  The latest JMetal source is currently missing the
    IConstraintViolationComparator interface and can not be compiled.

  - ResultFileMerger should be able to also retain decision variables.

  - Add ARFF and Aerovis output formats to ExtractData and any other relevant
    classes.

  - Examples 5 and 6 references the C interface code.  This should be included
    in the compiled JAR distribution.

  - Need to determine for which classes does value-based equals methods make
    sense, and provide equals and hashCode implementations for these classes.
    As an example, it doesn't make sense for Solution to provide an equals
    method since there are many possible interpretations of equality.  Are two
    solutions equal if they share the same objective values regardless of their
    decision variables?  Consequently, equals methods don't make sense for
    Populations.  However, a helper class that provides various methods of
    comparison between solutions and populations would be useful.  For
    consistency, use the Apache Commons Lang builder classes to implement
    equals and hashCode.

  - Scan the source code for errors, exceptions and warnings which are not
    documented in the HELP file.
    
  - Identify public facing API methods and functions which are not protected
    against invalid inputs, such as null or out-of-bounds values.  Ideally,
    an invalid input which would cause an error should be detected as soon as
    possible in order to provide meaningful feedback to developers (i.e.,
    identify and report a null pointer ASAP rather than wait until dereferenced
    by internal code.
    
    
--------
 Medium
--------

  - The MOEA Framework can currently connect with C/C++ programs by sending
    data over standard I/O or sockets.  This, however, is not efficient as the
    data must be serialized, transmitted, and parsed between Java and C.  Java
    does have the Java Native Interface (JNI) or similar tools like Java Native
    Access (JNA) for directly invoking methods in natively-compiled libraries.
    Explore ways to develop a faster interface using JNI.
    
  - Develop a MATLAB interface, ideally using the same socket communication
    scheme employed by ExternalProblem.

  - The org.moeaframework.core.fitness package contains code for supporting
    indicator-based methods, but is currently unused.  These should be used to
    implement native indicator-based MOEAs.
    
  - The MOEA Framework is primarily a single-threaded library, and currently
    only supports multithreaded evaluation of problems.  This limitation is
    caused by: 1) shared instances which are not thread safe, such as PRNG;
    and 2) the current requirement for reproducibility, which is affected if 
    PRNG is accessed by multiple concurrent threads.  Identify any other 
    limiting factors that would hinder modifying the code to support 
    multi-threaded execution.  Write a report detailing the necessary changes,
    but do NOT implement any changes.
    
  - The MOEA Framework is currently standardized for minimization problems,
    requiring any maximized objectives to be converted to minimization
    objectives (i.e., through negation).  This has several advantages, such as
    standardizing the file representation.  While a more flexible approach
    would allow the problem to define both minimization and maximization
    objectives, this may impact codes which only work on minimized objectives.
    Write a report detailing the necessary changes, but do NOT implement any
    changes.
    

------
 Hard
------

  - Develop a GUI that simplifies the use of the framework, allowing users to
    quickly design, run and view the results of experiments.  This should
    support high-dimensional (3D) visualization of Pareto sets, detailed
    runtime and end-of-run performance analysis, a code editor for defining new
    problems in one of the supported scripting languages, etc.

