=== Maintenance ===
  - Avoiding duplicated information (impossible to keep things up-to-date in the manuals). Good would be to store everything in-code (perhaps with some script scavengers all information from the headers automatically)
  - <del>Modularity: Having each REGISTER_CLASS() in the respective source file. Code for registering components exists for string-only versions (I'm hoping that classtype versions should rather be removed). Currently works for dynamic linking, but static linking is a problem (static symbols are optimized away). Solution could be to push for dynamic linking.</del>
  - <del>''classType'' has to go. Replace with strings (Note: ''int DataStream::write(const std::string &data); + read'' already exists!). This effects context files and load balancing.</del>
  - Reduce numbering of engineering models
    - SM-module: Replace ''DEIDynamic'', ''DIIDynamic'', ''NLDEIDynamic'', ''NonLinearDynamic'' with ''Dynamic''
    - TM-module: Replace ''NonStationary'', ''NLTransient'' with ''Transient''
  - Automatic tools:
    - More tests (at least 1 for each element type, at least 1 for each material, and 1 for each engineering model).
    - <del>Coverage testing (static analyzers could help, gcov + ctest is an option but it will miss tons of unstestable, optional but used, code).</del> Possible to run with ctest now
    - Aiming at zero-warning policy, even with MSVC (some thing that MSVC warns about could be fixed, some could be turned off). Usage of ''-DCMAKE_CXX_COMPILER_FLAG=-Werror'' is recommended. We still produce quite a lot of warnings in Clang and Intels compilers.

=== For new developers ===
  - Add ''BasicElement'' (linear triangle with plane stress) and ''BasicMaterial'' (isotropic plasticity + hardening) for the structural analysis problems which could help new developers get started without having to understand complex inheritance and tons of optional features. These are kept in-code with tests so that we make sure to keep them up-to-date.

=== Consistent naming schemes ===
  - Geometric type, interpolation order, and equation type should be part of the name. 
    - Number of spatial dimensions rarely need to be part of the name.
    - Will definitely break backwards compatibility. 
    - Tricky cases: Bi-quadratic v.s. Serendipity interpolation. Beams and shells. Springs. 
    - Suggested naming for standard elements: Type-Geometry-Order. E.g: ''PlaneStressTr2'', ''HeatTransferHexa1''
    - Should we try to be consistent with ''SpringLine1'' and ''Beam2dLine1'' ? I think these structural elements could have their own naming / Mikael
  - Add ClassFactory for interpolation classes, allowing to create more flexible 
    - ''FEInterpolation *ClassFactory :: createInterpolation(const char* name)'' <-- Needs empty (or consistent constructors).
    - ''PlaneStressTr2

=== Sets ===
  - <del>Mikael will be adding sets (boundary/edge/surface sets and bulk sets to start with)</del>
  - <del>Active boundary conditions will use sets instead of storing their own list of elements.</del>
  - <del>See where to go from there (perhaps it's possible to keep backwards compability)</del>

=== License ===
  - <del>Keep GPL - Might cut of commercial interest that could be benefitial</del>
  - <del>Switch to LGPL - Commercial might pay developers to extend OOFEM to include new elements, materials, contact models, etc.</del> This option has been applied
  - <del>Offer separate commercial license - We would probably require a copyright assignment agreement for contributions to work with this. Seems unlikely to happen.</del>