|
|
| Line 1: |
Line 1: |
| | | | |
| − | (http://wiki.openmod-initiative.org/ or http://platform.openmod-initiative.org/wiki) | + | ([[http://wiki.openmod-initiative.org/, open source modelling|http://wiki.openmod-initiative.org/]] or [http://platform.openmod-initiative.org/wiki http://platform.openmod-initiative.org/wiki]) |
| | | | |
| | The wiki provides information as well for non-modellers or newbies in the modelling field as for model developers. The presented information is developed collaboratively (i.e. discussions in the background). | | The wiki provides information as well for non-modellers or newbies in the modelling field as for model developers. The presented information is developed collaboratively (i.e. discussions in the background). |
| | | | |
| | + | <br/>'''Just having a look''' |
| | | | |
| − | '''Just having a look'''
| |
| | The user, who visits the glossary just to have a look, finds a list of all terms given in alphabetical order. With a click on the term she/he gets to a wiki page showing the term and its definition as well as, if existing, its sub-terms and other related terms (ontology). | | The user, who visits the glossary just to have a look, finds a list of all terms given in alphabetical order. With a click on the term she/he gets to a wiki page showing the term and its definition as well as, if existing, its sub-terms and other related terms (ontology). |
| | | | |
| Line 20: |
Line 20: |
| | The glossary is made up by the wiki pages, which are part of the category called “glossary”. | | The glossary is made up by the wiki pages, which are part of the category called “glossary”. |
| | | | |
| | + | <br/> |
| | | | |
| | = Quality criteria = | | = Quality criteria = |
| Line 28: |
Line 29: |
| | | | |
| | *Data: source provided, reliable source, licence given, structure of data (i.e. machine readability etc.), ... | | *Data: source provided, reliable source, licence given, structure of data (i.e. machine readability etc.), ... |
| − | *Models: external validation, active community, up-to-date and good documentation (see also [https://docs.google.com/document/d/1Rg6f9iGyVcW7o4SolGi_cstwa66tZiOMVQyzmT1PRsA/edit?pref=2&pli=1 here]), [[Best_practices_for_model_websites|good model presentation]] incl. giving an [https://typo3.org/extensions/repository/ overview of available extensions] etc. There is a certain overlap with the elements of the model fact sheet, but here the best practice is presented / discussed. | + | *Models: external validation, active community, up-to-date and good documentation (see also [https://docs.google.com/document/d/1Rg6f9iGyVcW7o4SolGi_cstwa66tZiOMVQyzmT1PRsA/edit?pref=2&pli=1 here]), [[Best practices for model websites|good model presentation]] incl. giving an [https://typo3.org/extensions/repository/ overview of available extensions] etc. There is a certain overlap with the elements of the model fact sheet, but here the best practice is presented / discussed. |
| | *Assumptions: .. | | *Assumptions: .. |
| | *Scenarios: … | | *Scenarios: … |
| Line 39: |
Line 40: |
| | Wiki pages. | | Wiki pages. |
| | | | |
| | + | <br/> |
| | | | |
| | = openmod Activities / Events = | | = openmod Activities / Events = |
| Line 52: |
Line 54: |
| | Wiki pages as before. | | Wiki pages as before. |
| | | | |
| | + | <br/> |
| | | | |
| | = Open Licences = | | = Open Licences = |
| Line 57: |
Line 60: |
| | '''<u>Use Case of all users:</u>''' | | '''<u>Use Case of all users:</u>''' |
| | | | |
| − | On [[Choosing_a_license|this wiki page]] the user finds, as before, information with regard to open source licences, copyrights and copylefts. | + | On [[Choosing a license|this wiki page]] the user finds, as before, information with regard to open source licences, copyrights and copylefts. |
| | | | |
| | <u>'''Implementation:'''</u> | | <u>'''Implementation:'''</u> |
| Line 63: |
Line 66: |
| | Wiki pages as before. | | Wiki pages as before. |
| | | | |
| | + | <br/> |
| | | | |
| | = Best practice guide for collaborative modelling = | | = Best practice guide for collaborative modelling = |
| Line 85: |
Line 89: |
| | Wiki pages. | | Wiki pages. |
| | | | |
| | + | <br/> |
| | | | |
| | = Coding Rules / Guidelines / Standards = | | = Coding Rules / Guidelines / Standards = |
| Line 90: |
Line 95: |
| | <u>'''Use Case of model developers:'''</u> | | <u>'''Use Case of model developers:'''</u> |
| | | | |
| − | The model developers document and discuss their rules / guidelines for the coding of energy system models and their components on these wiki pages in order to establish good practice and perhaps to facilitate the process of model integration (see also [[Discussion:_Ways_of_model_integration|here]]). The model developers might use the annual openmod workshops to collaboratively develop these best practice standards for software design. | + | The model developers document and discuss their rules / guidelines for the coding of energy system models and their components on these wiki pages in order to establish good practice and perhaps to facilitate the process of model integration (see also [[Discussion: Ways of model integration|here]]). The model developers might use the annual openmod workshops to collaboratively develop these best practice standards for software design. |
| | | | |
| | ''Differentiation between Coding Rules / Guidelines published by oemof (e.g. git braching model) and by the OpenEnergy Platform required!'' | | ''Differentiation between Coding Rules / Guidelines published by oemof (e.g. git braching model) and by the OpenEnergy Platform required!'' |
Revision as of 09:19, 18 February 2016
([open source modelling|http://wiki.openmod-initiative.org/] or http://platform.openmod-initiative.org/wiki)
The wiki provides information as well for non-modellers or newbies in the modelling field as for model developers. The presented information is developed collaboratively (i.e. discussions in the background).
Just having a look
The user, who visits the glossary just to have a look, finds a list of all terms given in alphabetical order. With a click on the term she/he gets to a wiki page showing the term and its definition as well as, if existing, its sub-terms and other related terms (ontology).
Searching a definition
The wish to clarify the terminology is not limited to beginners and non-modellers, because some terms might be used differently or be vague. A user studying a fact sheet might come across a term, that can be hardly interpreted. In order to get to know, how a term is used and understood in the openmod community, the user types the term into a search field and selects the glossary search. The search results will list all glossary entries whose titles or explanations match. With a click on one of the search result the user gets to the wiki page of the selected term.
Giving and discussing a definition
A logged-in user can on the one hand create a new glossary page in the wiki in order to give a definition of a new term. On the other hand she/he can participate in the discussions belonging to existing glossary entries as well as she/he can change the glossary entries themselves.
Implementation:
The glossary is made up by the wiki pages, which are part of the category called “glossary”.
Quality criteria
Use Case of all users:
As a result of an ongoing discussion process (in the openmod wiki or another specified place) the user finds quality criteria for data, assumptions, models, scenarios and open source code in the openmod wiki. For example:
- Data: source provided, reliable source, licence given, structure of data (i.e. machine readability etc.), ...
- Models: external validation, active community, up-to-date and good documentation (see also here), good model presentation incl. giving an overview of available extensions etc. There is a certain overlap with the elements of the model fact sheet, but here the best practice is presented / discussed.
- Assumptions: ..
- Scenarios: …
- Open Source Code: additional to the criteria for good models: good code and developer documentation, ...
Specifications / explanations are also given here. The user can also participate in the discussion process.
Implementation:
Wiki pages.
openmod Activities / Events
Use Case of all users:
As up to now the user finds here the wiki pages for the past and coming events of the openmod initiative with links to the protocols and presentations.
(Hint: The upcoming openmod workshop will also be presented on the main page (“Connect!”).)
Implementation:
Wiki pages as before.
Open Licences
Use Case of all users:
On this wiki page the user finds, as before, information with regard to open source licences, copyrights and copylefts.
Implementation:
Wiki pages as before.
Best practice guide for collaborative modelling
Use Case of model developers:
On these wiki pages the user finds a selection of tools, energy system modellers recommend / use for the collaborative open source model development. Moreover, proven work flows are presented by users for users, for example:
- Designing communication channels for a project
- Usage of issues and labels on GitHubs / issue management
- (git work flows)
- (regular) web conferences / chats and their rules (e.g. discussing points on the agenda / problems only based on existing suggestions / solution porposals)
- Good real-life meetings (incl. organising events for the developer community like http://t3board15.typo3.org/)
- Writing good protocols (documentation of agreements)
- Roles in the collaborative open source model development (lead developer, release lead etc.)
- Decision making processes
- Asking the community (mailing list or Question and Answer (Q&A) on Stack Overflow with preferred tag)
- perhaps also presentation of negative examples
Implementation:
Wiki pages.
Coding Rules / Guidelines / Standards
Use Case of model developers:
The model developers document and discuss their rules / guidelines for the coding of energy system models and their components on these wiki pages in order to establish good practice and perhaps to facilitate the process of model integration (see also here). The model developers might use the annual openmod workshops to collaboratively develop these best practice standards for software design.
Differentiation between Coding Rules / Guidelines published by oemof (e.g. git braching model) and by the OpenEnergy Platform required!
Examples for modelling with Python could be:
- PEPs (Python Enhancement Proposals): PEP 0008 for the main text and PEP 0257 for docstring conventions
- Using pylint for Python models to check the quality of the model code
- (Python 3.5 standard because of the type hints)
Implementation:
Wiki pages.
