What is a framework ? - Strategic oemof planning and design

[simnh]

@oemof/oemof-main

In the last month I noticed that a lot of code was produced without having a decesion-tool for important decisions on new features. Additionally new developers are joining / will be joining the project soon.

On the other hand I feel the absence of a common understanding of what oemof or more general a framework is. Important structures such as "core scope, documentation, stringent code, flexible interfaces for adaptions" are missing or "are not clear" (as @ckaldemeyer pointed out in issue #103 ).

This is cleary not something that can be resolved in an issue discussion. We should have a webco on this soon. Nevertheless, we can share ideas and prepare ourselves here.

Personally I think: 'Less is more' / 'quality before quantity' . I think the core conflict here is the following:

All oemof developers need (now!) problem specific models/tools etc. There is little time to only work on oemof because most of us are involed in other projects. At the same time there is an interest to share code in a framework structure / base our models on a framework. In contrast oemof needs well designed generic functionalties that are in general not part of this problem specific work in project. This means that in particulat at the beginning (and we are at the beginning) we need to be carefull in pushing too much problem specfic code into an unfished structure - or not even generic code in a unfinished structure. In my opinion the conflict can only be resolved by working on structure/interfaces/extensions regarding oemof and stop pushing too much new code into the framework. Even if this means oemof is growing very slowly.

I think we need a decision tool / group deciding about:

• What should the framework provide (Type of models and functionalities)
• Are new features inline with this idea
• Can the current oemof structure handle new proposed features or does it foster a unstructured framework

[uvchik]

It will be difficult to decide this because it is quite unspecific. But I also think it will be difficult to define rules that are described so clearly that everybody will understand the same.

• For me a quality management is very important. A merge should have to be unblocked by one or two admins.
• I think it is good to have extension levels (experimental, testing,...), so that people can add new features but it will take a while until they become a real part of oemof or they will not if they are not good enough.
• For new features transparency is important. We should use issues or PR to document the new feature instead of just merging it. It is easier to discuss whether a new feature is useful or not than to define overall rules that are interpreted differently.

[uvchik]

Another important question for me is the role of solph within the framework. Is it the solving library or a solving library?

[simnh]

For me solph is clearly A library!

[ckaldemeyer]

It will be difficult to decide this because it is quite unspecific.

Yes, I also think it really is. But I think a (maybe partly not optimal) decision is better than no decision since no decision might threaten the success of the whole project in my opinion.

But I also think it will be difficult to define rules that are described so clearly that everybody will understand the same. For me a quality management is very important. A merge should have to be unblocked by one or two admins. I think it is good to have extension levels (experimental, testing,...), so that people can add new features but it will take a while until they become a real part of oemof or they will not if they are not good enough. For new features transparency is important. We should use issues or PR to document the new feature instead of just merging it. It is easier to discuss whether a new feature is useful or not than to define overall rules that are interpreted differently.

I am completely in line with that!

[ckaldemeyer]

Another important question for me is the role of solph within the framework. Is it the solving library or a solving library?

For me too. If we really want to stick to the framework idea and keep the flexibility, there should be different libraries to model/solve different problem types and they should be independent from each other.

[ckaldemeyer]

For instance, if someone wants to solve his/her problem using quadratic programming, there should be a library for that that has the same inputs/outputs as solph.

[uvchik]

Then we should talk about the documentation of solph, because we need a place where we document how to use an entitiy within solph and what entities are suitable with solph. I think the assembler functions could be a good place but they are difficult to handle within sphinx (see #109). We cannot do this in the core classes because a nolph-library might use them differently.

[ckaldemeyer]

Protocol of the web conference from today

Attendant: Uwe, Simon, Günni, Clemens, Cord, Caro

• A full paper at EnvironInfo is not realistic (deadline end of march) but a working paper would be an option
• All participants agreed that a "Refactoring" of oemof makes sense and we should have a live meeting for that
• All active developers should take part and all current RLI/ZNES requirements should be heard
• Refactoring-meeting from 07/04/2016 - 08/04/2016
  • Participants: Uwe, Simon, Günni, Clemens, Cord
  • Place: to be defined
• Discussion based on prepared proposals
  • 1. Organisation/workflows (Uwe, ...): project management, quality management, ...
  • 2. Restructuring of framework elemens (Cord, Simon, ...): definition of core/extension architecture, encapsulation of single modules/packages, definition of package interfaces (at least in pseudo-code), ...

[gplssm]

Just to let you know: the _openeGo is aware of the Refactoring-meeting and discusses potential participation.

We're more keen on discussing future structure, feature and all things among this than working on the refactoring of old code. So, I'll figure out in the next days what's the best way of participation of for us.

[cswh]

I think the refactoring meeting outcome which should find its way into the github in the next days, is enough to close this issue.

If you think different, please reopen.